Subject: [PCN] PCN architecture new section on tunnelling

From: <[email-masked]>
Date: Wed, 8 Aug 2007 23:14:11 +0100

This is to flag up that I wrote a new sub-section (in Section 5,
Detailed functional architecture) about tunelling:

5.8.  Tunnelling

   It is possible that tunnels terminate at a PCN-node.  It is important

   that any PCN-marking is preserved after decapsulation, so that it is

   still seen by the PCN-egress-node.  To ensure this, on decapsulation

   the following rules are applied:

   o  the PCN-marking state of the inner and outer headers are compared

   o  if the inner header's marking state is more severe then it is

      preserved

   o  if the outer header's marking state is more severe then it is

      copied onto the inner header

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

   Similarly, if encapsulation is done within the PCN-domain, then the

   following rule is applied:

   o  any PCN-marking is copied into the outer header

   Tunnelling considerations also depend on which header bits the PCN WG

   decides to use.  If the ECN bits are used then

   [I-D.briscoe-tsvwg-ecn-tunnel] applies; the rules above conform to

   its spirit.  If the DSCP field is used then [RFC2983] needs to be

   considered carefully.

   An operator may wish to tunnel PCN-traffic from PCN-ingress-nodes to

   PCN-egress-nodes, in which case the rules above aren't needed.  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: additional overhead in terms of bandwidth and processing;

   and the effective elimination of ECMP as a load balancing mechanism.

_______________________________________________
PCN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pcn

---

From: "Jozef Babiarz" <[email-masked]>
Date: Tue, 14 Aug 2007 14:16:33 -0400

Phil, please see my comment below demarked with [Joe].

Regards, Joe 
email:[email-masked] 
Telephone:613-763-6098 

________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: August 8, 2007 6:14 PM
To: [email-masked]
Subject: [PCN] PCN architecture new section on tunnelling

5.8.  Tunnelling

      preserved

      rate)

*         any PCN-marking is copied into the outer header

[Joe] The above may introduce unnecessary information leakage. Why not
just at the encapsulation point mark all packets as unmarked. The
decapsulation point can sort them out. Just realizes that excess rate
marking approach will not work unless PCN-marking information is copied
from inner to outer headers when encapsulating. [end]

[Joe] I'm assuming for time being that "PCN nonce" (similar to ECN
nonce) is out of scope as we are not sure if it's need for PCN. If not
than the "PCN nonce" would also need to be copied to outer header. [end]

   considered carefully.

---

From: Michael Menth <[email-masked]>
Date: Tue, 14 Aug 2007 23:51:46 +0200

Hi,

Imagine a packet is tunneled from node A to some other node B, it is 
decapsulated there and forwarded to destination C. Then, the traffic 
takes the route from A over B to C.
1st problem: how do we find the ingress node X of the packet at its PCN 
egress Y?
2nd problem: provided that we know the ingress node X, the path from A 
over B to C does not necessarily coincide with normal IP routed path 
from the corresponding PCN ingress X to egress Y. If those packets are 
admission marked, they may cause admission stop for traffic from X to Y 
although they take a different path.

Thus, the problem is that we associate the admission-stop-marking with 
the path from the ingress to the egress of the packet. If the packet 
took a different path than by typical IP routing, the interpretation of 
the PCN information is leads to the wrong conclusions. Similar problems 
occur with excess-traffic-marked packets if the corresponding PCN 
information is associated with the path. The marked flow termination 
(MFT) from the 3sm-draft associates the marking with the flow and can 
cope well with arbitrarily routed flows.

Possible solution: the marking from X to B needs to be evaluated at B 
and be associated with the path from X to B, and the marking received 
from B to Y needs to be evaluated at Y and be associated with the path 
from B to Y.

I just want to say: tunneling with tunnel endpoints in PCN networks is 
not yet understood.

Best wishes,

Michael

Jozef Babiarz wrote:
> /Regards, Joe/
> ------------------------------------------------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]]
> *Sent:* August 8, 2007 6:14 PM
> *To:* [email-masked]
> *Subject:* [PCN] PCN architecture new section on tunnelling
>
> · any PCN-marking is copied into the outer header
>
> marking approach will not work unless PCN-marking information is 
> copied from inner to outer headers when encapsulating. [end]
>
> [Joe] I’m assuming for time being that “PCN nonce” (similar to ECN 
> nonce) is out of scope as we are not sure if it’s need for PCN. If not 
> than the “PCN nonce” would also need to be copied to outer header. [end]
>
> ------------------------------------------------------------------------
>

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: "Jozef Babiarz" <[email-masked]>
Date: Wed, 15 Aug 2007 16:14:26 -0400

See my comments below demarked with [Joe]

Regards, Joe
email:[email-masked]
Telephone:613-763-6098

