Subject: RE: Determining the Network Layer Protocol

From: Eric Gray <[email-masked]>
Date: Mon, 18 Sep 2000 10:19:06 -0700

Renwei,

	LSPs are established using signaling and labels
are provided from downstream LSRs.  Therefore, it is
expected of a downstream LSR that it shouldn't provide
a label to an upstream LSR unless it knows how to
forward packets received using that label.  There are
two ways that it might "know" how to forward labeled
packets:

	1) it is the egress for the corresponding LSP and
	knows how to forward the packet as an L3 packet
	(for whatever L3 applies) or

	2) it has a corresponding label from a downstream 
	LSR peer that it can use in forwarding the packet
	to that peer.

Either way, labeled packets should eventually arrive at 
an egress LSR that knows what to do with them.

--
Eric Gray

> -----Original Message-----
> From: Li, Renwei [mailto:[email-masked]]
> Sent: Monday, September 18, 2000 9:25 AM
> To: [email-masked]'
> Subject: Determining the Network Layer Protocol
> 
> 
> After all labels are popped off or when some errors are 
> found, a networking
> device needs to process the network layer protocols. However, 
> the network
> layer protocol is not specified in the MPLS label stack or 
> any of its lower
> protocol headers. 
> 
> In the draft titled "MPLS Label Stack Encoding", some 
> inference tricks are
> presented. Basically, the draft suggests that some labels be 
> used only for
> packets of a particular network layer. On the other hand, in 
> MPLS Control
> Protocol for PPP connection, no configuration options are 
> provided. In LDP,
> CR-LDP, RSVP-LDP, no options are found to enable us to 
> specify some labels
> for a particular network layer. In ATM VP/VC encoding, no 
> standard way is
> provided to reserve some special VP/VC for a particular network layer
> protocol.
> 
> Note that no matter which inference trick is used by 
> following MPLS Label
> Stack Encoding, there is always an example so that one is 
> unable to infer
> the network layer protocol. 
> 
> Since MPLS is intended for MULTIPLE PROTOCOLS, I am wondering 
> why we don't
> just simply add one more field (maybe just one byte) in the 
> MPLS header (for
> example, the last entry in the label stack) to denote the 
> network layer
> protocol? Can the authors of the MPLS Label Stack Encoding or 
> somebody else
> explain why it is not done so? Any reasons for that? Any comments?
> 
> Thanks,
> 
> Renwei Li
> 
> Principal Technical Analyst
> Abatis Systems Corporation
> Phone: (604) 918-4706    
> Email:  [email-masked]
> 
> 
> 
>

---

From: [email-masked]
Date: Mon, 18 Sep 2000 19:07:49 +0100

Li, Renwei wrote Monday, September 18, 2000 5:25 PM

> After all labels are popped off or when some errors are found, a
> networking
> device needs to process the network layer protocols. However, the network
> layer protocol is not specified in the MPLS label stack or any of its
> lower
> protocol headers. 
	[Harrison,N,Neil,INC1 X]  <snip> 

> Since MPLS is intended for MULTIPLE PROTOCOLS, I am wondering why we don't
> just simply add one more field (maybe just one byte) in the MPLS header
> (for
> example, the last entry in the label stack) to denote the network layer
> protocol? Can the authors of the MPLS Label Stack Encoding or somebody
> else
	[Harrison,N,Neil,INC1 X]  This is important for a reason you have
not touched on.....but I will come back on that in a moment.

	Firstly, wrt to identification of the client layer
network-type........it is generally assumed that there is a long-term
temporal association between an LSP and its client payload for the duration
of the LSP's lifetime.  In other words it is assumed that there is no
multiplexing of the client payload.  With this assumption one does not need
a payload identifier.

	A problem arises however when one needs to introduce defect handling
procedures into MPLS.  I will not go into the detail here (several of us are
working on an ID where this detail will be given), but in essence we can
have potential connectivity failure mechanisms in MPLS that do not afflict
an IP layer, eg in addition to the well-known simple breaks and
self-mismerging (aka looping) defects, we might also see swapped connections
and mismerged (different) connections.  These arise since LSPs use relative
addressing, ie a label may only be interface unique.  To detect/diagnose
these types of connectivity failures one can periodically send a
'Connectivity Verification (CV)' packet from an LSP's source to its sink
which contains a unique trail source identifier (note - each IP packet
already effectively carries out this function since IP addresses are
network-wide unique).  With this functionality, however, the problem now is
the diffentiation of such a CV packet from normal user-plane traffic.

	A payload identifier in the LSP header would have been the ideal
solution, but this would be unlikely to have found favour with many (even a
minor revising the use of the TTL field would have done).  So we are likely
to require additional special labels to identify such OAM functions from
normal user-plane traffic....with the minor downside that this will increase
the label depth on the issue of such OAM packets.

	Regards, Neil

---

From: Eric Gray <[email-masked]>
Date: Wed, 20 Sep 2000 10:28:54 -0700

Dimitri,

	This concern comes up occasionally.  Most of
the people who have weighed in on this issue have
said that packets should be discarded if a tunnel
is broken in the middle - especially if the type of
traffic being transported is unknown to the router
at the point where the tunnel is broken.

	This is a transient condition since the fact
that the tunnel is broken will be signaled to the
tunnel "edge" points (not to raise a different re-
curring discussion) very shortly after the break.

--
Eric Gray

> From: Dimitri Stratton Vlachos [mailto:[email-masked]]
> Sent: Wednesday, September 20, 2000 9:23 AM
> To: Andrew G. Malis; David Charlap
> Cc: [email-masked]'
> Subject: Re: Determining the Network Layer Protocol
> 
> 
> 
> >draft-martini-l2circuit-trans-mpls-03.txt introduces a new LDP Virtual 
> >Circuit FEC TLV element for use with non-IP protocols carried over 
> >MPLS.  The protocol type is signaled in the TLV as a part of label
binding.
>
> However, in this draft there is essentially two levels of labels, a VC 
> label and then a "tunnel" label stack.  The mention you make above about 
> the protocol type being in the TLV is used for signalling only the VC 
> label.  So it is possible that in the middle of the "Tunnel" LSP if a 
> problem occurs, the router will not know the payload as it was not
involved 
> in the negotiation of the VC label.
> 
> 
> >Cheers,
> >Andy
> >
> >_____________________________________________________________
> ___________
> >Andrew G. Malis     [email-masked]     
> phone:408-383-7223
> >Vivace Networks/2730 Orchard Parkway/San Jose, CA 
> 95134/fax:408-904-4748
> >http://www.vivacenetworks.com
> >
> 
> ------
> "Advertising signs they con
>   You into thinking you're the one
>   That can do what's never been done
>   That can win what's never been won
>   Meanwhile life outside goes on all around you"
> 	       -Bob Dylan
> ---------------------------------------------------------------------
> Dimitri Stratton Vlachos                          [email-masked]
> Cisco Systems                                     Tel 978-244-8349
> IOS Layer 3 Services                              Fax 978-244-8126
> 250 Apollo Drive
> Chelmsford, Mass 01824
>