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]