Internet Draft


Internet Engineering Task Force                   D. Bussiere, Cabletron
INTERNET DRAFT                                         H. Esaki, Toshiba
                                                        A. Ghanwani, IBM
                                                   S. Matsuzawa, Toshiba
                                                         J. W. Pace, IBM
                                                      V. Srinivasan, IBM
                                                             August 1997


                     Labels for MPLS over LAN Media

                draft-srinivasan-mpls-lans-label-00.txt


Status of This Memo

   This document is an Internet-Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months, and may be updated, replaced, or obsoleted by other documents
   at any time.  It is not appropriate to use Internet Drafts as
   reference material, or to cite them other than as a ``working draft''
   or ``work in progress.''

   To learn the current status of any Internet-Draft, please check
   the ``1id-abstracts.txt'' listing contained in the internet-drafts
   Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).


Abstract

   Multi Protocol Label Switching (MPLS) refers to a forwarding paradigm
   for routed networks which combines the speed and simplicity of link
   layer switching with the scalability and control of network layer
   forwarding.  Routers which support MPLS are referred to as Label
   Switching Routers (LSRs).  MPLS requires the distribution labels
   between peer LSRs based on routing and traffic information.  These
   labels are then carried in packets and are used for making high speed
   forwarding decisions at the routers by eliminating the need for
   conventional network layer header processing.  This note discusses
   the format and encapsulation of labels when using MPLS on LAN media.








Bussiere et al.              Expires February 1998              [Page i]

Internet Draft        Labels for MPLS over LAN Media         August 1997


1. Introduction

   The Multi Protocol Label Switching (MPLS) working group in the
   IETF is currently exploring methods for improving the forwarding
   efficiency of routed networks while retaining their scalability [1].
   Several proposals that address these issues have been submitted to
   the MPLS working group [3,4,5].  The MPLS paradigm requires that link
   layer packets carry labels which are used for indexing tables which
   enable fast IP forwarding at close to media speeds by minimizing the
   need for network-layer packet processing.  Routers which support
   MPLS are known as Label Switching Routers (LSRs).  Labels may be
   carried in different ways depending on the underlying link-layer
   technology.  Networks based on ATM technology, which is inherently
   a label swapping technology, lend themselves very well to this
   paradigm.  In this case, the label may be represented by a particular
   VPI/VCI value.  This is particularly efficient since switching in ATM
   is actually based on the contents of these fields.  Further, because
   ATM operates over point to point links only, the choice of a label
   may be based on a local decision.

   On the other hand, LAN switching technologies such as Ethernet, token
   ring, and FDDI are not inherently label swapping technologies.  As
   a consequence, a shim consisting of one or more 32-bit label stack
   entries inserted between the link-layer and the network-layer headers
   has been proposed as a means to convey the label information [2].
   The main drawback of using such an approach is that accessing the
   labels requires that the frames be processed by software, reducing
   the benefit offered by label switching.  Alternatively, hardware
   technology specific to label switching may be developed.  However,
   standardized devices incorporating this technology do not exist today
   and cannot be built until the MPLS standard becomes stable.

   This memo proposes a different approach for label switching on LAN
   media where the label is carried in the destination address portion
   of the frame.  Because of the broadcast nature of LAN technologies,
   labels must be unique within a given broadcast network.  The proposal
   makes it easy to leverage existing bridge hardware that conforms
   to the IEEE 802.1D standard [6].  Note that this proposal does not
   preclude use of a label stack.  It merely proposes an encapsulation
   for labels that allows leveraging of existing link layer switching
   infrastructure which is one of the goals of the work in the MPLS
   working group [1].

   The remainder of this note is organized as follows.  Section 2
   discusses the label format and its encapsulation in Ethernet/IEEE
   802.3 data frames.  In Section 3, the issue of label assignment is
   discussed.  Section 4 examines the issue of loop prevention.  Section
   5 concludes this note with a summary.



Bussiere et al.              Expires February 1998              [Page 1]

Internet Draft        Labels for MPLS over LAN Media         August 1997


