draft-ietf-mpls-label-encaps-00.txt   draft-ietf-mpls-label-encaps-01.txt 
Network Working Group Eric C. Rosen Network Working Group Eric C. Rosen
Internet Draft Yakov Rekhter Internet Draft Yakov Rekhter
Expiration Date: May 1998 Daniel Tappan Expiration Date: August 1998 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
November 1997 February 1998
MPLS Label Stack Encoding MPLS Label Stack Encoding
draft-ietf-mpls-label-encaps-00.txt draft-ietf-mpls-label-encaps-01.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. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. 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
skipping to change at page 1, line 42 skipping to change at page 1, line 42
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
Abstract Abstract
''Multi-Protocol Label Switching (MPLS)'' [1,2,3] requires a set of "Multi-Protocol Label Switching (MPLS)" [1,2,3] 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 and possibly on other data links as labeled packets on PPP data links, on LAN data links, and possibly on
well. On some data links, the label at the top of the stack may be other data links as well. On some data links, the label at the top
encoded in a different manner, but the techniques described here MUST of the stack may be encoded in a different manner, but the techniques
be used to encode the remainder of the label stack. This document described here MUST be used to encode the remainder of the label
also specifies rules and procedures for processing the various fields stack. This document also specifies rules and procedures for
of the label stack encoding. processing the various fields of the label stack encoding.
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 ........................................ 4 2 The Label Stack ........................................ 4
2.1 Encoding the Label Stack ............................... 4 2.1 Encoding the Label Stack ............................... 4
2.2 Determining the Network Layer Protocol ................. 7 2.2 Determining the Network Layer Protocol ................. 7
2.3 Processing the Time to Live Field ...................... 7 2.3 Processing the Time to Live Field ...................... 8
2.3.1 Definitions ............................................ 7 2.3.1 Definitions ............................................ 8
2.3.2 Protocol-independent rules ............................. 7 2.3.2 Protocol-independent rules ............................. 8
2.3.3 IP-dependent rules ..................................... 8 2.3.3 IP-dependent rules ..................................... 8
3 Fragmentation and Path MTU Discovery ................... 8 2.3.4 Translating Between Different Encapsulations ........... 9
3.1 Terminology ............................................ 9 3 Fragmentation and Path MTU Discovery ................... 9
3.2 Maximum Initially Labeled IP Datagram Size ............. 10 3.1 Terminology ............................................ 10
3.3 When are Labeled IP Datagrams Too Big? ................. 11 3.2 Maximum Initially Labeled IP Datagram Size ............. 12
3.4 Processing Labeled IPv4 Datagrams which are Too Big .... 12 3.3 When are Labeled IP Datagrams Too Big? ................. 13
3.5 Processing Labeled IPv6 Datagrams which are Too Big .... 13 3.4 Processing Labeled IPv4 Datagrams which are Too Big .... 13
3.6 Implications with respect to Path MTU Discovery ........ 14 3.5 Processing Labeled IPv6 Datagrams which are Too Big .... 14
3.6.1 Tunneling through a Transit Routing Domain ............. 14 3.6 Implications with respect to Path MTU Discovery ........ 15
3.6.2 Tunneling Private Addresses through a Public Backbone .. 14 3.6.1 Tunneling through a Transit Routing Domain ............. 15
4 Transporting Labeled Packets over PPP .................. 15 3.6.2 Tunneling Private Addresses through a Public Backbone .. 16
4.1 Introduction ........................................... 15 4 Transporting Labeled Packets over PPP .................. 16
4.2 A PPP Network Control Protocol for MPLS ................ 16 4.1 Introduction ........................................... 16
4.3 Sending Labeled Packets ................................ 17 4.2 A PPP Network Control Protocol for MPLS ................ 17
4.4 Label Switching Control Protocol Configuration Options . 17 4.3 Sending Labeled Packets ................................ 18
5 Security Considerations ................................ 18 4.4 Label Switching Control Protocol Configuration Options . 18
6 Authors' Addresses ..................................... 18 5 Transporting Labeled Packets over LAN Media ............ 18
7 References ............................................. 19 6 Security Considerations ................................ 19
7 Authors' Addresses ..................................... 19
8 References ............................................. 20
1. Introduction 1. Introduction
"Multi-Protocol Label Switching (MPLS)" [1,2,3] requires a set of "Multi-Protocol Label Switching (MPLS)" [1,2,3] 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. The specified encoding transmit labeled packets on PPP data links and on LAN data links.
may also be useful for other data links as well. The specified encoding may also be useful for other data links as
well.
This document also specifies rules and procedures for processing the This document also specifies rules and procedures for processing the
various fields of the label stack encoding. Since MPLS is various fields of the label stack encoding. Since MPLS is
independent of any particular network layer protocol, the majority of independent of any particular network layer protocol, the majority of
such procedures are also protocol-independent. A few, however, do such procedures are also protocol-independent. A few, however, do
differ for different protocols. In this document, we specify the differ for different protocols. In this document, we specify the
protocol-independent procedures, and we specify the protocol- protocol-independent procedures, and we specify the protocol-
dependent procedures for IPv4 and IPv6. dependent procedures for IPv4 and IPv6.
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 may 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
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. of the specification. These words are often capitalized.
MUST MUST
This word, or the adjective "required", means that the This word, or the adjective "required", means that the
definition is an absolute requirement of the specification. definition is an absolute requirement of the specification.
skipping to change at page 7, line 9 skipping to change at page 7, line 9
"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-16 are reserved.
2.2. Determining the Network Layer Protocol 2.2. Determining the Network Layer Protocol
When the last label is popped from the label stack, it is necessary When the last label is popped from a packet's label stack (resulting
to determine the particular network layer protocol which is being in the stack being emptied), further processing of the packet is
carried. Note that the label stack entries carry no explicit field based on the packet's network layer header. The LSR which pops the
to identify the network layer header. Rather, this must be inferable last label off the stack must therefore be able to identify the
from the value of the label which is popped from the bottom of the packet's network layer protocol. However, the label stack does not
stack. This means that when the first label is pushed onto a network contain any field which explicitly identifies the network layer
layer packet, the label must be one which is used ONLY for packets of protocol. This means that the identity of the network layer protocol
a particular network layer. Furthermore, whenever that label is must be inferable from the value of the label which is popped from
the bottom of the stack, possibly along with the contents of the
network layer header itself.
Therefore, when the first label is pushed onto a network layer
packet, either the label must be one which is used ONLY for packets
of a particular network layer, or the label must be one which is used
ONLY for a specified set of network layer protocols, where packets of
the specified network layers can be distinguished by inspection of
the network layer header. Furthermore, whenever that label is
replaced by another label value during a packet's transit, the new replaced by another label value during a packet's transit, the new
value must also be one which is used only for packets of that network value must also be one which meets the same criteria. If these
layer. conditions are not met, the LSR which pops the last label off a
packet will not be able to identify the packet's network layer
protocol.
Adherence to these conditions does not necessarily enable
intermediate nodes to identify a packet's network layer protocol.
Under ordinary conditions, this is not necessary, but there are error
conditions under which it is desirable. For instance, if an
intermediate LSR determines that a labeled packet is undeliverable,
it may be desirable for that LSR to generate error messages which are
specific to the packet's network layer. The only means the
intermediate LSR has for identifying the network layer is inspection
of the top label and the network layer header. So if intermediate
nodes are to be able to generate protocol-specific error messages for
labeled packets, all labels in the stack must meet the criteria
specified above for labels which appear at the bottom of the stack.
2.3. Processing the Time to Live Field 2.3. Processing the Time to Live Field
2.3.1. Definitions 2.3.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
skipping to change at page 8, line 21 skipping to change at page 9, line 4
2.3.3. IP-dependent rules 2.3.3. IP-dependent rules
We define the "IP TTL" field to be the value of the IPv4 TTL field, We define the "IP TTL" field to be the value of the IPv4 TTL field,
or the value of the IPv6 Hop Limit field, whichever is applicable. or the value of the IPv6 Hop Limit field, whichever is applicable.
When an IP packet is first labeled, the TTL field of the label stack When an IP packet is first labeled, the TTL field of the label stack
entry MUST BE set to the value of the IP TTL field. (If the IP TTL entry MUST BE set to the value of the IP TTL field. (If the IP TTL
field needs to be decremented, as part of the IP processing, it is field needs to be decremented, as part of the IP processing, it is
assumed that this has already been done.) assumed that this has already been done.)
When a label is popped, and the resulting label stack is empty, then When a label is popped, and the resulting label stack is empty, then
the value of the IP TTL field MUST BE replaced with the outgoing TTL the value of the IP TTL field MUST BE replaced with the outgoing TTL
value, as defined above. In IPv4 this also requires modification of value, as defined above. In IPv4 this also requires modification of
the IP header checksum. the IP header checksum.
2.3.4. Translating Between Different Encapsulations
Sometimes an LSR may receive a labeled packet over, say, a label
switching controlled ATM (LC-ATM) interface [11], and may need to
send it out over a PPP or LAN link. Then the incoming packet will
not be received using the encapsulation specified in this document,
but the outgoing packet will be sent using the encapsulation
specified in this document.
In this case, the value of the "incoming TTL" is determined by the
procedures used for carrying labeled packets on, e.g., LC-ATM
interfaces. TTL processing then proceeds as described above.
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
the incoming packet will be received using the encapsulation
specified in this document, but the outgoing packet will not be send
using the encapsulation specified in this document. In this case,
the procedure for carrying the value of the "outgoing TTL" is
determined by the procedures used for carrying labeled packets on,
e.g., LC-ATM interfaces.
3. Fragmentation and Path MTU Discovery 3. Fragmentation and Path MTU Discovery
Just as it is possible to receive an unlabeled IP datagram which is Just as it is possible to receive an unlabeled IP datagram which is
too large to be transmitted on its output link, it is possible to too large to be transmitted on its output link, it is possible to
receive a labeled packet which is too large to be transmitted on its receive a labeled packet which is too large to be transmitted on its
output link. output link.
It is also possible that a received packet (labeled or unlabeled) It is also possible that a received packet (labeled or unlabeled)
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
skipping to change at page 9, line 37 skipping to change at page 10, line 42
already been labeled. already been labeled.
3.1. Terminology 3.1. Terminology
With respect to a particular data link, we can use the following With respect to a particular data link, we can use the following
terms: terms:
- Frame Payload: - Frame Payload:
The contents of a data link frame, excluding any data link layer The contents of a data link frame, excluding any data link layer
headers or trailers (e.g., MAC headers, LLC headers, 802.1Q or headers or trailers (e.g., MAC headers, LLC headers, 802.1Q
802.1p headers, PPP header, frame check sequences, etc.). headers, PPP header, frame check sequences, etc.).
When a frame is carrying an an unlabeled IP datagram, the Frame When a frame is carrying an an unlabeled IP datagram, the Frame
Payload is just the IP datagram itself. When a frame is carrying Payload is just the IP datagram itself. When a frame is carrying
a labeled IP datagram, the Frame Payload consists of the label a labeled IP datagram, the Frame Payload consists of the label
stack entries and the IP datagram. stack entries and the IP datagram.
- Conventional Maximum Frame Payload Size: - Conventional Maximum Frame Payload Size:
The maximum Frame Payload size allowed by data link standards. The maximum Frame Payload size allowed by data link standards.
For example, the Conventional Maximum Frame Payload Size for For example, the Conventional Maximum Frame Payload Size for
skipping to change at page 18, line 5 skipping to change at page 18, line 35
Note that two codepoints are defined for labeled packets; one for Note that two codepoints are defined for labeled packets; one for
multicast and one for unicast. Once the MPLSCP has reached the multicast and one for unicast. Once the MPLSCP has reached the
Opened state, both label Switched multicasts and label Switched Opened state, both label Switched multicasts and label Switched
unicasts can be sent over the PPP link. unicasts can be sent over the PPP link.
4.4. Label Switching Control Protocol Configuration Options 4.4. Label Switching Control Protocol Configuration Options
There are no configuration options. There are no configuration options.
5. Security Considerations 5. Transporting Labeled Packets over LAN Media
Exactly one labeled packet is carried in each frame.
The label stack entries immediately precede the network layer header,
and follow any data link layer headers, including, e.g., any 802.1Q
headers that may exist.
The ethertype value 8847 hex is used to indicate that a frame is
carrying an MPLS unicast packet.
The ethertype value 8848 hex is used to indicate that a frame is
carrying an MPLS multicast packet.
These ethertype values can be used with either the ethernet
encapsulation or the 802.3 SNAP/SAP encapsulation to carry labeled
packets.
6. Security Considerations
Security considerations are not discussed in this document. Security considerations are not discussed in this document.
6. Authors' Addresses 7. 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 18, line 46 skipping to change at page 20, line 4
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
7. References 8. References
[1], "A Proposed Architecture for MPLS", 7/97, draft-ietf-mpls-arch- [1], "A Proposed Architecture for MPLS", 7/97, draft-ietf-mpls-arch-
00.txt, Rosen, Viswanathan, Callon 00.txt, Rosen, Viswanathan, Callon
[2] "A Framework for Multiprotocol Label Switching", 7/97, draft- [2] "A Framework for Multiprotocol Label Switching", 11/97, draft-
ietf-mpls-framework-01.txt, Callon, Doolan, Feldman, Fredette, ietf-mpls-framework-02.txt, Callon, Doolan, Feldman, Fredette,
Swallow, Visanathawan Swallow, Viswanathan
[3] "Tag Switching Architecture - Overview", 7/97, draft-rekhter- [3] "Tag Switching Architecture - Overview", 7/97, draft-rekhter-
tagswitch-arch-01.txt, Rekhter, Davie, Katz, Rosen, Swallow tagswitch-arch-01.txt, Rekhter, Davie, Katz, Rosen, Swallow
[4] "Internet Protocol", RFC 791, 9/81, Postel [4] "Internet Protocol", RFC 791, 9/81, Postel
[5] "Internet Control Message Protocol", RFC 792, 9/81, Postel [5] "Internet Control Message Protocol", RFC 792, 9/81, Postel
[6] "Path MTU Discovery", RFC 1191, 11/90, Mogul & Deering [6] "Path MTU Discovery", RFC 1191, 11/90, Mogul & Deering
[7] "IP Router Alert Option", RFC 2113, 2/97, Katz [7] "IP Router Alert Option", RFC 2113, 2/97, Katz
[8] "The Point-to-Point Protocol (PPP)", RFC 1661, 7/94, Simpson [8] "The Point-to-Point Protocol (PPP)", RFC 1661, 7/94, Simpson
[9] "Internet Control Message Protocol (ICMPv6) for the Internet [9] "Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", RFC 1885, 12/95, Conta, Protocol Version 6 (IPv6) Specification", RFC 1885, 12/95, Conta,
Deering Deering
[10] "Path MTU Discovery for IP version 6", [RFC-1981] McCann, J., S. [10] "Path MTU Discovery for IP version 6", [RFC-1981] McCann, J., S.
Deering, J. Mogul Deering, J. Mogul
[11] "Use of Label Switching with ATM", draft-davie-mpls-atm-00.txt,
Davie, Lawrence, McCloghrie, Rekhter, Rosen, Swallow, Doolan
 End of changes. 

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