Re: [mpls] Question about 0x8848 Ethertype
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [mpls] Question about 0x8848 Ethertype



Hi Eric,

Do you know why such restriction for unicast exist? Why didn't the standard let unicast Ethernet carrying upstream-assigned label also use 0x8848? 

What should a system that receives a Unicast Ethernet frame with Ethertype 0x8848 do? Should the packet be dropped?

Regards,
Shahram

-----Original Message-----
From: Shahram Davari 
Sent: Thursday, October 22, 2009 12:28 PM
To: erosen at cisco.com
Cc: Nitin Bahadur; mpls at ietf.org
Subject: RE: [mpls] Question about 0x8848 Ethertype

Hi Eric,

Thanks for your clarifications.

Regards,
Shahram 

-----Original Message-----
From: Eric Rosen [mailto:erosen at cisco.com] 
Sent: Thursday, October 22, 2009 12:21 PM
To: Shahram Davari
Cc: Nitin Bahadur; mpls at ietf.org
Subject: Re: [mpls] Question about 0x8848 Ethertype


Nitin's interpretation matches the intention of the text.

If the ethertype of an ethernet frame is 8848:

- The top label is to be looked up an interface-specific label space that is
  populated by the context labels in use on the LAN.  Each such label must
  uniquely correspond to an LSR on the LAN.

- As a result of making this lookup, you identify a second label space, one
  that is specific to the LSR that transmitted the frame.  This label space
  is populated by the labels that have been upstream-assigned by that LSR.

If the ethertype is 8847, the top label is an ordinary downstream-assigned
label, looked up in a label space populated by the downstream-assigned
labels of the LSR that receives the frame.

The above mentions three different label spaces; all label uniqueness
requirements are relative to a particular label space.

> How will a node receiving a unicast packet can identify whether the top
> label is upstream assigned or downstream assigned?

Per the standards, there is no way of using upstream-assigned labels in
unicast ethernet frames.  





Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.