Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkzK8-00077o-Dj; Thu, 25 Oct 2007 05:48:20 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IkzK6-00075Z-Lx for pcn-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 05:48:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkzK6-00075R-7Y for pcn@ietf.org; Thu, 25 Oct 2007 05:48:18 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkzK5-0001KG-DG for pcn@ietf.org; Thu, 25 Oct 2007 05:48:18 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Thu, 25 Oct 2007 11:48:09 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Oct 2007 11:48:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] PCN & tunnelling Date: Thu, 25 Oct 2007 11:48:08 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C4C132C@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5F8@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN & tunnelling thread-index: AcgWJ+54M2I8eYc4QJu/kWUfuySz/QABQXZQAA2JTqAAIfRrQA== From: "Geib, Ruediger" To: X-OriginalArrivalTime: 25 Oct 2007 09:48:09.0411 (UTC) FILETIME=[26808930:01C816EC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9d7e8d783239e9f0c425c823a9c950ff Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0597437933==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0597437933== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C816EC.26181EBF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C816EC.26181EBF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Phil, =20 by propagating down DSCP and PCN settings at a tunnel end, a router can make sure that the next hop is able to correctly interpret these values - if this next hop is within its own domain. If the tunnel end is an edge router and the next hop is part of a different domain, then the edge router should neither change the inner header DSCP nor the PCN codepoints. Is that what you think of? =20 Regards, =20 Rudiger -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Wednesday, October 24, 2007 9:07 PM To: Geib, Rudiger Cc: pcn@ietf.org Subject: RE: [PCN] PCN & tunnelling Ruediger, =20 Yes, it is a more general problem. I've been trying to read 2983 [diffserv & tunnels] and 3270 [mpls & diffserv - similar kinds of issues] =20 2983 has 2 conceptual models, Uniform & Pipe: - Uniform: tunnel is an artefact on the e2e path from a traffic conditioning viewpoint; pkt effectively has one DS field that's used for traffic conditioning. Copy DSCP value to the outer header at encaps and copy outer header's dscp value to inner IP header at decaps.=20 - Pipe: IP tunnel hides the nodes so they don't really participate in traffic conditioning. Tunnel egress ignores the outer header's dscp & uses the inner header's DSCP (or rather the traffic conditioning info it conveys - to cover the case where the same meaning is encoded by different values of dscp). Tunnel links DS domains at end points into a diffserv region ('virtually' contiguous).=20 =20 When it comes to PCN & tunnels, something analogous to the Uniform model seems more appropriate to me - ie the pkt effectively has one field for PCN-marking that's used for PCN-based adm ctrl (& termination); the operation is at decaps, if the outer header's PCN-marking is more severe than the inner IP header's, then copy it to the inner IP header.=20 At least I think the Uniform model is best for the normal (?) case where the tunnel is within the PCN-domain - because we want all nodes in the PCN-domain to be able potentially to PCN-mark & hence contribute to the adm ctrl decisions. If the tunnel is partly within a PCN-domain and partly outside I think the uniform model is still the right one (not too sure - there are lots of things complicating it, some of which mentioned in first email below, but I think the conceptual model should still be the same].=20 =20 Ruediger: question about what you call 'downpropagation', I assume this is the copying operation I refer to in the Uniform model. I agree with you for PCN marking [text is already in the archit draft on these lines]. However, you also mention downpropagation of DSCP which I don't think is correct.=20 =20 Ruediger, you mention where the DSCP values have different meanings at the tunnel ingress & egress (tunnel crosses a diffserv domain boundary). Yes, I believe this is a general diffserv issue and is covered by 2475. =20 phil =20 -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 Sent: 24 October 2007 12:10 To: Eardley,PL,Philip,CXR9 R Cc: pcn@ietf.org Subject: RE: [PCN] PCN & tunnelling =20 Phil, =20 I guess this is a general DiffServ issue too. In case [2] you assume the same DSCP to be used by the tunnel end point PCN domain as at the tunnel entry. This assumption may not hold, if the set DSCP is used for another service class or unused at the end point.=20 =20 I had a brief glance on RFC2983, "Differentiated Services and Tunnels". Downpropagation of outer IP header DSCP/PCN settings may be a fairly good recommendation. =20 Regards, =20 Rudiger -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Wednesday, October 24, 2007 12:24 PM To: pcn@ietf.org Subject: [PCN] PCN & tunnelling Hi, =20 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.=20 =20 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]. =20 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.)=20 =20 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.) =20 Thoughts? =20 Thanks, Phil/ =20 ------_=_NextPart_001_01C816EC.26181EBF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Phil,
 
