[PCN] PCN & tunnelling

<philip.eardley@bt.com> Wed, 24 October 2007 10:23 UTC

Return-path: <pcn-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkdOk-0001lo-IR; Wed, 24 Oct 2007 06:23:38 -0400
Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IkdOi-0001kk-Hf for pcn-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 06:23:36 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkdOh-0001k7-Mn for pcn@ietf.org; Wed, 24 Oct 2007 06:23:35 -0400
Received: from smtp4.smtp.bt.com ([217.32.164.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkdOh-0008CI-9b for pcn@ietf.org; Wed, 24 Oct 2007 06:23:35 -0400
Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 11:23:34 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 24 Oct 2007 11:23:34 +0100
Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5F4@E03MVZ1-UKDY.domain1.systemhost.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: PCN & tunnelling
Thread-Index: AcgWJ+54M2I8eYc4QJu/kWUfuySz/Q==
From: philip.eardley@bt.com
To: pcn@ietf.org
X-OriginalArrivalTime: 24 Oct 2007 10:23:34.0455 (UTC) FILETIME=[EEB6C470:01C81627]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1
Subject: [PCN] PCN & tunnelling
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: PCN WG list <pcn.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pcn>
List-Post: <mailto:pcn@ietf.org>
List-Help: <mailto:pcn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1232073198=="
Errors-To: pcn-bounces@ietf.org

Hi,

 

I was chatting with Bob about section 5.8 tunnelling. We've realised
there's the following nasty case which we hadn't thought about. The
scenario is when a tunnel starts inside a PCN-domain and finishes
outside it. 

 

First we follow what happens when the current text is followed. Imagine
that the pkt is PCN-marked by some PCN-node before the tunnel start
node. On encapsulation the PCN-mark is copied onto the outer header.
Hence the PCN-egress-node 'sees' the PCN-mark as normal - this is ok.
The PCN-egress-node clears the marking in the (outer) header and
forwards the pkt into the next domain. The pkt is decapsulated at the
tunnel end point. But the decapsulated pkt is already PCN-marked.
Potential problems: [1] if it's decapsulated in a non-PCN-domain, then
the pkt may confuse nodes in this domain [depending on what encoding is
used for a PCN-mark] ; [2] if it's decapsulated in a PCN-domain, then
the pkt is PCN-marked [which might lead this PCN-domain to terminate or
block a flow unnecessarily].

 

The problem arises because the PCN-egress-node clears PCN-marking on the
outer header but not on the inner header. (This is a new problem
compared with ECN & tunnelling.) 

 

Possible solution: if the pkt is PCN-marked, then the tunnel start node
checks whether the tunnel egress is inside or outside the PCN-domain -
if it's outside, then it clears the PCN-marking on the inner header
(effectively it does this on behalf of the PCN-egress-node). (Also, the
PCN-mark is copied onto the outer header, as the current text says.)

 

Thoughts?

 

Thanks,

Phil/  

_______________________________________________
PCN mailing list
PCN@ietf.org
https://www1.ietf.org/mailman/listinfo/pcn