[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 [127.0.0.1] (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 [10.90.34.44] (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 ([217.32.164.137]) 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 ([193.113.30.63]) 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>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
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 signalling.
_______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn
- [PCN] new text about Tunnelling for architecture … philip.eardley