2. Label Format and Encapsulation

   For LAN media such as Ethernet and token ring, the most desirable
   place to carry the label is in the destination MAC address field in
   the frame since forwarding decisions at the link layer are made based
   on the contents of this field.  By using the field for the label,
   we are able to ensure that existing hardware can easily be used for
   building an LSR. The proposed format for the 48 bit MAC based label
   is shown in the figure below:

       +--------------------+------------+---------+-----------+
       |    OUI Prefix (24) | Label (20) | CoS (3) | Stack (1) |
       +--------------------+------------+---------+-----------+

   Figure 1:  Proposed Label Format for MPLS on LAN Media.  The numbers
   in parenthesis indicates the size of each field in bits.

   The first 24 bits are the OUI prefix assigned by the IEEE. It is
   necessary to have to have a unique OUI for all labels to insure
   that no collisions occur between labels being used as MAC addresses
   and existing MAC addresses of devices.  This allows for LSRs to be
   interconnected by bridges/switches thereby allowing co-existence
   of bridged and routed protocols in the network which is a key
   requirement for LANs.

   The remaining 24 bits contain the Label, CoS, and Stack bits.  The
   Label is used for making forwarding decisions in an LSR. It indicates
   the next hop and any action that may need to be taken with respect to
   the label stack.  The CoS indicates the class of service with which
   the packet must be handled.  This can be used, for instance, to set
   the priority bits in the link layer header if the technology supports
   it.  The Stack bit indicates the presence of a label stack if any.
   Additional entries of the label stack may be encoded elsewhere in the
   frame, e.g.  between the link layer and network layer headers.  In
   the simplest LSR on a LAN, the CoS and Stack bits may be ignored from
   a functional standpoint if the corresponding functions are not being
   used.














Bussiere et al.              Expires February 1998              [Page 2]

Internet Draft        Labels for MPLS over LAN Media         August 1997


    +---------+----------+-------------------+-------------------------+
    | DA (48) |  SA (48) |  Type/Length (16) |  Data (variable length) |
    +---------+----------+-------------------+-------------------------+
        ||
        ||   Label is inserted as the destination address
        \/
    +-----------------+------------+---------+-----------+
    | OUI Prefix (24) | Label (20) | CoS (3) | Stack (1) |
    +-----------------+------------+---------+-----------+

   Figure 2:  Encapsulation of Labels in Ethernet/IEEE 802.3 Frames

   Figure 2 shows the encapsulation of a label within an Ethernet/IEEE
   802.3 frame.  Note that without a label stack, the frame remains
   exactly the same as a regular Ethernet/IEEE 802.3 data frame.
   Because the frame size remains unchanged, there will be no MTU
   violations and traditional bridges/switches can handle these frames
   normally.


3. Label Assignment

   Any of the methods for label allocation and distribution described in
   [1] may be used over LAN media.  For instance, with the egress-based
   scheme, when an LSR on a LAN receives a label in a setup message from
   a downstream next hop for a particular Stream (as defined in [1]), it
   generates a label and propagates the setup message with this label
   to all other LSRs on the LAN. As mentioned earlier, we also need to
   insure that every label is unique within a given broadcast domain.
   This requires that the label space be partitioned either statically
   or dynamically between LSRs in the same broadcast domain.  An LSR
   must be capable of swapping labels and must be capable of receiving
   traffic addressed to any of the labels assigned by it.

   The setup message is sent over the LAN with the label in the source
   address field of the MAC header.  This allows bridges/switches in
   the LAN to learn the label for future forwarding of frames that
   carry the label in the destination address field of the frame.  As
   long as labels are assigned in the manner outlined above, there is
   no possibility for incorrect/ambiguous learning of MAC addresses by
   bridges/switches on the LAN.


4. Loop Prevention

   Every IP datagram includes a Time to Live (TTL) field which prevents
   a looping packet from staying in the network forever.  This field is
   required to be processed at every router visited by the packet.  The



Bussiere et al.              Expires February 1998              [Page 3]

