Subject: Determining the Network Layer Protocol

From: "Li, Renwei" <[email-masked]>
Date: Mon, 18 Sep 2000 09:25:09 -0700

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: David Charlap <[email-masked]>
Date: Mon, 18 Sep 2000 13:21:38 -0400

"Li, Renwei" wrote:
> 
> 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.

When RSVP-TE is used to signal label distribution, this information is
sent from the ingress node to the egress node as a part of the
label-request object.

I would be surprised if CR-LDP doesn't have a similar mechanism in it.

-- David

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 18 Sep 2000 14:58:14 -0400

David and Renwei,

>I would be surprised if CR-LDP doesn't have a similar mechanism in it.

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.

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

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 18 Sep 2000 15:45:49 -0400

In message <[email-masked]>, "Li
> layer protocol is not specified in the MPLS label stack or any of its lower

See draft-ietf-mpls-rsvp-lsp-tunnel-07.txt section 4.2 starting on
page 20.  Generic format below, formats for ATM and FR on the
following pages.

Curtis

4.2. Label Request Object

   The Label Request  Class  is  19.   Currently  there  three  possible
   C_Types.  Type 1 is a Label Request without label range.  Type 2 is a
   label request with an ATM label range.  Type 3  is  a  label  request
   with a Frame Relay label range.  The LABEL_REQUEST object formats are
   shown below.

4.2.1. Label Request without Label Range

      Class = 19, C_Type = 1

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Reserved            |             L3PID             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Reserved

         This field is reserved. It MUST be set to zero on transmis-
         sion and MUST be ignored on receipt.

      L3PID

         an identifier of the layer 3 protocol using this path.
         Standard Ethertype values are used.

---

From: Dimitri Stratton Vlachos <[email-masked]>
Date: Wed, 20 Sep 2000 12:22:54 -0400

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

>Andy

------
"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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 20 Sep 2000 13:31:29 -0400

Dimitri,

>problem occurs, the router will not know the payload as it was not 
>involved in the negotiation of the VC label.

That's intentional.  The router in the middle of the tunnel has no need to 
know what kind of data is being carried in the interior LSPs, it just needs 
to know the tunnel characteristics that were signaled to it via RSVP-TE or 
CR-LDP.  It's just the inner LSP termination points that need to know what 
to do with the packet contents.  Things scale much better this way.

Of course, if the service provider in the middle has a honking big LSR and 
wants to run Carnivore or some such on it, then I suppose there's nothing 
conceptually keeping it from snooping on every packet run through the 
tunnel and tracking the state and contents of every interior LSP it sees 
signaled. :-)

Cheers,
Andy

---

From: Dimitri Stratton Vlachos <[email-masked]>
Date: Wed, 20 Sep 2000 14:47:36 -0400

At 01:31 PM 9/20/00 -0400, Andrew G. Malis wrote:
>know what kind of data is being carried in the interior LSPs, it just 
>needs to know the tunnel characteristics that were signaled to it via 
>RSVP-TE or CR-LDP.  It's just the inner LSP termination points that need 
>to know what to do with the packet contents.  Things scale much better 
>this way.

I agree my main point is that the prior emails on this thread seemed to be 
implying that exception processing for a given LSP will always know what 
type of traffic is flowing over the LSP at LSP setup time and this is not 
always the case.

------