draft-ietf-mpls-label-encaps-07.txt   draft-ietf-mpls-label-encaps-08.txt 
Network Working Group Eric C. Rosen Network Working Group Eric C. Rosen
Internet Draft Yakov Rekhter Internet Draft Yakov Rekhter
Expiration Date: March 2000 Daniel Tappan Expiration Date: January 2001 Daniel Tappan
Dino Farinacci
Guy Fedorkow Guy Fedorkow
Cisco Systems, Inc. Cisco Systems, Inc.
Dino Farinacci
Tony Li Tony Li
Juniper Networks, Inc. Procket Networks, Inc.
Alex Conta Alex Conta
Lucent Technologies TranSwitch Corporation
September 1999 July 2000
MPLS Label Stack Encoding MPLS Label Stack Encoding
draft-ietf-mpls-label-encaps-07.txt draft-ietf-mpls-label-encaps-08.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 44 skipping to change at page 1, line 45
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
"Multi-Protocol Label Switching (MPLS)" [1,2] requires a set of "Multi-Protocol Label Switching (MPLS)" [1] requires a set of
procedures for augmenting network layer packets with "label stacks", procedures for augmenting network layer packets with "label stacks",
thereby turning them into "labeled packets". Routers which support thereby turning them into "labeled packets". Routers which support
MPLS are known as "Label Switching Routers", or "LSRs". In order to MPLS are known as "Label Switching Routers", or "LSRs". In order to
transmit a labeled packet on a particular data link, an LSR must transmit a labeled packet on a particular data link, an LSR must
support an encoding technique which, given a label stack and a support an encoding technique which, given a label stack and a
network layer packet, produces a labeled packet. This document network layer packet, produces a labeled packet. This document
specifies the encoding to be used by an LSR in order to transmit specifies the encoding to be used by an LSR in order to transmit
labeled packets on PPP data links, on LAN data links, and possibly on labeled packets on PPP data links, on LAN data links, and possibly on
other data links as well. On some data links, the label at the top other data links as well. On some data links, the label at the top
of the stack may be encoded in a different manner, but the techniques of the stack may be encoded in a different manner, but the techniques
skipping to change at page 3, line 7 skipping to change at page 3, line 7
4.4 Label Switching Control Protocol Configuration Options . 19 4.4 Label Switching Control Protocol Configuration Options . 19
5 Transporting Labeled Packets over LAN Media ............ 19 5 Transporting Labeled Packets over LAN Media ............ 19
6 IANA Considerations .................................... 20 6 IANA Considerations .................................... 20
7 Security Considerations ................................ 20 7 Security Considerations ................................ 20
8 Intellectual Property .................................. 20 8 Intellectual Property .................................. 20
9 Authors' Addresses ..................................... 21 9 Authors' Addresses ..................................... 21
10 References ............................................. 22 10 References ............................................. 22
1. Introduction 1. Introduction
"Multi-Protocol Label Switching (MPLS)" [1,2] requires a set of "Multi-Protocol Label Switching (MPLS)" [1] requires a set of
procedures for augmenting network layer packets with "label stacks", procedures for augmenting network layer packets with "label stacks",
thereby turning them into "labeled packets". Routers which support thereby turning them into "labeled packets". Routers which support
MPLS are known as "Label Switching Routers", or "LSRs". In order to MPLS are known as "Label Switching Routers", or "LSRs". In order to
transmit a labeled packet on a particular data link, an LSR must transmit a labeled packet on a particular data link, an LSR must
support an encoding technique which, given a label stack and a support an encoding technique which, given a label stack and a
network layer packet, produces a labeled packet. network layer packet, produces a labeled packet.
This document specifies the encoding to be used by an LSR in order to This document specifies the encoding to be used by an LSR in order to
transmit labeled packets on PPP data links and on LAN data links. transmit labeled packets on PPP data links and on LAN data links.
The specified encoding may also be useful for other data links as The specified encoding may also be useful for other data links as
skipping to change at page 3, line 38 skipping to change at page 3, line 38
LSRs that are implemented on certain switching devices (such as ATM LSRs that are implemented on certain switching devices (such as ATM
switches) may use different encoding techniques for encoding the top switches) may use different encoding techniques for encoding the top
one or two entries of the label stack. When the label stack has one or two entries of the label stack. When the label stack has
additional entries, however, the encoding technique described in this additional entries, however, the encoding technique described in this
document MUST be used for the additional label stack entries. document MUST be used for the additional label stack entries.
1.1. Specification of Requirements 1.1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3]. document are to be interpreted as described in RFC 2119 [2].
2. The Label Stack 2. The Label Stack
2.1. Encoding the Label Stack 2.1. Encoding the Label Stack
The label stack is represented as a sequence of "label stack The label stack is represented as a sequence of "label stack
entries". Each label stack entry is represented by 4 octets. This entries". Each label stack entry is represented by 4 octets. This
is shown in Figure 1. is shown in Figure 1.
0 1 2 3 0 1 2 3
skipping to change at page 5, line 30 skipping to change at page 5, line 30
label stack. label stack.
In addition to learning the next hop and the label stack In addition to learning the next hop and the label stack
operation, one may also learn the outgoing data link operation, one may also learn the outgoing data link
encapsulation, and possibly other information which is needed encapsulation, and possibly other information which is needed
in order to properly forward the packet. in order to properly forward the packet.
There are several reserved label values: There are several reserved label values:
i. A value of 0 represents the "IPv4 Explicit NULL Label". i. A value of 0 represents the "IPv4 Explicit NULL Label".
This label value is only legal when it is the sole This label value is only legal at the bottom of the
label stack entry. It indicates that the label stack label stack. It indicates that the label stack must be
must be popped, and the forwarding of the packet must popped, and the forwarding of the packet must then be
then be based on the IPv4 header. based on the IPv4 header.
ii. A value of 1 represents the "Router Alert Label". This ii. A value of 1 represents the "Router Alert Label". This
label value is legal anywhere in the label stack except label value is legal anywhere in the label stack except
at the bottom. When a received packet contains this at the bottom. When a received packet contains this
label value at the top of the label stack, it is label value at the top of the label stack, it is
delivered to a local software module for processing. delivered to a local software module for processing.
The actual forwarding of the packet is determined by The actual forwarding of the packet is determined by
the label beneath it in the stack. However, if the the label beneath it in the stack. However, if the
packet is forwarded further, the Router Alert Label packet is forwarded further, the Router Alert Label
should be pushed back onto the label stack before should be pushed back onto the label stack before
forwarding. The use of this label is analogous to the forwarding. The use of this label is analogous to the
use of the "Router Alert Option" in IP packets [6]. use of the "Router Alert Option" in IP packets [5].
Since this label cannot occur at the bottom of the Since this label cannot occur at the bottom of the
stack, it is not associated with a particular network stack, it is not associated with a particular network
layer protocol. layer protocol.
iii. A value of 2 represents the "IPv6 Explicit NULL Label". iii. A value of 2 represents the "IPv6 Explicit NULL Label".
This label value is only legal when it is the sole This label value is only legal at the bottom of the
label stack entry. It indicates that the label stack label stack. It indicates that the label stack must be
must be popped, and the forwarding of the packet must popped, and the forwarding of the packet must then be
then be based on the IPv6 header. based on the IPv6 header.
iv. A value of 3 represents the "Implicit NULL Label". iv. A value of 3 represents the "Implicit NULL Label".
This is a label that an LSR may assign and distribute, This is a label that an LSR may assign and distribute,
but which never actually appears in the encapsulation. but which never actually appears in the encapsulation.
When an LSR would otherwise replace the label at the When an LSR would otherwise replace the label at the
top of the stack with a new label, but the new label is top of the stack with a new label, but the new label is
"Implicit NULL", the LSR will pop the stack instead of "Implicit NULL", the LSR will pop the stack instead of
doing the replacement. Although this value may never doing the replacement. Although this value may never
appear in the encapsulation, it needs to be specified appear in the encapsulation, it needs to be specified
in the Label Distribution Protocol, so a value is in the Label Distribution Protocol, so a value is
skipping to change at page 10, line 28 skipping to change at page 10, line 28
of the IP header checksum. of the IP header checksum.
It is recognized that there may be situations where a network It is recognized that there may be situations where a network
administration prefers to decrement the IPv4 TTL by one as it administration prefers to decrement the IPv4 TTL by one as it
traverses an MPLS domain, instead of decrementing the IPv4 TTL by the traverses an MPLS domain, instead of decrementing the IPv4 TTL by the
number of LSP hops within the domain. number of LSP hops within the domain.
2.4.4. Translating Between Different Encapsulations 2.4.4. Translating Between Different Encapsulations
Sometimes an LSR may receive a labeled packet over, e.g., a label Sometimes an LSR may receive a labeled packet over, e.g., a label
switching controlled ATM (LC-ATM) interface [10], and may need to switching controlled ATM (LC-ATM) interface [9], and may need to send
send it out over a PPP or LAN link. Then the incoming packet will it out over a PPP or LAN link. Then the incoming packet will not be
not be received using the encapsulation specified in this document, received using the encapsulation specified in this document, but the
but the outgoing packet will be sent using the encapsulation outgoing packet will be sent using the encapsulation specified in
specified in this document. this document.
In this case, the value of the "incoming TTL" is determined by the In this case, the value of the "incoming TTL" is determined by the
procedures used for carrying labeled packets on, e.g., LC-ATM procedures used for carrying labeled packets on, e.g., LC-ATM
interfaces. TTL processing then proceeds as described above. interfaces. TTL processing then proceeds as described above.
Sometimes an LSR may receive a labeled packet over a PPP or a LAN Sometimes an LSR may receive a labeled packet over a PPP or a LAN
link, and may need to send it out, say, an LC-ATM interface. Then link, and may need to send it out, say, an LC-ATM interface. Then
the incoming packet will be received using the encapsulation the incoming packet will be received using the encapsulation
specified in this document, but the outgoing packet will not be sent specified in this document, but the outgoing packet will not be sent
using the encapsulation specified in this document. In this case, using the encapsulation specified in this document. In this case,
skipping to change at page 11, line 23 skipping to change at page 11, line 23
which was originally small enough to be transmitted on that link which was originally small enough to be transmitted on that link
becomes too large by virtue of having one or more additional labels becomes too large by virtue of having one or more additional labels
pushed onto its label stack. In label switching, a packet may grow pushed onto its label stack. In label switching, a packet may grow
in size if additional labels get pushed on. Thus if one receives a in size if additional labels get pushed on. Thus if one receives a
labeled packet with a 1500-byte frame payload, and pushes on an labeled packet with a 1500-byte frame payload, and pushes on an
additional label, one needs to forward it as frame with a 1504-byte additional label, one needs to forward it as frame with a 1504-byte
payload. payload.
This section specifies the rules for processing labeled packets which This section specifies the rules for processing labeled packets which
are "too large". In particular, it provides rules which ensure that are "too large". In particular, it provides rules which ensure that
hosts implementing Path MTU Discovery [5], and hosts using IPv6 hosts implementing Path MTU Discovery [4], and hosts using IPv6
[8,9], will be able to generate IP datagrams that do not need [7,8], will be able to generate IP datagrams that do not need
fragmentation, even if those datagrams get labeled as they traverse fragmentation, even if those datagrams get labeled as they traverse
the network. the network.
In general, IPv4 hosts which do not implement Path MTU Discovery [5] In general, IPv4 hosts which do not implement Path MTU Discovery [4]
send IP datagrams which contain no more than 576 bytes. Since the send IP datagrams which contain no more than 576 bytes. Since the
MTUs in use on most data links today are 1500 bytes or more, the MTUs in use on most data links today are 1500 bytes or more, the
probability that such datagrams will need to get fragmented, even if probability that such datagrams will need to get fragmented, even if
they get labeled, is very small. they get labeled, is very small.
Some hosts that do not implement Path MTU Discovery [5] will generate Some hosts that do not implement Path MTU Discovery [4] will generate
IP datagrams containing 1500 bytes, as long as the IP Source and IP datagrams containing 1500 bytes, as long as the IP Source and
Destination addresses are on the same subnet. These datagrams will Destination addresses are on the same subnet. These datagrams will
not pass through routers, and hence will not get fragmented. not pass through routers, and hence will not get fragmented.
Unfortunately, some hosts will generate IP datagrams containing 1500 Unfortunately, some hosts will generate IP datagrams containing 1500
bytes, as long the IP Source and Destination addresses have the same bytes, as long the IP Source and Destination addresses have the same
classful network number. This is the one case in which there is any classful network number. This is the one case in which there is any
risk of fragmentation when such datagrams get labeled. (Even so, risk of fragmentation when such datagrams get labeled. (Even so,
fragmentation is not likely unless the packet must traverse an fragmentation is not likely unless the packet must traverse an
ethernet of some sort between the time it first gets labeled and the ethernet of some sort between the time it first gets labeled and the
skipping to change at page 15, line 22 skipping to change at page 15, line 22
c. Forward the fragments c. Forward the fragments
4. If the IP datagram has the "Don't Fragment" bit set in its IP 4. If the IP datagram has the "Don't Fragment" bit set in its IP
header: header:
a. the datagram MUST NOT be forwarded a. the datagram MUST NOT be forwarded
b. Create an ICMP Destination Unreachable Message: b. Create an ICMP Destination Unreachable Message:
i. set its Code field [4] to "Fragmentation Required i. set its Code field [3] to "Fragmentation Required
and DF Set", and DF Set",
ii. set its Next-Hop MTU field [5] to the difference ii. set its Next-Hop MTU field [4] to the difference
between the Effective Maximum Frame Payload Size between the Effective Maximum Frame Payload Size
and the value of N and the value of N
c. If possible, transmit the ICMP Destination Unreachable c. If possible, transmit the ICMP Destination Unreachable
Message to the source of the of the discarded datagram. Message to the source of the of the discarded datagram.
3.5. Processing Labeled IPv6 Datagrams which are Too Big 3.5. Processing Labeled IPv6 Datagrams which are Too Big
To process a labeled IPv6 datagram which is too big, an LSR MUST To process a labeled IPv6 datagram which is too big, an LSR MUST
execute the following algorithm: execute the following algorithm:
skipping to change at page 16, line 29 skipping to change at page 16, line 29
c. Forward the fragments. c. Forward the fragments.
Reassembly of the fragments will be done at the destination Reassembly of the fragments will be done at the destination
host. host.
3.6. Implications with respect to Path MTU Discovery 3.6. Implications with respect to Path MTU Discovery
The procedures described above for handling datagrams which have the The procedures described above for handling datagrams which have the
DF bit set, but which are "too large", have an impact on the Path MTU DF bit set, but which are "too large", have an impact on the Path MTU
Discovery procedures of RFC 1191 [5]. Hosts which implement these Discovery procedures of RFC 1191 [4]. Hosts which implement these
procedures will discover an MTU which is small enough to allow n procedures will discover an MTU which is small enough to allow n
labels to be pushed on the datagrams, without need for fragmentation, labels to be pushed on the datagrams, without need for fragmentation,
where n is the number of labels that actually get pushed on along the where n is the number of labels that actually get pushed on along the
path currently in use. path currently in use.
In other words, datagrams from hosts that use Path MTU Discovery will In other words, datagrams from hosts that use Path MTU Discovery will
never need to be fragmented due to the need to put on a label header, never need to be fragmented due to the need to put on a label header,
or to add new labels to an existing label header. (Also, datagrams or to add new labels to an existing label header. (Also, datagrams
from hosts that use Path MTU Discovery generally have the DF bit set, from hosts that use Path MTU Discovery generally have the DF bit set,
and so will never get fragmented anyway.) and so will never get fragmented anyway.)
skipping to change at page 17, line 19 skipping to change at page 17, line 19
- Any time the transmitting endpoint of the tunnel needs to send a - Any time the transmitting endpoint of the tunnel needs to send a
packet into the tunnel, and that packet has the DF bit set, and packet into the tunnel, and that packet has the DF bit set, and
it exceeds the tunnel MTU, the transmitting endpoint of the it exceeds the tunnel MTU, the transmitting endpoint of the
tunnel MUST send the ICMP Destination Unreachable message to the tunnel MUST send the ICMP Destination Unreachable message to the
source, with code "Fragmentation Required and DF Set", and the source, with code "Fragmentation Required and DF Set", and the
Next-Hop MTU Field set as described above. Next-Hop MTU Field set as described above.
4. Transporting Labeled Packets over PPP 4. Transporting Labeled Packets over PPP
The Point-to-Point Protocol (PPP) [7] provides a standard method for The Point-to-Point Protocol (PPP) [6] provides a standard method for
transporting multi-protocol datagrams over point-to-point links. PPP transporting multi-protocol datagrams over point-to-point links. PPP
defines an extensible Link Control Protocol, and proposes a family of defines an extensible Link Control Protocol, and proposes a family of
Network Control Protocols for establishing and configuring different Network Control Protocols for establishing and configuring different
network-layer protocols. network-layer protocols.
This section defines the Network Control Protocol for establishing This section defines the Network Control Protocol for establishing
and configuring label Switching over PPP. and configuring label Switching over PPP.
4.1. Introduction 4.1. Introduction
skipping to change at page 18, line 16 skipping to change at page 18, line 16
4.2. A PPP Network Control Protocol for MPLS 4.2. A PPP Network Control Protocol for MPLS
The MPLS Control Protocol (MPLSCP) is responsible for enabling and The MPLS Control Protocol (MPLSCP) is responsible for enabling and
disabling the use of label switching on a PPP link. It uses the same disabling the use of label switching on a PPP link. It uses the same
packet exchange mechanism as the Link Control Protocol (LCP). MPLSCP packet exchange mechanism as the Link Control Protocol (LCP). MPLSCP
packets may not be exchanged until PPP has reached the Network-Layer packets may not be exchanged until PPP has reached the Network-Layer
Protocol phase. MPLSCP packets received before this phase is reached Protocol phase. MPLSCP packets received before this phase is reached
should be silently discarded. should be silently discarded.
The MPLS Control Protocol is exactly the same as the Link Control The MPLS Control Protocol is exactly the same as the Link Control
Protocol [7] with the following exceptions: Protocol [6] with the following exceptions:
1. Frame Modifications 1. Frame Modifications
The packet may utilize any modifications to the basic frame The packet may utilize any modifications to the basic frame
format which have been negotiated during the Link Establishment format which have been negotiated during the Link Establishment
phase. phase.
2. Data Link Layer Protocol Field 2. Data Link Layer Protocol Field
Exactly one MPLSCP packet is encapsulated in the PPP Exactly one MPLSCP packet is encapsulated in the PPP
skipping to change at page 21, line 19 skipping to change at page 21, line 19
250 Apollo Drive 250 Apollo Drive
Chelmsford, MA, 01824 Chelmsford, MA, 01824
E-mail: erosen@cisco.com E-mail: erosen@cisco.com
Dan Tappan Dan Tappan
Cisco Systems, Inc. Cisco Systems, Inc.
250 Apollo Drive 250 Apollo Drive
Chelmsford, MA, 01824 Chelmsford, MA, 01824
E-mail: tappan@cisco.com E-mail: tappan@cisco.com
Dino Farinacci
Cisco Systems, Inc.
170 Tasman Drive
San Jose, CA, 95134
E-mail: dino@cisco.com
Yakov Rekhter Yakov Rekhter
Cisco Systems, Inc. Cisco Systems, Inc.
170 Tasman Drive 170 Tasman Drive
San Jose, CA, 95134 San Jose, CA, 95134
E-mail: yakov@cisco.com E-mail: yakov@cisco.com
Guy Fedorkow Guy Fedorkow
Cisco Systems, Inc. Cisco Systems, Inc.
250 Apollo Drive 250 Apollo Drive
Chelmsford, MA, 01824 Chelmsford, MA, 01824
E-mail: fedorkow@cisco.com E-mail: fedorkow@cisco.com
Dino Farinacci
Procket Networks, Inc.
3910 Freedom Circle, Ste. 102A
Santa Clara, CA 95054
E-mail: dino@procket.com
Tony Li Tony Li
Juniper Networks Procket Networks, Inc.
385 Ravendale Dr. 3910 Freedom Circle, Ste. 102A
Mountain View, CA, 94043 Santa Clara, CA 95054
E-mail: tli@juniper.net E-mail: tli@procket.com
Alex Conta Alex Conta
Lucent Technologies TranSwitch Corporation
300 Baker Avenue 3 Enterprise Drive
Concord, MA, 01742 Shelton, CT, 06484
E-mail: aconta@lucent.com E-mail: aconta@txc.com
10. References 10. References
[1] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol Label [1] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol Label
Switching Architecture", Work in Progress, April 1999. Switching Architecture", Work in Progress, July 2000.
[2] Callon, R., Doolan, P., Feldman, N., Fredette, A., Swallow, G.,
Viswanathan, A., "A Framework for Multiprotocol Label Switching",
Work in Progress, November 1997.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997. Levels", RFC 2119, BCP 14, March 1997.
[4] Postel, J., "Internet Control Message Protocol", RFC 792, [3] Postel, J., "Internet Control Message Protocol", RFC 792,
September 1981. September 1981.
[5] Mogul, J. and Deering S., "Path MTU Discovery", RFC 1191, [4] Mogul, J. and Deering S., "Path MTU Discovery", RFC 1191,
November 1990. November 1990.
[6] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. [5] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[7] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC [6] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC
1661, STD 51, July 1994. 1661, STD 51, July 1994.
[8] Conta, A. and Deering, S., "Internet Control Message Protocol [7] Conta, A. and Deering, S., "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification",
RFC 1885, December 1995. RFC 1885, December 1995.
[9] McCann, J., Deering, S. and Mogul, J., "Path MTU Discovery for IP [8] McCann, J., Deering, S. and Mogul, J., "Path MTU Discovery for IP
version 6", RFC 1981, August 1996. version 6", RFC 1981, August 1996.
[10] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E. [9] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E.
and Swallow G., "MPLS Using LDP and ATM VC Switching", Work in and Swallow G., "MPLS Using LDP and ATM VC Switching", Work in
Progress, April 1999. Progress, June 2000.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/