draft-ietf-mpls-label-encaps-08.txt   rfc3032.txt 
Network Working Group Eric C. Rosen Network Working Group E. Rosen
Internet Draft Yakov Rekhter Request for Comments: 3032 D. Tappan
Expiration Date: January 2001 Daniel Tappan Category: Standards Track G. Fedorkow
Guy Fedorkow
Cisco Systems, Inc. Cisco Systems, Inc.
Y. Rekhter
Dino Farinacci Juniper Networks
Tony Li D. Farinacci
T. Li
Procket Networks, Inc. Procket Networks, Inc.
A. Conta
Alex Conta
TranSwitch Corporation TranSwitch Corporation
January 2001
July 2000
MPLS Label Stack Encoding MPLS Label Stack Encoding
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 specifies an Internet standards track protocol for the
all provisions of Section 10 of RFC2026. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Internet-Drafts are working documents of the Internet Engineering Official Protocol Standards" (STD 1) for the standardization state
Task Force (IETF), its areas, and its working groups. Note that and status of this protocol. Distribution of this memo is unlimited.
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 inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2001). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
"Multi-Protocol Label Switching (MPLS)" [1] 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 Point-to-Point Protocol (PPP) data links, on LAN
other data links as well. On some data links, the label at the top data links, and possibly on other data links as well. On some data
of the stack may be encoded in a different manner, but the techniques links, the label at the top of the stack may be encoded in a
described here MUST be used to encode the remainder of the label different manner, but the techniques described here MUST be used to
stack. This document also specifies rules and procedures for encode the remainder of the label stack. This document also
processing the various fields of the label stack encoding. specifies rules and procedures for processing the various fields of
the label stack encoding.
Table of Contents Table of Contents
1 Introduction ........................................... 3 1 Introduction ........................................... 2
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 ................. 5
2.3 Generating ICMP Messages for Labeled IP Packets ........ 7 2.3 Generating ICMP Messages for Labeled IP Packets ........ 6
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 .. 7
2.4 Processing the Time to Live Field ...................... 9 2.4 Processing the Time to Live Field ...................... 8
2.4.1 Definitions ............................................ 9 2.4.1 Definitions ............................................ 8
2.4.2 Protocol-independent rules ............................. 9 2.4.2 Protocol-independent rules ............................. 8
2.4.3 IP-dependent rules ..................................... 10 2.4.3 IP-dependent rules ..................................... 9
2.4.4 Translating Between Different Encapsulations ........... 10 2.4.4 Translating Between Different Encapsulations ........... 9
3 Fragmentation and Path MTU Discovery ................... 11 3 Fragmentation and Path MTU Discovery ................... 10
3.1 Terminology ............................................ 12 3.1 Terminology ............................................ 11
3.2 Maximum Initially Labeled IP Datagram Size ............. 13 3.2 Maximum Initially Labeled IP Datagram Size ............. 12
3.3 When are Labeled IP Datagrams Too Big? ................. 14 3.3 When are Labeled IP Datagrams Too Big? ................. 13
3.4 Processing Labeled IPv4 Datagrams which are Too Big .... 14 3.4 Processing Labeled IPv4 Datagrams which are Too Big .... 13
3.5 Processing Labeled IPv6 Datagrams which are Too Big .... 15 3.5 Processing Labeled IPv6 Datagrams which are Too Big .... 14
3.6 Implications with respect to Path MTU Discovery ........ 16 3.6 Implications with respect to Path MTU Discovery ........ 15
4 Transporting Labeled Packets over PPP .................. 17 4 Transporting Labeled Packets over PPP .................. 16
4.1 Introduction ........................................... 17 4.1 Introduction ........................................... 16
4.2 A PPP Network Control Protocol for MPLS ................ 18 4.2 A PPP Network Control Protocol for MPLS ................ 17
4.3 Sending Labeled Packets ................................ 19 4.3 Sending Labeled Packets ................................ 18
4.4 Label Switching Control Protocol Configuration Options . 19 4.4 Label Switching Control Protocol Configuration Options . 18
5 Transporting Labeled Packets over LAN Media ............ 19 5 Transporting Labeled Packets over LAN Media ............ 18
6 IANA Considerations .................................... 20 6 IANA Considerations .................................... 19
7 Security Considerations ................................ 20 7 Security Considerations ................................ 19
8 Intellectual Property .................................. 20 8 Intellectual Property .................................. 19
9 Authors' Addresses ..................................... 21 9 Authors' Addresses ..................................... 20
10 References ............................................. 22 10 References ............................................. 22
11 Full Copyright Statement ............................... 23
1. Introduction 1. Introduction
"Multi-Protocol Label Switching (MPLS)" [1] 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.
skipping to change at page 4, line 5 skipping to change at page 3, line 38
document are to be interpreted as described in RFC 2119 [2]. 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
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 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
| Label | Exp |S| TTL | Stack | Label | Exp |S| TTL | Stack
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry
Label: Label Value, 20 bits -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry
Exp: Experimental Use, 3 bits Label: Label Value, 20 bits
S: Bottom of Stack, 1 bit Exp: Experimental Use, 3 bits
TTL: Time to Live, 8 bits S: Bottom of Stack, 1 bit
TTL: Time to Live, 8 bits
Figure 1 Figure 1
The label stack entries appear AFTER the data link layer headers, but The label stack entries appear AFTER the data link layer headers, but
BEFORE any network layer headers. The top of the label stack appears BEFORE any network layer headers. The top of the label stack appears
earliest in the packet, and the bottom appears latest. The network earliest in the packet, and the bottom appears latest. The network
layer packet immediately follows the label stack entry which has the layer packet immediately follows the label stack entry which has the
S bit set. S bit set.
Each label stack entry is broken down into the following fields: Each label stack entry is broken down into the following fields:
1. Bottom of Stack (S) 1. Bottom of Stack (S)
skipping to change at page 5, line 13 skipping to change at page 4, line 36
This three-bit field is reserved for experimental use. This three-bit field is reserved for experimental use.
4. Label Value 4. Label Value
This 20-bit field carries the actual value of the Label. This 20-bit field carries the actual value of the Label.
When a labeled packet is received, the label value at the top 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 of the stack is looked up. As a result of a successful lookup
one learns: one learns:
(a) the next hop to which the packet is to be forwarded; a) the next hop to which the packet is to be forwarded;
(b) the operation to be performed on the label stack before b) the operation to be performed on the label stack before
forwarding; this operation may be to replace the top forwarding; this operation may be to replace the top label
label stack entry with another, or to pop an entry off stack entry with another, or to pop an entry off the label
the label stack, or to replace the top label stack entry stack, or to replace the top label stack entry and then to
and then to push one or more additional entries on the push one or more additional entries on the 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 at the bottom of the This label value is only legal at the bottom of the label
label stack. It indicates that the label stack must be stack. It indicates that the label stack must be popped,
popped, and the forwarding of the packet must then be and the forwarding of the packet must then be based on the
based on the IPv4 header. 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
at the bottom. When a received packet contains this the bottom. When a received packet contains this label
label value at the top of the label stack, it is value at the top of the label stack, it is delivered to a
delivered to a local software module for processing. local software module for processing. The actual
The actual forwarding of the packet is determined by forwarding of the packet is determined by the label
the label beneath it in the stack. However, if the beneath it in the stack. However, if the packet is
packet is forwarded further, the Router Alert Label forwarded further, the Router Alert Label should be pushed
should be pushed back onto the label stack before back onto the label stack before forwarding. The use of
forwarding. The use of this label is analogous to the this label is analogous to the use of the "Router Alert
use of the "Router Alert Option" in IP packets [5]. Option" in IP packets [5]. Since this label cannot occur
Since this label cannot occur at the bottom of the at the bottom of the stack, it is not associated with a
stack, it is not associated with a particular network 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 at the bottom of the This label value is only legal at the bottom of the label
label stack. It indicates that the label stack must be stack. It indicates that the label stack must be popped,
popped, and the forwarding of the packet must then be and the forwarding of the packet must then be based on the
based on the IPv6 header. IPv6 header.
iv. A value of 3 represents the "Implicit NULL Label". iv. A value of 3 represents the "Implicit NULL Label". This
This is a label that an LSR may assign and distribute, is a label that an LSR may assign and distribute, but
but which never actually appears in the encapsulation. which never actually appears in the encapsulation. When
When an LSR would otherwise replace the label at the an LSR would otherwise replace the label at the top of the
top of the stack with a new label, but the new label is stack with a new label, but the new label is "Implicit
"Implicit NULL", the LSR will pop the stack instead of NULL", the LSR will pop the stack instead of doing the
doing the replacement. Although this value may never replacement. Although this value may never appear in the
appear in the encapsulation, it needs to be specified encapsulation, it needs to be specified in the Label
in the Label Distribution Protocol, so a value is Distribution Protocol, so a value is reserved.
reserved.
v. Values 4-15 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 10 skipping to change at page 7, line 28
example the routes from BGP are not distributed into OSPF, and the example the routes from BGP are not distributed into OSPF, and the
LSRs which are not ASBRs do not run BGP. LSRs which are not ASBRs do not run BGP.
In this example, only an ASBR will know how to route to the source of In this example, only an ASBR will know how to route to the source of
some arbitrary packet. If an interior router needs to send an ICMP some arbitrary packet. If an interior router needs to send an ICMP
message to the source of an IP packet, it will not know how to route message to the source of an IP packet, it will not know how to route
the ICMP message. the ICMP message.
One solution is to have one or more of the ASBRs inject "default" One solution is to have one or more of the ASBRs inject "default"
into the IGP. (N.B.: this does NOT require that there be a "default" into the IGP. (N.B.: this does NOT require that there be a "default"
carried by BGP.) This would then ensure that any unlabeled packet carried by BGP.) This would then ensure that any unlabeled packet
which must leave the domain (such as an ICMP packet) gets sent to a which must leave the domain (such as an ICMP packet) gets sent to a
router which has full routing information. The routers with full router which has full routing information. The routers with full
routing information will label the packets before sending them back routing information will label the packets before sending them back
through the transit domain, so the use of default routing within the through the transit domain, so the use of default routing within the
transit domain does not cause any loops. transit domain does not cause any loops.
This solution only works for packets which have globally unique This solution only works for packets which have globally unique
addresses, and for networks in which all the ASBRs have complete addresses, and for networks in which all the ASBRs have complete
routing information. The next subsection describes a solution which routing information. The next subsection describes a solution which
works when these conditions do not hold. works when these conditions do not hold.
skipping to change at page 9, line 8 skipping to change at page 8, line 24
When copying the label stack from the original packet to the ICMP When copying the label stack from the original packet to the ICMP
message, the label values must be copied exactly, but the TTL values 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 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 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 enough to allow the circuitous route that the ICMP message will need
to follow. to follow.
Note that if a packet's TTL expiration is due to the presence of a 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 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 loop as well. Since an ICMP message is never sent as a result of
receiving an ICMP message, and since many implementations throttle receiving an ICMP message, and since many implementations throttle
the rate at which ICMP messages can be generated, this is not the rate at which ICMP messages can be generated, this is not
expected to pose a problem. 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:
(a) one less than the incoming TTL, a) one less than the incoming TTL,
(b) zero. b) zero.
2.4.2. Protocol-independent rules 2.4.2. Protocol-independent rules
If the outgoing TTL of a labeled packet is 0, then the labeled packet If the outgoing TTL of a labeled packet is 0, then the labeled packet
MUST NOT be further forwarded; nor may the label stack be stripped MUST NOT be further forwarded; nor may the label stack be stripped
off and the packet forwarded as an unlabeled packet. The packet's off and the packet forwarded as an unlabeled packet. The packet's
lifetime in the network is considered to have expired. lifetime in the network is considered to have expired.
Depending on the label value in the label stack entry, the packet MAY Depending on the label value in the label stack entry, the packet MAY
be simply discarded, or it may be passed to the appropriate be simply discarded, or it may be passed to the appropriate
skipping to change at page 12, line 10 skipping to change at page 11, line 20
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
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
headers or trailers (e.g., MAC headers, LLC headers, 802.1Q layer headers or trailers (e.g., MAC headers, LLC headers,
headers, PPP header, frame check sequences, etc.). 802.1Q headers, PPP header, frame check sequences, etc.).
When a frame is carrying an unlabeled IP datagram, the Frame When a frame is carrying 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
a labeled IP datagram, the Frame Payload consists of the label carrying a labeled IP datagram, the Frame Payload consists of
stack entries and the IP datagram. the label 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
ethernet is 1500 bytes. ethernet is 1500 bytes.
- True Maximum Frame Payload Size: - True Maximum Frame Payload Size:
The maximum size frame payload which can be sent and received The maximum size frame payload which can be sent and received
properly by the interface hardware attached to the data link. properly by the interface hardware attached to the data link.
On ethernet and 802.3 networks, it is believed that the True On ethernet and 802.3 networks, it is believed that the True
Maximum Frame Payload Size is 4-8 bytes larger than the Maximum Frame Payload Size is 4-8 bytes larger than the
Conventional Maximum Frame Payload Size (as long as neither an Conventional Maximum Frame Payload Size (as long as neither an
802.1Q header nor an 802.1p header is present, and as long as 802.1Q header nor an 802.1p header is present, and as long as
neither can be added by a switch or bridge while a packet is in neither can be added by a switch or bridge while a packet is in
transit to its next hop). For example, it is believed that most transit to its next hop). For example, it is believed that
ethernet equipment could correctly send and receive packets most ethernet equipment could correctly send and receive
carrying a payload of 1504 or perhaps even 1508 bytes, at least, packets carrying a payload of 1504 or perhaps even 1508 bytes,
as long as the ethernet header does not have an 802.1Q or 802.1p at least, as long as the ethernet header does not have an
field. 802.1Q or 802.1p field.
On PPP links, the True Maximum Frame Payload Size may be On PPP links, the True Maximum Frame Payload Size may be
virtually unbounded. virtually unbounded.
- Effective Maximum Frame Payload Size for Labeled Packets: - Effective Maximum Frame Payload Size for Labeled Packets:
This is either the Conventional Maximum Frame Payload Size or the This is either the Conventional Maximum Frame Payload Size or
True Maximum Frame Payload Size, depending on the capabilities of the True Maximum Frame Payload Size, depending on the
the equipment on the data link and the size of the data link capabilities of the equipment on the data link and the size of
header being used. the data link header being used.
- Initially Labeled IP Datagram: - Initially Labeled IP Datagram:
Suppose that an unlabeled IP datagram is received at a particular Suppose that an unlabeled IP datagram is received at a
LSR, and that the the LSR pushes on a label before forwarding the particular LSR, and that the the LSR pushes on a label before
datagram. Such a datagram will be called an Initially Labeled IP forwarding the datagram. Such a datagram will be called an
Datagram at that LSR. Initially Labeled IP Datagram at that LSR.
- Previously Labeled IP Datagram: - Previously Labeled IP Datagram:
An IP datagram which had already been labeled before it was An IP datagram which had already been labeled before it was
received by a particular LSR. received by a particular LSR.
3.2. Maximum Initially Labeled IP Datagram Size 3.2. Maximum Initially Labeled IP Datagram Size
Every LSR which is capable of Every LSR which is capable of
(a) receiving an unlabeled IP datagram, a) receiving an unlabeled IP datagram,
(b) adding a label stack to the datagram, and b) adding a label stack to the datagram, and
(c) forwarding the resulting labeled packet, c) forwarding the resulting labeled packet,
SHOULD support a configuration parameter known as the "Maximum SHOULD support a configuration parameter known as the "Maximum
Initially Labeled IP Datagram Size", which can be set to a non- Initially Labeled IP Datagram Size", which can be set to a non-
negative value. negative value.
If this configuration parameter is set to zero, it has no effect. If this configuration parameter is set to zero, it has no effect.
If it is set to a positive value, it is used in the following way. If it is set to a positive value, it is used in the following way.
If: If:
(a) an unlabeled IP datagram is received, and
(b) that datagram does not have the DF bit set in its IP header, a) an unlabeled IP datagram is received, and
and b) that datagram does not have the DF bit set in its IP header,
(c) that datagram needs to be labeled before being forwarded, and and
(d) the size of the datagram (before labeling) exceeds the value c) that datagram needs to be labeled before being forwarded, and
of the parameter, d) the size of the datagram (before labeling) exceeds the value of
the parameter,
then then
(a) the datagram must be broken into fragments, each of whose size a) the datagram must be broken into fragments, each of whose size
is no greater than the value of the parameter, and is no greater than the value of the parameter, and
(b) each fragment must be labeled and then forwarded.
b) each fragment must be labeled and then forwarded.
For example, if this configuration parameter is set to a value of For example, if this configuration parameter is set to a value of
1488, then any unlabeled IP datagram containing more than 1488 bytes 1488, then any unlabeled IP datagram containing more than 1488 bytes
will be fragmented before being labeled. Each fragment will be will be fragmented before being labeled. Each fragment will be
capable of being carried on a 1500-byte data link, without further capable of being carried on a 1500-byte data link, without further
fragmentation, even if as many as three labels are pushed onto its fragmentation, even if as many as three labels are pushed onto its
label stack. label stack.
In other words, setting this parameter to a non-zero value allows one In other words, setting this parameter to a non-zero value allows one
to eliminate all fragmentation of Previously Labeled IP Datagrams, to eliminate all fragmentation of Previously Labeled IP Datagrams,
skipping to change at page 15, line 5 skipping to change at page 14, line 11
execute the following algorithm: execute the following algorithm:
1. Strip off the label stack entries to obtain the IP datagram. 1. Strip off the label stack entries to obtain the IP datagram.
2. Let N be the number of bytes in the label stack (i.e, 4 times 2. Let N be the number of bytes in the label stack (i.e, 4 times
the number of label stack entries). the number of label stack entries).
3. If the IP datagram does NOT have the "Don't Fragment" bit set 3. If the IP datagram does NOT have the "Don't Fragment" bit set
in its IP header: in its IP header:
a. convert it into fragments, each of which MUST be at least a. convert it into fragments, each of which MUST be at least N
N bytes less than the Effective Maximum Frame Payload bytes less than the Effective Maximum Frame Payload Size.
Size.
b. Prepend each fragment with the same label header that b. Prepend each fragment with the same label header that would
would have been on the original datagram had have been on the original datagram had fragmentation not
fragmentation not been necessary. been necessary.
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 [3] to "Fragmentation Required i. set its Code field [3] to "Fragmentation Required and DF
and DF Set", Set",
ii. set its Next-Hop MTU field [4] to the difference ii. set its Next-Hop MTU field [4] to the difference between
between the Effective Maximum Frame Payload Size the Effective Maximum Frame Payload Size and the value
and the value of N 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:
1. Strip off the label stack entries to obtain the IP datagram. 1. Strip off the label stack entries to obtain the IP datagram.
2. Let N be the number of bytes in the label stack (i.e, 4 times 2. Let N be the number of bytes in the label stack (i.e., 4 times
the number of label stack entries). the number of label stack entries).
3. If the IP datagram contains more than 1280 bytes (not counting 3. If the IP datagram contains more than 1280 bytes (not counting
the label stack entries), or if it does not contain a fragment the label stack entries), or if it does not contain a fragment
header, then: header, then:
a. Create an ICMP Packet Too Big Message, and set its Next- a. Create an ICMP Packet Too Big Message, and set its Next-Hop
Hop MTU field to the difference between the Effective MTU field to the difference between the Effective Maximum
Maximum Frame Payload Size and the value of N Frame Payload Size and the value of N
b. If possible, transmit the ICMP Packet Too Big Message to b. If possible, transmit the ICMP Packet Too Big Message to the
the source of the datagram. source of the datagram.
c. discard the labeled IPv6 datagram. c. discard the labeled IPv6 datagram.
4. If the IP datagram is not larger than 1280 octets, and it 4. If the IP datagram is not larger than 1280 octets, and it
contains a fragment header, then contains a fragment header, then
a. Convert it into fragments, each of which MUST be at least a. Convert it into fragments, each of which MUST be at least N
N bytes less than the Effective Maximum Frame Payload bytes less than the Effective Maximum Frame Payload Size.
Size.
b. Prepend each fragment with the same label header that b. Prepend each fragment with the same label header that would
would have been on the original datagram had have been on the original datagram had fragmentation not
fragmentation not been necessary. been necessary.
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 [4]. 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
skipping to change at page 17, line 5 skipping to change at page 16, line 11
where a labeled IP Datagram's fragmentation needs to occur, it is where a labeled IP Datagram's fragmentation needs to occur, it is
possible to cause an ICMP Destination Unreachable message to be possible to cause an ICMP Destination Unreachable message to be
routed to the packet's source address. See section 2.3. routed to the packet's source address. See section 2.3.
If it is not possible to forward an ICMP message from within an MPLS If it is not possible to forward an ICMP message from within an MPLS
"tunnel" to a packet's source address, but the network configuration "tunnel" to a packet's source address, but the network configuration
makes it possible for the LSR at the transmitting end of the tunnel makes it possible for the LSR at the transmitting end of the tunnel
to receive packets that must go through the tunnel, but are too large to receive packets that must go through the tunnel, but are too large
to pass through the tunnel unfragmented, then: to pass through the tunnel unfragmented, then:
- The LSR at the transmitting end of the tunnel MUST be able to - The LSR at the transmitting end of the tunnel MUST be able to
determine the MTU of the tunnel as a whole. It MAY do this by determine the MTU of the tunnel as a whole. It MAY do this by
sending packets through the tunnel to the tunnel's receiving sending packets through the tunnel to the tunnel's receiving
endpoint, and performing Path MTU Discovery with those packets. endpoint, and performing Path MTU Discovery with those packets.
- Any time the transmitting endpoint of the tunnel needs to send a - Any time the transmitting endpoint of the tunnel needs to send
packet into the tunnel, and that packet has the DF bit set, and a packet into the tunnel, and that packet has the DF bit set,
it exceeds the tunnel MTU, the transmitting endpoint of the and 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
source, with code "Fragmentation Required and DF Set", and the the source, with code "Fragmentation Required and DF Set", and
Next-Hop MTU Field set as described above. the 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) [6] 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
skipping to change at page 20, line 24 skipping to change at page 19, line 24
7. Security Considerations 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
the network layer header being in a fixed place relative to the the network layer header being in a fixed place relative to the
data link layer header. These procedures will not work when the data link layer header. These procedures will not work when
MPLS encapsulation is used, because that encapsulation is of a the MPLS encapsulation is used, because that encapsulation is
variable size. of a 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
determining who the label writer was for any particular label. of determining who the label writer was for any particular
If labeled packets are accepted from untrusted sources, the label. If labeled packets are accepted from untrusted sources,
result may be that packets are routed in an illegitimate manner. the result may be that packets are routed in an illegitimate
manner.
8. Intellectual Property 8. Intellectual Property
The IETF has been notified of intellectual property rights claimed in The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this regard to some or all of the specification contained in this
document. For more information consult the online list of claimed document. For more information consult the online list of claimed
rights. rights.
9. Authors' Addresses 9. 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
EMail: 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
EMail: tappan@cisco.com
Yakov Rekhter Yakov Rekhter
Cisco Systems, Inc. Juniper Networks
170 Tasman Drive 1194 N. Mathilda Avenue
San Jose, CA, 95134 Sunnyvale, CA 94089
E-mail: yakov@cisco.com
EMail: yakov@juniper.net
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
EMail: fedorkow@cisco.com
Dino Farinacci Dino Farinacci
Procket Networks, Inc. Procket Networks, Inc.
3910 Freedom Circle, Ste. 102A 3910 Freedom Circle, Ste. 102A
Santa Clara, CA 95054 Santa Clara, CA 95054
E-mail: dino@procket.com
EMail: dino@procket.com
Tony Li Tony Li
Procket Networks, Inc. Procket Networks, Inc.
3910 Freedom Circle, Ste. 102A 3910 Freedom Circle, Ste. 102A
Santa Clara, CA 95054 Santa Clara, CA 95054
E-mail: tli@procket.com
EMail: tli@procket.com
Alex Conta Alex Conta
TranSwitch Corporation TranSwitch Corporation
3 Enterprise Drive 3 Enterprise Drive
Shelton, CT, 06484 Shelton, CT, 06484
E-mail: aconta@txc.com
EMail: aconta@txc.com
10. References 10. References
[1] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol Label [1] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label
Switching Architecture", Work in Progress, July 2000. Switching Architecture", RFC 3031, January 2001.
[2] 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", BCP 14, RFC 2119, March 1997.
[3] Postel, J., "Internet Control Message Protocol", RFC 792, [3] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
September 1981. September 1981.
[4] Mogul, J. and Deering S., "Path MTU Discovery", RFC 1191, [4] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990. November 1990.
[5] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. [5] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[6] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC [6] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51,
1661, STD 51, July 1994. RFC 1661, July 1994.
[7] Conta, A. and Deering, S., "Internet Control Message Protocol [7] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", (ICMPv6) for the Internet Protocol Version 6 (IPv6)
RFC 1885, December 1995. Specification", RFC 1885, December 1995.
[8] McCann, J., Deering, S. and Mogul, J., "Path MTU Discovery for IP [8] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP
version 6", RFC 1981, August 1996. version 6", RFC 1981, August 1996.
[9] 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 G. Swallow, "MPLS Using LDP and ATM VC Switching", RFC 3035,
Progress, June 2000. January 2001.
11. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 76 change blocks. 
250 lines changed or deleted 244 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/