-----Original Message-----
From: Michael Menth [mailto:[email-masked]] 
Sent: August 14, 2007 5:52 PM
To: Babiarz, Jozef (CAR:0S03)
Cc: [email-masked]; [email-masked]
Subject: Re: [PCN] PCN architecture new section on tunnelling

Hi,

[Joe] One possible approach is to use a probe method something like.
PCN-ingress node using the IP header information of the flow to be
admitted generates and sends probe packets that can easily be detected
by the PCN-egress-node (in your case node C). The sent probe packets
contain as payload the address of the PCN-ingress-node so that the
PCN-egress-node knows where to send the pre-congestion information for
that flow. [end]

2nd problem: provided that we know the ingress node X, the path from A 
over B to C does not necessarily coincide with normal IP routed path 
from the corresponding PCN ingress X to egress Y.

[Joe] It will coincide if the IP header information of the probe packet
is the same as media packet if admitted. By IP header information I
mean, source/destination IP address, source/destination port numbers,
protocol ID and DSCP value. The source/destination IP address, etc. is
that of endpoints and not boundary nodes that originate or consume probe
packets.[end]

 If those packets are 

Possible solution: the marking from X to B needs to be evaluated at B 
and be associated with the path from X to B, and the marking received 
from B to Y needs to be evaluated at Y and be associated with the path 
from B to Y.
[Joe] Not sure way the marking at B needs to be evaluated? At the
decapsulation point B, if the outer header's marking state is more
severe then it is copied onto the inner header. [end]

Best wishes,

Michael

---

From: Michael Menth <[email-masked]>
Date: Thu, 16 Aug 2007 23:35:54 +0200

Hi Joe and all,

> PCN-egress-node knows where to send the pre-congestion information for

Usually, probes are simple packets. A probe from A is destined to B. 
Decapsulation at B does not work for the probe packet. If a tunnelled IP 
packet enters the PCN ingress A, then the probe needs to mimic this. I 
guess tunneling will be tricky with PCN.

> that of endpoints and not boundary nodes that originate or consume probe

Again, when tunneled IP packets enter the PCN domain, this poses 
additional challenges on probing as there are several stacked headers to 
be mimicked. Maybe there are other, simpler solutions.

In any case: probing and marked flow termination guarantees that the 
admission and termination decision is associated with the right path 
which is not trivial with tunneling.

Regards,

    Michael

>> than the "PCN nonce" would also need to be copied to outer header.
>>     
> [end]
>

---

From: [email-masked]
Date: Sat, 18 Aug 2007 14:37:46 -0400

Joe,

[DLB] The copying can simplify dealing with the various headers.  If the

PCN marking is always in the outermost header (copied out on ingress,
copied

in on egress), then dealing with PCN marking is orthogonal to tunnel
encap/

decap, and in particular, the right thing happens if a tunnel crosses a
PCN

boundary and has its egress in the middle of a PCN domain.  This is
related

to RFC 2983's uniform model for dealing with diffserv and tunnels, and
some

of the tunnel discussion in RFC 3270 (MPLS and diffserv) may also be
useful

to review (not because MPLS and PCN ought to be in scope, but rather
because

Francois and the RFC 3270 co-authors did a fine job of exploring the

implications of the uniform and pipe models in RFC 3270 to the next
levels

of detail.

Thanks,

--David

---------------------------------------------------- 
David L. Black, Senior Technologist 
EMC Corporation, 176 South St., Hopkinton, MA  01748 
+1 (508) 293-7953             FAX: +1 (508) 293-7786 
[email-masked]        Mobile: +1 (978) 394-7754 
---------------------------------------------------- 

	From: Jozef Babiarz [mailto:[email-masked]] 
	Sent: Tuesday, August 14, 2007 2:17 PM
	To: [email-masked]; [email-masked]
	Subject: RE: [PCN] PCN architecture new section on tunnelling

	Regards, Joe 
	email:[email-masked] 
	Telephone:613-763-6098 

	5.8.  Tunnelling

	   It is possible that tunnels terminate at a PCN-node.  It is
important

	   that any PCN-marking is preserved after decapsulation, so
that it is

	   still seen by the PCN-egress-node.  To ensure this, on
decapsulation

	   o  the PCN-marking state of the inner and outer headers are
compared

	   o  if the inner header's marking state is more severe then it
is

	      preserved

	   o  if the outer header's marking state is more severe then it
is

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

	   Similarly, if encapsulation is done within the PCN-domain,
then the

	[Joe] The above may introduce unnecessary information leakage.
Why not just at the encapsulation point mark all packets as unmarked.
The decapsulation point can sort them out. Just realizes that excess
rate marking approach will not work unless PCN-marking information is
copied from inner to outer headers when encapsulating. [end]

	[Joe] I'm assuming for time being that "PCN nonce" (similar to
ECN nonce) is out of scope as we are not sure if it's need for PCN. If
not than the "PCN nonce" would also need to be copied to outer header.
[end] 

	   Tunnelling considerations also depend on which header bits
