📄 rfc3032.txt
字号:
Network Working Group E. Rosen
Request for Comments: 3032 D. Tappan
Category: Standards Track G. Fedorkow
Cisco Systems, Inc.
Y. Rekhter
Juniper Networks
D. Farinacci
T. Li
Procket Networks, Inc.
A. Conta
TranSwitch Corporation
January 2001
MPLS Label Stack Encoding
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
"Multi-Protocol Label Switching (MPLS)" [1] requires a set of
procedures for augmenting network layer packets with "label stacks",
thereby turning them into "labeled packets". Routers which support
MPLS are known as "Label Switching Routers", or "LSRs". In order to
transmit a labeled packet on a particular data link, an LSR must
support an encoding technique which, given a label stack and a
network layer packet, produces a labeled packet. This document
specifies the encoding to be used by an LSR in order to transmit
labeled packets on Point-to-Point Protocol (PPP) data links, on LAN
data links, and possibly on 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 described here MUST be used to
encode the remainder of the label stack. This document also
specifies rules and procedures for processing the various fields of
the label stack encoding.
Rosen, et al. Standards Track [Page 1]
RFC 3032 MPLS Label Stack Encoding January 2001
Table of Contents
1 Introduction ........................................... 2
1.1 Specification of Requirements .......................... 3
2 The Label Stack ........................................ 3
2.1 Encoding the Label Stack ............................... 3
2.2 Determining the Network Layer Protocol ................. 5
2.3 Generating ICMP Messages for Labeled IP Packets ........ 6
2.3.1 Tunneling through a Transit Routing Domain ............. 7
2.3.2 Tunneling Private Addresses through a Public Backbone .. 7
2.4 Processing the Time to Live Field ...................... 8
2.4.1 Definitions ............................................ 8
2.4.2 Protocol-independent rules ............................. 8
2.4.3 IP-dependent rules ..................................... 9
2.4.4 Translating Between Different Encapsulations ........... 9
3 Fragmentation and Path MTU Discovery ................... 10
3.1 Terminology ............................................ 11
3.2 Maximum Initially Labeled IP Datagram Size ............. 12
3.3 When are Labeled IP Datagrams Too Big? ................. 13
3.4 Processing Labeled IPv4 Datagrams which are Too Big .... 13
3.5 Processing Labeled IPv6 Datagrams which are Too Big .... 14
3.6 Implications with respect to Path MTU Discovery ........ 15
4 Transporting Labeled Packets over PPP .................. 16
4.1 Introduction ........................................... 16
4.2 A PPP Network Control Protocol for MPLS ................ 17
4.3 Sending Labeled Packets ................................ 18
4.4 Label Switching Control Protocol Configuration Options . 18
5 Transporting Labeled Packets over LAN Media ............ 18
6 IANA Considerations .................................... 19
7 Security Considerations ................................ 19
8 Intellectual Property .................................. 19
9 Authors' Addresses ..................................... 20
10 References ............................................. 22
11 Full Copyright Statement ............................... 23
1. Introduction
"Multi-Protocol Label Switching (MPLS)" [1] requires a set of
procedures for augmenting network layer packets with "label stacks",
thereby turning them into "labeled packets". Routers which support
MPLS are known as "Label Switching Routers", or "LSRs". In order to
transmit a labeled packet on a particular data link, an LSR must
support an encoding technique which, given a label stack and a
network layer packet, produces a labeled packet.
Rosen, et al. Standards Track [Page 2]
RFC 3032 MPLS Label Stack Encoding January 2001
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.
The specified encoding may also be useful for other data links as
well.
This document also specifies rules and procedures for processing the
various fields of the label stack encoding. Since MPLS is
independent of any particular network layer protocol, the majority of
such procedures are also protocol-independent. A few, however, do
differ for different protocols. In this document, we specify the
protocol-independent procedures, and we specify the protocol-
dependent procedures for IPv4 and IPv6.
LSRs that are implemented on certain switching devices (such as ATM
switches) may use different encoding techniques for encoding the top
one or two entries of the label stack. When the label stack has
additional entries, however, the encoding technique described in this
document MUST be used for the additional label stack entries.
1.1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2].
2. The Label Stack
2.1. Encoding the Label Stack
The label stack is represented as a sequence of "label stack
entries". Each label stack entry is represented by 4 octets. This
is shown in Figure 1.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
| Label | Exp |S| TTL | Stack
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry
Label: Label Value, 20 bits
Exp: Experimental Use, 3 bits
S: Bottom of Stack, 1 bit
TTL: Time to Live, 8 bits
Figure 1
Rosen, et al. Standards Track [Page 3]
RFC 3032 MPLS Label Stack Encoding January 2001
The label stack entries appear AFTER the data link layer headers, but
BEFORE any network layer headers. The top of the label stack appears
earliest in the packet, and the bottom appears latest. The network
layer packet immediately follows the label stack entry which has the
S bit set.
Each label stack entry is broken down into the following fields:
1. Bottom of Stack (S)
This bit is set to one for the last entry in the label stack
(i.e., for the bottom of the stack), and zero for all other
label stack entries.
2. Time to Live (TTL)
This eight-bit field is used to encode a time-to-live value.
The processing of this field is described in section 2.4.
3. Experimental Use
This three-bit field is reserved for experimental use.
4. Label Value
This 20-bit field carries the actual value of the Label.
When a labeled packet is received, the label value at the top
of the stack is looked up. As a result of a successful lookup
one learns:
a) the next hop to which the packet is to be forwarded;
b) the operation to be performed on the label stack before
forwarding; this operation may be to replace the top label
stack entry with another, or to pop an entry off the label
stack, or to replace the top label stack entry and then to
push one or more additional entries on the label stack.
In addition to learning the next hop and the label stack
operation, one may also learn the outgoing data link
encapsulation, and possibly other information which is needed
in order to properly forward the packet.
Rosen, et al. Standards Track [Page 4]
RFC 3032 MPLS Label Stack Encoding January 2001
There are several reserved label values:
i. A value of 0 represents the "IPv4 Explicit NULL Label".
This label value is only legal at the bottom of the label
stack. It indicates that the label stack must be popped,
and the forwarding of the packet must then be based on the
IPv4 header.
ii. A value of 1 represents the "Router Alert Label". This
label value is legal anywhere in the label stack except at
the bottom. When a received packet contains this label
value at the top of the label stack, it is delivered to a
local software module for processing. The actual
forwarding of the packet is determined by the label
beneath it in the stack. However, if the packet is
forwarded further, the Router Alert Label should be pushed
back onto the label stack before forwarding. The use of
this label is analogous to the use of the "Router Alert
Option" in IP packets [5]. Since this label cannot occur
at the bottom of the stack, it is not associated with a
particular network layer protocol.
iii. A value of 2 represents the "IPv6 Explicit NULL Label".
This label value is only legal at the bottom of the label
stack. It indicates that the label stack must be popped,
and the forwarding of the packet must then be based on the
IPv6 header.
iv. A value of 3 represents the "Implicit NULL Label". This
is a label that an LSR may assign and distribute, but
which never actually appears in the encapsulation. When
an LSR would otherwise replace the label at the top of the
stack with a new label, but the new label is "Implicit
NULL", the LSR will pop the stack instead of doing the
replacement. Although this value may never appear in the
encapsulation, it needs to be specified in the Label
Distribution Protocol, so a value is reserved.
v. Values 4-15 are reserved.
2.2. Determining the Network Layer Protocol
When the last label is popped from a packet's label stack (resulting
in the stack being emptied), further processing of the packet is
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
packet's network layer protocol. However, the label stack does not
contain any field which explicitly identifies the network layer
Rosen, et al. Standards Track [Page 5]
RFC 3032 MPLS Label Stack Encoding January 2001
protocol. This means that the identity of the network layer protocol
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
value must also be one which meets the same criteria. If these
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.
If a packet cannot be forwarded for some reason (e.g., it exceeds the
data link MTU), and either its network layer protocol cannot be
identified, or there are no specified protocol-dependent rules for
handling the error condition, then the packet MUST be silently
discarded.
2.3. Generating ICMP Messages for Labeled IP Packets
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -