Subject: Query on draft-ietf-mpls-label-encaps

From: "Sudhanshu Jain" <[email-masked]>
Date: Wed, 11 Oct 2000 19:49:00 -0700

Hi All,
   In draft-ietf-mpls-label-encaps-08.txt, in section 2.1 language has been
   changed to ....

              i. A value of 0 represents the "IPv4 Explicit NULL Label".
                 This label value is only legal at the bottom of the
                 label stack.  It indicates that the label stack must be
                 popped, and the forwarding of the packet must then be
                 based on the IPv4 header.

   From draft-ietf-mpls-label-encaps-07.txt, in section 2.1 ....

              i. A value of 0 represents the "IPv4 Explicit NULL Label".
                 This label value is only legal when it is the sole
                 label stack entry.  It indicates that the label stack
                 must be popped, and the forwarding of the packet must
                 then be based on the IPv4 header.

  Same stands for the bullet (iii).

  Does it mean, Label 0 and Label 2 are used to carry Protocol type 
  at the "bottom of the label stack" in case of tunnel traffic? 

  Is it the standard way to carry the protocol type in MPLS Tunnel traffic?

Thanks,
-Sudhanshu

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 11 Oct 2000 23:54:46 -0400

In message <[email-masked]>, "Sudhanshu Jain"
 writes:
> This is a multi-part message in MIME format.
> 
> ------=_NextPart_000_0188_01C033BC.4D01B680
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
> 
> Hi All,
>    In draft-ietf-mpls-label-encaps-08.txt, in section 2.1 language has =
> been
>    changed to ....
> 
>  =20
>   Does it mean, Label 0 and Label 2 are used to carry Protocol type=20
>   at the "bottom of the label stack" in case of tunnel traffic?=20
> 
>   Is it the standard way to carry the protocol type in MPLS Tunnel =
> traffic?
> 
> Thanks,
> -Sudhanshu

Sudhanshu,

The last phrase in this paragraph should be reworded to say that it
will be forwarded based on the protocol type specified in the L3PID
when the tunnel was set, for example IPv4 or IPv6.

Note to authors:

  Remove the last the words, "on the IPv4 header" and replace with "on
  the underlying payload's header".  You could also add a sentence
  "The protocol type of the underlying header is determined by
  signaling that occurs at LSP setup time".

The use of L3PID to determine payload protocol identifier is
definitely a good candidate for an FAQ.  The signaling of L3PID is
specified in section 4.2 of draft-ietf-mpls-rsvp-lsp-tunnel-07.txt.

Curtis

---

From: "Sudhanshu Jain" <[email-masked]>
Date: Thu, 12 Oct 2000 10:42:43 -0700

Hi Curtis,

Thanks for the response.

L3PID is the what used in setting up tunnel which are protocol aware.

But if a tunnel is being setup as a fat pipe, ( e.g. L3PID is not present at
setup time).

Is it possible for such a tunnel to carry multiprotocols via using 0 or 2
label at the bottom of the stack?

Is there any existing implementation which carry multi protocol over single
tunnel? If so, how do they carry protocol information end-to-end?

Thanks,
-Sudhanshu

----- Original Message -----
From: Curtis Villamizar <[email-masked]>
To: Sudhanshu Jain <[email-masked]>
Cc: <[email-masked]>; Yakov Rekhter <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, October 11, 2000 8:54 PM
Subject: Re: Query on draft-ietf-mpls-label-encaps

---

From: Eric Rosen <[email-masked]>
Date: Thu, 12 Oct 2000 16:38:58 -0400

> Does it mean, Label  0 and Label 2 are used to  carry Protocol type at the
> "bottom of the label stack" in case of tunnel traffic?  

No, the cited paragraph means neither  more nor less than it says.  There is
no requirement that the bottom of  the stack ever have an explicit null.  It
would not be legitimate to write code which presumes that it does.

> Is it the standard way to carry the protocol type in MPLS Tunnel traffic?

No.

---

From: David Charlap <[email-masked]>
Date: Fri, 13 Oct 2000 11:14:51 -0400

Sudhanshu Jain wrote:
> But if a tunnel is being setup as a fat pipe, ( e.g. L3PID is not
> present at setup time).
> 
> Is it possible for such a tunnel to carry multiprotocols via using 0
> or 2 label at the bottom of the stack?
> 
> Is there any existing implementation which carry multi protocol over
> single tunnel? If so, how do they carry protocol information
> end-to-end?

Doing this is very problematic.

Eventually, the data will have to leave the MPLS tunnel.  When it does,
some kind of L3PID information must exist, in order to place it in the
L2 header of the network beyond the tunnel.  If multiple packets in the
tunnel have different L3PIDs, how will the egress router be able to
properly generate the L2 header?

In the ATM world, wrappers like AAL5 are used to carry this kind of
information.

IMO, the only good way to carry multiple L3 protocols in a single LSP is
to wrap the packets in something that can carry the protocol ID on a
per-packet basis.

If such a thing would be done, then (from MPLS's perspective), the
tunnel would be carrying packets all of one type - the wrapper's type. 
Whatever code on the ingress/egress that exists to add/remove these
wrappers would then be responsible for preserving the per-packet L3PID
information.

(Is there a draft for this?  I don't know.  If people really want to run
multiple protocols in one tunnel, then such a draft would be useful so
that different implementations can interoperate.)

-- David

---

From: Grenville Armitage <[email-masked]>
Date: Fri, 13 Oct 2000 09:34:15 -0700

David Charlap wrote:
	[..]
> In the ATM world, wrappers like AAL5 are used to carry this kind of

AAL5 doesn't carry protocol muxing info per se, it requires additional
overhead such as LLC/SNAP headers. Which (as you correctly allude)
would solve the original poster's problem too.

cheers,
gja

---

From: Eric Rosen <[email-masked]>
Date: Mon, 16 Oct 2000 15:16:21 -0400

David> IMO, the only good way to carry multiple L3 protocols in a single LSP
David> is to wrap the packets in something that can carry the protocol ID on
David> a per-packet basis.

... 

David> (Is there a draft for this?  I don't know.  If people really want to run
David> multiple protocols in one tunnel, then such a draft would be useful so
David> that different implementations can interoperate.)

See, e.g, draft-martini-l2circuit-trans-mpls-03.txt.