the PCN WG

	   [I-D.briscoe-tsvwg-ecn-tunnel] applies; the rules above
conform to

	   its spirit.  If the DSCP field is used then [RFC2983] needs
to be

	   considered carefully.

	   An operator may wish to tunnel PCN-traffic from
PCN-ingress-nodes to

	   PCN-egress-nodes, in which case the rules above aren't
needed.  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: additional overhead in terms of bandwidth and
processing;

	   and the effective elimination of ECMP as a load balancing
mechanism.

---

From: <[email-masked]>
Date: Mon, 20 Aug 2007 09:45:38 +0100

Michael

Good points. To me your tunnelling analysis is another example of
multi-path; like ECMP it's quite tricky for PCN. 

for flow termination, this can be solved by terminating flows that are
actually marked (3sm-draft is one example, the Briscoe-cl-architecture
gave another). 

For adm ctrl, the solutions seem to be: 
- tunnel all traffic between PCN-ingress-node and PCN-egress-node (I
think this works for your tunnelling examples as well as for ECMP)
- accept the adm decision is approximate; 
- do probing for each flow admission

in terms of knowing what the PCN-ingress-node is (so that you know where
to do policing to enforce the adm decision), wouldn't this still be done
at the signalling level? I suppose the question is then what happens if
eg rsvp is tunnelled?

phil

> Sent: 14 August 2007 22:52
> To: Jozef Babiarz
> Cc: Eardley,PL,Philip,CXR9 R; [email-masked]
[end]
PCN-ingress-node

---

From: <[email-masked]>
Date: Thu, 30 Aug 2007 18:17:15 +0100

Thanks - I'll add some explanation to the draft.

Also in the next version of the draft I'll add a note that the RFCs you
mention should be explored in more detail [unless of course someone does
this exploration before then]

phil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 18 August 2007 19:38
To: [email-masked]; [email-masked]
Subject: RE: [PCN] PCN architecture new section on tunnelling

Joe,

of the tunnel discussion in RFC 3270 (MPLS and diffserv) mayalso be
useful

Francois and the RFC 3270 co-authors did a fine jobof exploring the

of detail.

Thanks,

--David

	

	Regards, Joe 
	email:[email-masked] 
	Telephone:613-763-6098 

	5.8.  Tunnelling

	      preserved

	      rate)

	   considered carefully.

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 31 Aug 2007 08:45:55 +0200

Phil,

is the mentioned "knowing what the PCN-ingress-node is, done 
at the signaling level" described in more detail in one of 
the documents already?

RSVP is not supposed to be tunneled to all places. If a PCN 
related RSVP message is tunneled through a PCN ingress router, 
the tunnel terminates in the middle of a PCN domain and the 
RSVP message continues through a PCN domain egress, I'd 
regard this as a security incident. May be the message should 
simply be ignored - dropping is another alternative. The 
possibility to insert RSVP (or other signaling messages) that 
way requires authentication for the signaling between PCN 
ingress and egress nodes.

Regards,