Internet Draft        Labels for MPLS over LAN Media         August 1997


   proposed label format does not, however, include a TTL since this
   would simply be duplication of information already present in the
   network layer header of the frame.  Transient loops may occur at the
   network layer due to routing table inconsistencies.  When these label
   switched paths (LSPs) are established at the link layer using MPLS
   mechanisms, these loops become a problem.  This is true when MPLS is
   used with technologies such as such as ATM as well since the label
   carried in the VPI/VCI portion of the cell header does not include
   a TTL either.  Clearly then a loop prevention scheme that will
   eliminate the possibility of LSPs with loops is essential This is a
   major issue and is currently a work item in the MPLS working group.
   It is recommended that the approach designed by the MPLS working
   group be used in order to guarantee an LSP is loop free before it is
   set up.


5. Summary

   This note discusses the label format and encapsulation for MPLS over
   LAN media.  The proposed encapsulation encodes the label within the
   destination MAC address field of data frames insuring that frame
   sizes are not affected by carrying a label in the frame.  Further,
   with this proposal, existing bridge/switch hardware can easily be
   leveraged for building an LSR.


References

[1]  R. Callon et al., "A Framework for Multi Protocol Label Switching,"
  <draft-ietf-mpls-framework-00.txt>, work in progress, July 1997.

[2]  E. Rosen et al., "Label Switching,: Label Stack Encodings,"
  <draft-rosen-tag-stack-02.txt>, work in progress, June 1997.

[3]  A. Viswanathan et al., "ARIS: Aggregate Route-Based IP Switching,"
  <draft-viswanathan-aris-overview-00.txt>,  work in progress,
  March 1997.

[4]  Y. Rekhter et al., "Tag Switching Architecture - Overview,"
  <draft-rekhter-tagswitch-arch-00.txt>, work in progress,
  January 1997.

[5]  K. Nagami et al., "Flow Attribute Notification Protocol
  (FANP) Specification," <draft-rfced-info-nagami-00.txt>,
  work in progress, February 1997.

[6]  IEEE Standards for Local and Metropolitan Area Networks:
  Media Access Control Bridges, 1993.



Bussiere et al.              Expires February 1998              [Page 4]

Internet Draft        Labels for MPLS over LAN Media         August 1997


Acknowledgements

   The authors gratefully acknowledge input from Steven Blake.


Authors' Address

    Dick Bussiere
    Cabletron Systems
    40 Continental Blvd
    Merrimack, NH 03054
    Phone: +1-603-337-5136
    Email: bussiere@ctron.com

    Hiroshi Esaki
    Toshiba Corporation
    1-1-1 Shibaura, Minato-ku,
    Tokyo, 105-01, Japan
    Phone: +81-3-3457-2563
    Fax:   +81-3-5444-9441
    Email: hiroshi@isl.rdc.toshiba.co.jp

    Anoop Ghanwani
    IBM Corporation
    P. O. Box 12195
    Research Triangle Park, NC 27709
    Phone: +1-919-254-0260
    Fax:   +1-919-254-5410
    Email: anoop@raleigh.ibm.com

    Shigeo Matsuzawa
    R & D Center, Toshiba Corporation
    1 Komukai-Toshiba-cho, Saiwai-ku,
    Kawasaki, 210, Japan
    Phone: +81-44-549-2238
    Fax:   +81-44-520-1806
    Email: shigeom@isl.rdc.toshiba.co.jp

    Wayne Pace
    IBM Corporation
    P. O. Box 12195
    Research Triangle Park, NC 27709
    Phone: +1-919-254-4930
    Fax:   +1-919-254-5410
    Email: pacew@raleigh.ibm.com

    Vijay Srinivasan
    IBM Corporation



Bussiere et al.              Expires February 1998              [Page 5]

Internet Draft        Labels for MPLS over LAN Media         August 1997


    P. O. Box 12195
    Research Triangle Park, NC 27709
    Phone: +1-919-254-2730
    Fax:   +1-919-254-5410
    Email: vijay@raleigh.ibm.com














































Bussiere et al.              Expires February 1998              [Page 6]