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]