by=20 propagating down DSCP and PCN settings at a tunnel end, a router = can make=20 sure that the next hop is able to correctly interpret these values - if = this=20 next hop is within its own domain. If the tunnel end is an edge router = and the=20 next hop is part of a different domain, then the edge router should = neither=20 change the inner header DSCP nor the PCN codepoints. Is that what you = think=20 of?
 
Regards,
 
Rudiger
-----Original Message-----
From: = philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: Wednesday, October 24, = 2007=20 9:07 PM
To: Geib, Rüdiger
Cc:=20 pcn@ietf.org
Subject: RE: [PCN] PCN &=20 tunnelling

Ruediger,

 

Yes, it is = a more=20 general problem. I’ve been trying to read 2983 [diffserv & = tunnels] and=20 3270 [mpls & diffserv – similar kinds of = issues]

 

2983 has 2 = conceptual=20 models, Uniform & Pipe:

- Uniform: = tunnel is=20 an artefact on the e2e path from a traffic conditioning viewpoint; pkt = effectively has one DS field that’s used for traffic = conditioning. Copy DSCP=20 value to the outer header at encaps and copy outer header’s dscp = value to=20 inner IP header at decaps.

- Pipe: IP = tunnel=20 hides the nodes so they don’t really participate in traffic = conditioning.=20 Tunnel egress ignores the outer header’s dscp & uses the = inner header’s=20 DSCP (or rather the traffic conditioning info it conveys – to = cover the case=20 where the same meaning is encoded by different values of dscp). Tunnel = links=20 DS domains at end points into a diffserv region = (‘virtually’ contiguous).=20

 

When it = comes to PCN=20 & tunnels, something analogous to the Uniform model seems more = appropriate=20 to me – ie the pkt effectively has one field for PCN-marking = that’s used for=20 PCN-based adm ctrl (& termination); the operation is at decaps, if = the=20 outer header’s PCN-marking is more severe than the inner IP = header’s, then=20 copy it to the inner IP header.

At least I = think the=20 Uniform model is best for the normal (?) case where the tunnel is = within the=20 PCN-domain – because we want all nodes in the PCN-domain to be = able=20 potentially to PCN-mark & hence contribute to the adm ctrl = decisions. If=20 the tunnel is partly within a PCN-domain and partly outside I think = the=20 uniform model is still the right one (not too sure – there are = lots of things=20 complicating it, some of which mentioned in first email below, but I = think the=20 conceptual model should still be the same].

 

Ruediger: = question=20 about what you call ‘downpropagation’, I assume this is = the copying operation=20 I refer to in the Uniform model. I agree with you for PCN marking = [text is=20 already in the archit draft on these lines]. However, you also mention = downpropagation of DSCP which I don’t think is correct. =

 

Ruediger, = you mention=20 where the DSCP values have different meanings at the tunnel ingress = &=20 egress (tunnel crosses a diffserv domain boundary). Yes, I believe = this is a=20 general diffserv issue and is covered by 2475.

 

phil

 

-----Original=20 Message-----
From: = Geib,=20 Ruediger [mailto:Ruediger.Geib@t-systems.com]
Sent: 24=20 October 2007 12:10
To: Eardley,PL,Philip,CXR9 = R
Cc: pcn@ietf.org
Subject: RE: [PCN] PCN &=20 tunnelling

 

Phil,

 

I guess = this is a=20 general DiffServ issue too. In case [2] you assume the same DSCP to be = used by=20 the tunnel end point PCN domain as at the tunnel entry. This = assumption=20 may not hold, if the set DSCP is used for another service class = or unused=20 at the end point.

 

I had a = brief glance=20 on RFC2983, "Differentiated Services and Tunnels". Downpropagation of = outer IP=20 header DSCP/PCN settings may be a fairly good=20 recommendation.

 

Regards,

 

Rudiger

-----Original=20 Message-----
From:=20 philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Wednesday, October 24, = 2007 12:24=20 PM
To:=20 pcn@ietf.org
Subject: [PCN]=20 PCN & tunnelling

Hi,

 

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

 

First we follow what happens when the = current text=20 is followed. Imagine that the pkt is PCN-marked by some PCN-node = before the=20 tunnel start node. On encapsulation the PCN-mark is copied onto the = outer=20 header. Hence the PCN-egress-node ‘sees’ the PCN-mark as = normal – this is=20 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=20 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=20 confuse nodes in this domain [depending on what encoding is used for = a=20 PCN-mark] ; [2] if it’s decapsulated in a PCN-domain, then the = pkt is=20 PCN-marked [which might lead this PCN-domain to terminate or block a = flow=20 unnecessarily].

 

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

 

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

 

Thoughts?

 

Thanks,

Phil/=20  

------_=_NextPart_001_01C816EC.26181EBF-- --===============0597437933== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============0597437933==--