draft-ietf-mpls-label-encaps-03.txt   draft-ietf-mpls-label-encaps-04.txt 
Network Working Group Eric C. Rosen Network Working Group Eric C. Rosen
Internet Draft Yakov Rekhter Internet Draft Yakov Rekhter
Expiration Date: March 1999 Daniel Tappan Expiration Date: October 1999 Daniel Tappan
Dino Farinacci Dino Farinacci
Guy Fedorkow Guy Fedorkow
Cisco Systems, Inc. Cisco Systems, Inc.
Tony Li Tony Li
Juniper Networks, Inc. Juniper Networks, Inc.
Alex Conta Alex Conta
Lucent Technologies Lucent Technologies
September 1998 April 1999
MPLS Label Stack Encoding MPLS Label Stack Encoding
draft-ietf-mpls-label-encaps-03.txt draft-ietf-mpls-label-encaps-04.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft and is in full conformance with
documents of the Internet Engineering Task Force (IETF), its areas, all provisions of Section 10 of RFC2026.
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. 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 Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the The list of current Internet-Drafts can be accessed at
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow http://www.ietf.org/ietf/1id-abstracts.txt.
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific The list of Internet-Draft Shadow Directories can be accessed at
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 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,2] 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
described here MUST be used to encode the remainder of the label described here MUST be used to encode the remainder of the label
stack. This document also specifies rules and procedures for stack. This document also specifies rules and procedures for
processing the various fields of the label stack encoding. processing the various fields of the label stack encoding.
skipping to change at page 2, line 22 skipping to change at page 2, line 25
Table of Contents Table of Contents
1 Introduction ........................................... 3 1 Introduction ........................................... 3
1.1 Specification of Requirements .......................... 3 1.1 Specification of Requirements .......................... 3
2 The Label Stack ........................................ 3 2 The Label Stack ........................................ 3
2.1 Encoding the Label Stack ............................... 3 2.1 Encoding the Label Stack ............................... 3
2.2 Determining the Network Layer Protocol ................. 6 2.2 Determining the Network Layer Protocol ................. 6
2.3 Generating ICMP Messages for Labeled IP Packets ........ 7 2.3 Generating ICMP Messages for Labeled IP Packets ........ 7
2.3.1 Tunneling through a Transit Routing Domain ............. 7 2.3.1 Tunneling through a Transit Routing Domain ............. 7
2.3.2 Tunneling Private Addresses through a Public Backbone .. 8 2.3.2 Tunneling Private Addresses through a Public Backbone .. 8
2.4 Processing the Time to Live Field ...................... 8 2.4 Processing the Time to Live Field ...................... 9
2.4.1 Definitions ............................................ 8 2.4.1 Definitions ............................................ 9
2.4.2 Protocol-independent rules ............................. 9 2.4.2 Protocol-independent rules ............................. 9
2.4.3 IP-dependent rules ..................................... 9 2.4.3 IP-dependent rules ..................................... 10
2.4.4 Translating Between Different Encapsulations ........... 10 2.4.4 Translating Between Different Encapsulations ........... 10
3 Fragmentation and Path MTU Discovery ................... 10 3 Fragmentation and Path MTU Discovery ................... 11
3.1 Terminology ............................................ 11 3.1 Terminology ............................................ 12
3.2 Maximum Initially Labeled IP Datagram Size ............. 13 3.2 Maximum Initially Labeled IP Datagram Size ............. 13
3.3 When are Labeled IP Datagrams Too Big? ................. 14 3.3 When are Labeled IP Datagrams Too Big? ................. 14
3.4 Processing Labeled IPv4 Datagrams which are Too Big .... 14 3.4 Processing Labeled IPv4 Datagrams which are Too Big .... 14
3.5 Processing Labeled IPv6 Datagrams which are Too Big .... 15 3.5 Processing Labeled IPv6 Datagrams which are Too Big .... 15
3.6 Implications with respect to Path MTU Discovery ........ 16 3.6 Implications with respect to Path MTU Discovery ........ 16
4 Transporting Labeled Packets over PPP .................. 17 4 Transporting Labeled Packets over PPP .................. 17
4.1 Introduction ........................................... 17 4.1 Introduction ........................................... 17
4.2 A PPP Network Control Protocol for MPLS ................ 17 4.2 A PPP Network Control Protocol for MPLS ................ 18
4.3 Sending Labeled Packets ................................ 18 4.3 Sending Labeled Packets ................................ 19
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 Security Considerations ................................ 19 6 IANA Considerations .................................... 20
7 Authors' Addresses ..................................... 20 7 Security Considerations ................................ 20
8 References ............................................. 21 8 Authors' Addresses ..................................... 20
9 References ............................................. 21
1. Introduction 1. Introduction
"Multi-Protocol Label Switching (MPLS)" [1,2] requires a set of "Multi-Protocol Label Switching (MPLS)" [1,2] 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.
skipping to change at page 6, line 22 skipping to change at page 6, line 22
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
reserved. reserved.
v. Values 4-16 are reserved. v. Values 4-15 are reserved.
2.2. Determining the Network Layer Protocol 2.2. Determining the Network Layer Protocol
When the last label is popped from a packet's label stack (resulting When the last label is popped from a packet's label stack (resulting
in the stack being emptied), further processing of the packet is in the stack being emptied), further processing of the packet is
based on the packet's network layer header. The LSR which pops the based on the packet's network layer header. The LSR which pops the
last label off the stack must therefore be able to identify the last label off the stack must therefore be able to identify the
packet's network layer protocol. However, the label stack does not packet's network layer protocol. However, the label stack does not
contain any field which explicitly identifies the network layer contain any field which explicitly identifies the network layer
protocol. This means that the identity of the network layer protocol protocol. This means that the identity of the network layer protocol
skipping to change at page 8, line 42 skipping to change at page 8, line 42
In this environment, in order to send an ICMP message to the source In this environment, in order to send an ICMP message to the source
of a packet, one can copy the label stack from the original packet to of a packet, one can copy the label stack from the original packet to
the ICMP message, and then label switch the ICMP message. This will the ICMP message, and then label switch the ICMP message. This will
cause the message to proceed in the direction of the original cause the message to proceed in the direction of the original
packet's destination, rather than its source. Unless the message is packet's destination, rather than its source. Unless the message is
label switched all the way to the destination host, it will end up, label switched all the way to the destination host, it will end up,
unlabeled, in a router which does know how to route to the source of unlabeled, in a router which does know how to route to the source of
original packet, at which point the message will be sent in the original packet, at which point the message will be sent in the
proper direction. proper direction.
This technique can be very useful if the ICMP message is a "Time
Exceeded" message or a "Destination Unreachable because fragmentation
needed and DF set" message.
When copying the label stack from the original packet to the ICMP
message, the label values must be copied exactly, but the TTL values
in the label stack should be set to the TTL value that is placed in
the IP header of the ICMP message. This TTL value should be long
enough to allow the circuitous route that the ICMP message will need
to follow.
Note that if a packet's TTL expiration is due to the presence of a
routing loop, then if this technique is used, the ICMP message may
loop as well. Since an ICMP message is never sent as a result of
receiving an ICMP message, and since many implementations throttle
the rate at which ICMP messages can be generated, this is not
expected to pose a problem.
2.4. Processing the Time to Live Field 2.4. Processing the Time to Live Field
2.4.1. Definitions 2.4.1. Definitions
The "incoming TTL" of a labeled packet is defined to be the value of The "incoming TTL" of a labeled packet is defined to be the value of
the TTL field of the top label stack entry when the packet is the TTL field of the top label stack entry when the packet is
received. received.
The "outgoing TTL" of a labeled packet is defined to be the larger The "outgoing TTL" of a labeled packet is defined to be the larger
of: of:
skipping to change at page 10, line 8 skipping to change at page 10, line 27
TTL value, as defined above. In IPv4 this also requires modification TTL value, as defined above. In IPv4 this also requires modification
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, say, 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 [10], and may need to
send it out over a PPP or LAN link. Then the incoming packet will send it out over a PPP or LAN link. Then the incoming packet will
not be received using the encapsulation specified in this document, not be received using the encapsulation specified in this document,
but the outgoing packet will be sent using the encapsulation but the outgoing packet will be sent using the encapsulation
specified in this document. specified in 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.
skipping to change at page 11, line 18 skipping to change at page 11, line 40
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 [5] 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 do not have bytes, as long the IP Source and Destination addresses have the same
the same classful network number. This is the one case in which classful network number. This is the one case in which there is any
there is any risk of fragmentation when such datagrams get labeled. risk of fragmentation when such datagrams get labeled. (Even so,
(Even so, fragmentation is not likely unless the packet must traverse fragmentation is not likely unless the packet must traverse an
an ethernet of some sort between the time it first gets labeled and ethernet of some sort between the time it first gets labeled and the
the time it gets unlabeled.) time it gets unlabeled.)
This document specifies procedures which allow one to configure the This document specifies procedures which allow one to configure the
network so that large datagrams from hosts which do not implement network so that large datagrams from hosts which do not implement
Path MTU Discovery get fragmented just once, when they are first Path MTU Discovery get fragmented just once, when they are first
labeled. These procedures make it possible (assuming suitable labeled. These procedures make it possible (assuming suitable
configuration) to avoid any need to fragment packets which have configuration) to avoid any need to fragment packets which have
already been labeled. already been labeled.
3.1. Terminology 3.1. Terminology
skipping to change at page 19, line 35 skipping to change at page 20, line 5
The ethertype value 8847 hex is used to indicate that a frame is The ethertype value 8847 hex is used to indicate that a frame is
carrying an MPLS unicast packet. carrying an MPLS unicast packet.
The ethertype value 8848 hex is used to indicate that a frame is The ethertype value 8848 hex is used to indicate that a frame is
carrying an MPLS multicast packet. carrying an MPLS multicast packet.
These ethertype values can be used with either the ethernet These ethertype values can be used with either the ethernet
encapsulation or the 802.3 LLC/SNAP encapsulation to carry labeled encapsulation or the 802.3 LLC/SNAP encapsulation to carry labeled
packets. packets.
6. Security Considerations 6. IANA Considerations
Label values 0-15 inclusive have special meaning, as specified in
this document, or as further assigned by IANA.
In this document, label values 0-3 are specified in section 2.1.
Label values 4-15 may be assigned by IANA, based on IETF Consensus.
7. Security Considerations
The MPLS encapsulation that is specified herein does not raise any The MPLS encapsulation that is specified herein does not raise any
security issues that are not already present in either the MPLS security issues that are not already present in either the MPLS
architecture [1] or in the architecture of the network layer protocol architecture [1] or in the architecture of the network layer protocol
contained within the encapsulation. contained within the encapsulation.
There are two security considerations inherited from the MPLS There are two security considerations inherited from the MPLS
architecture which may be pointed out here: architecture which may be pointed out here:
- Some routers may implement security procedures which depend on - Some routers may implement security procedures which depend on
skipping to change at page 20, line 13 skipping to change at page 20, line 38
variable size. variable size.
- An MPLS label has its meaning by virtue of an agreement between - An MPLS label has its meaning by virtue of an agreement between
the LSR that puts the label in the label stack (the "label the LSR that puts the label in the label stack (the "label
writer") , and the LSR that interprets that label (the "label writer") , and the LSR that interprets that label (the "label
reader"). However, the label stack does not provide any means of reader"). However, the label stack does not provide any means of
determining who the label writer was for any particular label. determining who the label writer was for any particular label.
If labeled packets are accepted from untrusted sources, the If labeled packets are accepted from untrusted sources, the
result may be that packets are routed in an illegitimate manner. result may be that packets are routed in an illegitimate manner.
7. Authors' Addresses 8. Authors' Addresses
Eric C. Rosen Eric C. Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
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
skipping to change at page 21, line 4 skipping to change at page 21, line 29
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
Tony Li Tony Li
Juniper Networks Juniper Networks
385 Ravendale Dr. 385 Ravendale Dr.
Mountain View, CA, 94043 Mountain View, CA, 94043
E-mail: tli@juniper.net E-mail: tli@juniper.net
Alex Conta Alex Conta
Lucent Technologies Lucent Technologies
300 Baker Avenue 300 Baker Avenue
Concord, MA, 01742 Concord, MA, 01742
E-mail: aconta@lucent.com E-mail: aconta@lucent.com
8. References 9. 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, July, 1998 Switching Architecture", Work in Progress, April 1999.
[2] Callon, R., Doolan, P., Feldman, N., Fredette, A., Swallow, G., [2] Callon, R., Doolan, P., Feldman, N., Fredette, A., Swallow, G.,
Viswanathan, A., "A Framework for Multiprotocol Label Switching", Viswanathan, A., "A Framework for Multiprotocol Label Switching",
Work in Progress, November 1997. Work in Progress, November 1997.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] 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, [4] Postel, J., "Internet Control Message Protocol", RFC 792,
September 1981. September 1981.
skipping to change at page 21, line 41 skipping to change at page 22, line 21
1661, STD 51, July 1994. 1661, STD 51, July 1994.
[8] Conta, A. and Deering, S., "Internet Control Message Protocol [8] 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 [9] 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. [10] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E.
and Swallow G., "Use of Label Switching with ATM", Work in Progress, and Swallow G., "MPLS Using LDP and ATM VC Switching", Work in
July 1998. Progress, April 1999.
 End of changes. 

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