Ruediger

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]]
|Sent: Monday, August 20, 2007 10:46 AM
|To: [email-masked]; [email-masked]
|Cc: [email-masked]
|Subject: RE: [PCN] PCN architecture new section on tunnelling
|
|
|Michael
|
|Good points. To me your tunnelling analysis is another example of
|multi-path; like ECMP it's quite tricky for PCN. 
|
|for flow termination, this can be solved by terminating flows that are
|actually marked (3sm-draft is one example, the Briscoe-cl-architecture
|gave another). 
|
|For adm ctrl, the solutions seem to be: 
|- tunnel all traffic between PCN-ingress-node and PCN-egress-node (I
|  think this works for your tunnelling examples as well as for ECMP)
|- accept the adm decision is approximate; 
|- do probing for each flow admission
|
|in terms of knowing what the PCN-ingress-node is (so that you 
|know where to do policing to enforce the adm decision), wouldn't 
|this still be done at the signalling level? I suppose the 
|question is then what happens if eg rsvp is tunnelled?
|
|phil
|
|> -----Original Message-----
|> From: Michael Menth [mailto:[email-masked]]
|> Sent: 14 August 2007 22:52
|> To: Jozef Babiarz
|> Cc: Eardley,PL,Philip,CXR9 R; [email-masked]
|> Subject: Re: [PCN] PCN architecture new section on tunnelling
|> 
|> Hi,
|> 
|> Imagine a packet is tunneled from node A to some other node B, it is
|> decapsulated there and forwarded to destination C. Then, the traffic
|> takes the route from A over B to C.
|> 1st problem: how do we find the ingress node X of the packet at its
|PCN
|> egress Y?
|> 2nd problem: provided that we know the ingress node X, the 
|path from A
|> over B to C does not necessarily coincide with normal IP routed path
|> from the corresponding PCN ingress X to egress Y. If those 
|packets are
|> admission marked, they may cause admission stop for traffic from X to
|Y
|> although they take a different path.
|> 
|> Thus, the problem is that we associate the 
|admission-stop-marking with
|> the path from the ingress to the egress of the packet. If the packet
|> took a different path than by typical IP routing, the interpretation
|of
|> the PCN information is leads to the wrong conclusions. Similar
|problems
|> occur with excess-traffic-marked packets if the corresponding PCN
|> information is associated with the path. The marked flow termination
|> (MFT) from the 3sm-draft associates the marking with the flow and can
|> cope well with arbitrarily routed flows.
|> 
|> Possible solution: the marking from X to B needs to be evaluated at B
|> and be associated with the path from X to B, and the marking received
|> from B to Y needs to be evaluated at Y and be associated 
|with the path
|> from B to Y.
|> 
|> I just want to say: tunneling with tunnel endpoints in PCN 
|networks is
|> not yet understood.
|> 
|> Best wishes,
|> 
|> Michael
|> 
|> Jozef Babiarz wrote:
|> >
|> > Phil, please see my comment below demarked with [Joe].
|> >
|> > /Regards, Joe/
|> > email:[email-masked]
|> > Telephone:613-763-6098
|> >
|> >
|---------------------------------------------------------------
|---------
|> >
|> > *From:* [email-masked] [mailto:[email-masked]]
|> > *Sent:* August 8, 2007 6:14 PM
|> > *To:* [email-masked]
|> > *Subject:* [PCN] PCN architecture new section on tunnelling
|> >
|> > This is to flag up that I wrote a new sub-section (in Section 5,
|> > Detailed functional architecture) about tunelling:
|> >
|> > 5.8. Tunnelling
|> >
|> > It is possible that tunnels terminate at a PCN-node. It is 
|important
|> >
|> > that any PCN-marking is preserved after decapsulation, so 
|that it is
|> >
|> > still seen by the PCN-egress-node. To ensure this, on decapsulation
|> >
|> > the following rules are applied:
|> >
|> > o the PCN-marking state of the inner and outer headers are compared
|> >
|> > o if the inner header's marking state is more severe then it is
|> >
|> > preserved
|> >
|> > o if the outer header's marking state is more severe then it is
|> >
|> > copied onto the inner header
|> >
|> > o 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)
|> >
|> > Similarly, if encapsulation is done within the PCN-domain, then the
|> >
|> > following rule is applied:
|> >
|> > * any PCN-marking is copied into the outer header
|> >
|> > [Joe] The above may introduce unnecessary information leakage. Why
|not
|> > just at the encapsulation point mark all packets as unmarked. The
|> > decapsulation point can sort them out. Just realizes that excess
|rate
|> > marking approach will not work unless PCN-marking information is
|> > copied from inner to outer headers when encapsulating. [end]
|> >
|> > [Joe] I'm assuming for time being that "PCN nonce" (similar to ECN
|> > nonce) is out of scope as we are not sure if it's need for PCN. If
|not
|> > than the "PCN nonce" would also need to be copied to outer header.
|[end]
|> >
|> > Tunnelling considerations also depend on which header bits the PCN
|WG
|> >
|> > decides to use. If the ECN bits are used then
|> >
|> > [I-D.briscoe-tsvwg-ecn-tunnel] applies; the rules above conform to
|> >
|> > its spirit. If the DSCP field is used then [RFC2983] needs to be
|> >
|> > considered carefully.
|> >
|> > An operator may wish to tunnel PCN-traffic from 
|PCN-ingress-nodes to
|> >
|> > PCN-egress-nodes, in which case the rules above aren't needed. 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: additional overhead in terms of bandwidth and 
|processing;
|> >
|> > and the effective elimination of ECMP as a load balancing 
|mechanism.
|> >
|> >
|---------------------------------------------------------------
|---------
|> >
|> > _______________________________________________
|> > PCN mailing list
|> > [email-masked]
|> > https://www1.ietf.org/mailman/listinfo/pcn
|> >
|> 
|> --
|> Dr. Michael Menth, Assistant Professor
|> University of Wuerzburg, Institute of Computer Science
|> Am Hubland, D-97074 Wuerzburg, Germany, room B206
|> phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
|> mailto:[email-masked]
|> http://www3.informatik.uni-wuerzburg.de/research/ngn
|
|
|
|_______________________________________________
|PCN mailing list
[email-masked]
|https://www1.ietf.org/mailman/listinfo/pcn
|