[PCN] new text about Tunnelling for architecture draft

<philip.eardley@bt.com> Thu, 25 October 2007 11:38 UTC

Return-path: <pcn-bounces@ietf.org>
Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il12Q-0004cI-1N; Thu, 25 Oct 2007 07:38:10 -0400
Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Il12O-0004bj-L8 for pcn-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 07:38:08 -0400
Received: from [] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il12O-0004ap-6z for pcn@ietf.org; Thu, 25 Oct 2007 07:38:08 -0400
Received: from smtp1.smtp.bt.com ([]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il12J-0003ux-Fa for pcn@ietf.org; Thu, 25 Oct 2007 07:38:04 -0400
Received: from E03MVZ1-UKDY.domain1.systemhost.net ([]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 12:36:38 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 25 Oct 2007 12:36:36 +0100
Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5FE@E03MVZ1-UKDY.domain1.systemhost.net>
Thread-Topic: new text about Tunnelling for architecture draft
Thread-Index: AcgW+0zEw+jXMppFTPiVcZ1Yb6Dn3w==
From: philip.eardley@bt.com
To: pcn@ietf.org
X-OriginalArrivalTime: 25 Oct 2007 11:36:38.0459 (UTC) FILETIME=[4E3270B0:01C816FB]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6379955759c38e2371a49573a0932fc7
Subject: [PCN] new text about Tunnelling for architecture draft
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="===============1412565482=="
Errors-To: pcn-bounces@ietf.org

Have tried to re-write the tunnelling section in the architecture draft
to reflect the recent emails:


Tunnelling (modified text for S5.8)

Tunnels may originate and/or terminate within a PCN-domain. It is
important that the PCN-marking of any packet can potentially influence
PCN's flow admission control and termination - it shouldn't matter
whether the packet happens to be tunnelled at the PCN-node that
PCN-marks the packet, or indeed whether it's decapsulated or
encapsulated by a subsequent PCN-node. 


This suggests that the "uniform conceptual model" described in [2983]
should be re-applied in the PCN context. In line with this and the
approach of [4303] and [draft-briscoe-tsvwg-ecn-tunnel], the following
rule is applied if encapsulation is done within the PCN-domain:

*        any PCN-marking is copied into the outer header    


Similarly, in line with the "uniform conceptual model" of [2983] and the
"full-functionality option" of [3168], the following rules are applied
if decapsulation is done within the PCN-domain:

*        if the outer header's marking state is more severe then it is
copied onto the inner header

*        NB the order of increasing severity is: unmarked; PCN-marking
with first encoding (ie associated with the PCN-lower-rate); PCN-marking
with second encoding (ie associated with the PCN-upper-rate)


The essential reason for the copying operations described above is to
simplify dealing with the various headers: PCN-marking is then
orthogonal to tunnel encapsulation /decapsulation. 


An operator may wish to tunnel PCN-traffic from PCN-ingress-nodes to
PCN-egress-nodes. The PCN-marks shouldn't be visible outside the
PCN-domain, which can be achieved by PCN-colouring (Section 5.3) after
all the other functions. The potential reasons for doing such tunnelling
are: the PCN-egress-node then automatically knows the address of the
relevant PCN-ingress-node for a flow; even if ECMP is running, all
PCN-packets on a particular ingress-egress-aggregate follow the same
path. But it also has drawbacks, for example the additional overhead in
terms of bandwidth and processing. 


Open issues: (text for S6, second para is new)

Tunnelling: There are scenarios where tunnelling makes it hard to
determine the path in the PCN-domain. The problem, its impact and the
potential solutions are similar to those for ECMP. 


Partially PCN-capable tunnels: (1) The tunnel starts outside a
PCN-domain and finishes inside it. If the packet arrives at the tunnel
ingress with the same encoding as used within the PCN-domain to indicate
PCN-marking, then this could lead the PCN-egress-node to falsely measure
pre-congestion.  (2) The tunnel starts inside a PCN-domain and finishes
outside it. If the packet arrives at the tunnel ingress already
PCN-marked, then it will still have the same encoding when it's
decapsulated which could potentially confuse nodes beyond the tunnel
egress.  (3) Scenarios with partially PCN-capable tunnels may also make
it harder for the PCN-egress-node to gather from the signalling messages
(eg RSVP, NSIS) the identity of the PCN-ingress-node. 



Potential solutions: (out of scope of architecture draft, but I'll add a
ref to this email thread)

*        tunnel starts outside a PCN-domain and finishes inside it:
could require tunnel egress to drop such a packet. This is same approach
as in S3.5, where PCN-ingress-node drops packet.

*        tunnel starts inside a PCN-domain and finishes outside it:
could require the tunnel ingress to check (somehow) whether the tunnel
egress is outside the PCN-domain, and if it is then clear any
PCN-marking on the inner header.

*        Signalling and partially-capable PCN-tunnels: don't know, could
try something similar to nsis [rfc4080 S5.4]: < To signal for the
packets carrying the tunneled data, the tunnel is considered a new data
flow in its own right, and NSIS signaling is applied to it recursively.
This requires signaling support in at least one tunnel endpoint.> This
problem should be considered in the milestone doc about reqts for pcn



PCN mailing list