RE: [PCN] PCN & tunnelling

Phil,

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?

Regards,

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,

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

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. 

- 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). 

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. 

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]. 

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. 

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.

phil

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

Phil,

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. 

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.

Regards,

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,

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/  