RE: [PCN] PCN architecture new section on tunnelling

[<[e-mail]>]

Ruediger,
In-line - thanks
phil

> -----Original Message-----
> From: Geib, Ruediger [mailto:[e-mail]]
> Sent: 31 August 2007 07:46
> To: Eardley,PL,Philip,CXR9 R
> Cc: [e-mail]
> Subject: RE: [PCN] PCN architecture new section on tunnelling
> 
> 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?

[phil]
http://www.watersprings.org/pub/id/draft-lefaucheur-rsvp-ecn-01.txt [&
http://www.watersprings.org/pub/id/draft-briscoe-tsvwg-cl-architecture-0
4.txt] - I think try to do this, with rsvp as the signalling example
> 
> 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.

[phil] yes you're right. in this case where the ingress doesn't see the
rsvp msg, then presumably adm ctrl isn't triggered so the flow wouldn't
be admitted. 

> 
> Regards,
> 
> Ruediger
> 
> |-----Original Message-----
> |From: [e-mail] [mailto:[e-mail]]
> |Sent: Monday, August 20, 2007 10:46 AM
> |To: [e-mail]; [e-mail]
> |Cc: [e-mail]
> |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:[e-mail]]
> |> Sent: 14 August 2007 22:52
> |> To: Jozef Babiarz
> |> Cc: Eardley,PL,Philip,CXR9 R; [e-mail]
> |> 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:[e-mail]
> |> > Telephone:[phone]
> |> >
> |> >
> |---------------------------------------------------------------
> |---------
> |> >
> |> > *From:* [e-mail] [mailto:[e-mail]]
> |> > *Sent:* August 8, 2007 6:14 PM
> |> > *To:* [e-mail]
> |> > *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
> |> > [e-mail]
> |> > 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: [phone], fax: [phone]
> |> mailto:[e-mail]
> |> http://www3.informatik.uni-wuerzburg.de/research/ngn
> |
> |
> |
> |_______________________________________________
> |PCN mailing list
> |[e-mail]
> |https://www1.ietf.org/mailman/listinfo/pcn
> |


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