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/  