The MPLS WG Archive

[Anoop Ghanwani <anoop@cosinecom.com>]

Title: RE: MPLS Label Stack Encoding

> -----Original Message-----
> From: Mark Stewart [mailto:Mstewart@nexen.com]
> Sent: Monday, November 20, 2000 11:56 AM
> To: mpls@UU.NET
> Subject: MPLS Label Stack Encoding
>
>
> Hi All
>
> "draft-ietf-mpls-label-encaps-08.txt"  defines distinct
> protocol/ethertype fields for MPLS unicast and MPLS
> multicast. I find it
> strange to add address space information to the protocol type
> field, and
> am curious if someone can clarify why this separation of label spaces
> was mandated?

One of the reasons (not a good one, though :-)) is that
it increases the label space.  By using different Ethertypes
we have twice the number of labels if we use lots of unicast
and multicast.

The more compelling reason is the following.  Unicast labels can
be managed on a per-interface basis by the router assigning
the labels.  OTOH, for multicast case, once a label value has
been assigned by a router on a LAN, no other router on that
LAN can assign the same label.  See Section 2.2.1 of
http://www.ietf.org/internet-drafts/draft-farinacci-mpls-multicast-02.txt
for more explanation about this problem.  If we wanted to use
the same Ethertype for both unicast and multicast labels,
we would have to worry about some sort of inter-router
partitioning of the label space right from the beginning.
Now we can punt the issue to the time when MPLS-based
multicasting becomes important :-) 
 
> Further I am curious as to what constitutes an MPLS multicast
> packet in
> this case. Does it apply on a specific hop, or must the multicast
> property be preserved end to end?
>
> Can a multicast packet be tunneled through a unicast LSP?

I'm not an expert on multicast, but I don't see why not.
An MPLS unicast tunnel should be just like any other tunnel.
Once you get to the end of the tunnel, the egress router would
strip off of the (unicast) label, and do a destination
IP address lookup for the multicast packet.

-Anoop