idnits 2.17.1 draft-ietf-mpls-label-encaps-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([1,2,3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 49: '... described here MUST be used to encod...' RFC 2119 keyword, line 112: '... document MUST be used for the addit...' RFC 2119 keyword, line 119: '... MUST...' RFC 2119 keyword, line 124: '... MUST NOT...' RFC 2119 keyword, line 129: '... SHOULD...' (19 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1998) is 9417 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '4' is defined on line 926, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 928, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 930, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 936, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 940, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-mpls-arch-02 == Outdated reference: A later version (-05) exists of draft-ietf-mpls-framework-02 -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Normative reference to a draft: ref. '3' ** Obsolete normative reference: RFC 1885 (ref. '9') (Obsoleted by RFC 2463) ** Obsolete normative reference: RFC 1981 (ref. '10') (Obsoleted by RFC 8201) -- Possible downref: Normative reference to a draft: ref. '11' Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Eric C. Rosen 2 Internet Draft Yakov Rekhter 3 Expiration Date: January 1999 Daniel Tappan 4 Dino Farinacci 5 Guy Fedorkow 6 Cisco Systems, Inc. 7 Tony Li 8 Juniper Networks, Inc. 9 Alex Conta 10 Lucent Technologies 12 July 1998 14 MPLS Label Stack Encoding 16 draft-ietf-mpls-label-encaps-02.txt 18 Status of this Memo 20 This document is an Internet-Draft. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 To view the entire list of current Internet-Drafts, please check the 31 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 32 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 33 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 34 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 36 Abstract 38 "Multi-Protocol Label Switching (MPLS)" [1,2,3] requires a set of 39 procedures for augmenting network layer packets with "label stacks", 40 thereby turning them into "labeled packets". Routers which support 41 MPLS are known as "Label Switching Routers", or "LSRs". In order to 42 transmit a labeled packet on a particular data link, an LSR must 43 support an encoding technique which, given a label stack and a 44 network layer packet, produces a labeled packet. This document 45 specifies the encoding to be used by an LSR in order to transmit 46 labeled packets on PPP data links, on LAN data links, and possibly on 47 other data links as well. On some data links, the label at the top 48 of the stack may be encoded in a different manner, but the techniques 49 described here MUST be used to encode the remainder of the label 50 stack. This document also specifies rules and procedures for 51 processing the various fields of the label stack encoding. 53 Table of Contents 55 1 Introduction ........................................... 3 56 1.1 Specification of Requirements .......................... 3 57 2 The Label Stack ........................................ 4 58 2.1 Encoding the Label Stack ............................... 4 59 2.2 Determining the Network Layer Protocol ................. 7 60 2.3 Generating ICMP Messages for Labeled IP Packets ........ 8 61 2.3.1 Tunneling through a Transit Routing Domain ............. 8 62 2.3.2 Tunneling Private Addresses through a Public Backbone .. 9 63 2.4 Processing the Time to Live Field ...................... 9 64 2.4.1 Definitions ............................................ 9 65 2.4.2 Protocol-independent rules ............................. 9 66 2.4.3 IP-dependent rules ..................................... 10 67 2.4.4 Translating Between Different Encapsulations ........... 10 68 3 Fragmentation and Path MTU Discovery ................... 11 69 3.1 Terminology ............................................ 12 70 3.2 Maximum Initially Labeled IP Datagram Size ............. 13 71 3.3 When are Labeled IP Datagrams Too Big? ................. 14 72 3.4 Processing Labeled IPv4 Datagrams which are Too Big .... 14 73 3.5 Processing Labeled IPv6 Datagrams which are Too Big .... 15 74 3.6 Implications with respect to Path MTU Discovery ........ 16 75 4 Transporting Labeled Packets over PPP .................. 17 76 4.1 Introduction ........................................... 17 77 4.2 A PPP Network Control Protocol for MPLS ................ 17 78 4.3 Sending Labeled Packets ................................ 18 79 4.4 Label Switching Control Protocol Configuration Options . 19 80 5 Transporting Labeled Packets over LAN Media ............ 19 81 6 Security Considerations ................................ 19 82 7 Authors' Addresses ..................................... 19 83 8 References ............................................. 20 85 1. Introduction 87 "Multi-Protocol Label Switching (MPLS)" [1,2,3] requires a set of 88 procedures for augmenting network layer packets with "label stacks", 89 thereby turning them into "labeled packets". Routers which support 90 MPLS are known as "Label Switching Routers", or "LSRs". In order to 91 transmit a labeled packet on a particular data link, an LSR must 92 support an encoding technique which, given a label stack and a 93 network layer packet, produces a labeled packet. 95 This document specifies the encoding to be used by an LSR in order to 96 transmit labeled packets on PPP data links and on LAN data links. 97 The specified encoding may also be useful for other data links as 98 well. 100 This document also specifies rules and procedures for processing the 101 various fields of the label stack encoding. Since MPLS is 102 independent of any particular network layer protocol, the majority of 103 such procedures are also protocol-independent. A few, however, do 104 differ for different protocols. In this document, we specify the 105 protocol-independent procedures, and we specify the protocol- 106 dependent procedures for IPv4 and IPv6. 108 LSRs that are implemented on certain switching devices (such as ATM 109 switches) may use different encoding techniques for encoding the top 110 one or two entries of the label stack. When the label stack has 111 additional entries, however, the encoding technique described in this 112 document MUST be used for the additional label stack entries. 114 1.1. Specification of Requirements 116 In this document, several words are used to signify the requirements 117 of the specification. These words are often capitalized. 119 MUST 121 This word, or the adjective "required", means that the 122 definition is an absolute requirement of the specification. 124 MUST NOT 126 This phrase means that the definition is an absolute prohibition 127 of the specification. 129 SHOULD 131 This word, or the adjective "recommended", means that there may 132 exist valid reasons in particular circumstances to ignore this 133 item, but the full implications must be understood and carefully 134 weighed before choosing a different course. 136 MAY 138 This word, or the adjective "optional", means that this item is 139 one of an allowed set of alternatives. An implementation which 140 does not include this option MUST be prepared to interoperate 141 with another implementation which does include the option. 143 2. The Label Stack 145 2.1. Encoding the Label Stack 147 The label stack is represented as a sequence of "label stack 148 entries". Each label stack entry is represented by 4 octets. This 149 is shown in Figure 1. 151 0 1 2 3 152 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 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label 154 | Label | CoS |S| TTL | Stack 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry 157 Label: Label Value, 20 bits 158 CoS: Class of Service, 3 bits 159 S: Bottom of Stack, 1 bit 160 TTL: Time to Live, 8 bits 162 Figure 1 164 The label stack entries appear AFTER the data link layer headers, but 165 BEFORE any network layer headers. The top of the label stack appears 166 earliest in the packet, and the bottom appears latest. The network 167 layer packet immediately follows the label stack entry which has the 168 S bit set. 170 Each label stack entry is broken down into the following fields: 172 1. Bottom of Stack (S) 174 This bit is set to one for the last entry in the label stack 175 (i.e., for the bottom of the stack), and zero for all other 176 label stack entries. 178 2. Time to Live (TTL) 180 This eight-bit field is used to encode a time-to-live value. 181 The processing of this field is described in section 2.4. 183 3. Class of Service (CoS) 185 This three-bit field is used to identify a "Class of Service". 186 The setting of this field is intended to affect the scheduling 187 and/or discard algorithms which are applied to the packet as it 188 is transmitted through the network. 190 When an unlabeled packet is initially labeled, the value 191 assigned to the CoS field in the label stack entry is 192 determined by policy. Some possible policies are: 194 - the CoS value is a function of the IP ToS value 196 - the CoS value is a function of the packet's input interface 198 - the CoS value is a function of the "flow type" 200 Of course, many other policies are also possible. 202 When an additional label is pushed onto the stack of a packet 203 that is already labeled: 205 - in general, the value of the CoS field in the new top stack 206 entry should be equal to the value of the CoS field of the 207 old top stack entry; 209 - however, in some cases, most likely at boundaries between 210 network service providers, the value of the CoS field in 211 the new top stack entry may be determined by policy. 213 4. Label Value 215 This 20-bit field carries the actual value of the Label. 217 When a labeled packet is received, the label value at the top 218 of the stack is looked up. As a result of a successful lookup 219 one learns: 221 (a) information needed to forward the packet, such as the 222 next hop and the outgoing data link encapsulation; 223 however, the precise queue to put the packet on, or 224 information as to how to schedule the packet, may be a 225 function of both the label value AND the CoS field 226 value; 228 (b) the operation to be performed on the label stack before 229 forwarding; this operation may be to replace the top 230 label stack entry with another, or to pop an entry off 231 the label stack, or to replace the top label stack entry 232 and then to push one or more additional entries on the 233 label stack. 235 There are several reserved label values: 237 i. A value of 0 represents the "IPv4 Explicit NULL Label". 238 When this label value is the sole label stack entry, it 239 indicates that the label stack must be popped, and the 240 forwarding of the packet must then be based on the IPv4 241 header. When this label value is not the sole label 242 stack entry, it indicates that the label stack must be 243 popped, and the forwarding of the packet must then be 244 based on the label value which then rises to the top of 245 the stack. 247 ii. A value of 1 represents the "Router Alert Label". This 248 label value is legal anywhere in the label stack except 249 at the bottom. When a received packet contains this 250 label value at the top of the label stack, it is 251 delivered to a local software module for processing. 252 The actual forwarding of the packet is determined by 253 the label beneath it in the stack. However, if the 254 packet is forwarded further, the Router Alert Label 255 should be pushed back onto the label stack before 256 forwarding. The use of this label is analogous to the 257 use of the "Router Alert Option" in IP packets [7]. 258 Since this label cannot occur at the bottom of the 259 stack, it is not associated with a particular network 260 layer protocol. 262 iii. A value of 2 represents the "IPv6 Explicit NULL Label". 263 This label value is only legal when it is the sole 264 label stack entry. It indicates that the label stack 265 must be popped, and the forwarding of the packet must 266 then be based on the IPv6 header. 268 iv. A value of 3 represents the "Implicit NULL Label". 269 This is a label that an LSR may assign and distribute, 270 but which never actually appears in the encapsulation. 271 When an LSR would otherwise replace the label at the 272 top of the stack with a new label, but the new label is 273 "Implicit NULL", the LSR will pop the stack instead of 274 doing the replacement. Although this value may never 275 appear in the encapsulation, it needs to be specified 276 in the Label Distribution Protocol, so a value is 277 reserved. 279 v. Values 4-16 are reserved. 281 2.2. Determining the Network Layer Protocol 283 When the last label is popped from a packet's label stack (resulting 284 in the stack being emptied), further processing of the packet is 285 based on the packet's network layer header. The LSR which pops the 286 last label off the stack must therefore be able to identify the 287 packet's network layer protocol. However, the label stack does not 288 contain any field which explicitly identifies the network layer 289 protocol. This means that the identity of the network layer protocol 290 must be inferable from the value of the label which is popped from 291 the bottom of the stack, possibly along with the contents of the 292 network layer header itself. 294 Therefore, when the first label is pushed onto a network layer 295 packet, either the label must be one which is used ONLY for packets 296 of a particular network layer, or the label must be one which is used 297 ONLY for a specified set of network layer protocols, where packets of 298 the specified network layers can be distinguished by inspection of 299 the network layer header. Furthermore, whenever that label is 300 replaced by another label value during a packet's transit, the new 301 value must also be one which meets the same criteria. If these 302 conditions are not met, the LSR which pops the last label off a 303 packet will not be able to identify the packet's network layer 304 protocol. 306 Adherence to these conditions does not necessarily enable 307 intermediate nodes to identify a packet's network layer protocol. 308 Under ordinary conditions, this is not necessary, but there are error 309 conditions under which it is desirable. For instance, if an 310 intermediate LSR determines that a labeled packet is undeliverable, 311 it may be desirable for that LSR to generate error messages which are 312 specific to the packet's network layer. The only means the 313 intermediate LSR has for identifying the network layer is inspection 314 of the top label and the network layer header. So if intermediate 315 nodes are to be able to generate protocol-specific error messages for 316 labeled packets, all labels in the stack must meet the criteria 317 specified above for labels which appear at the bottom of the stack. 319 2.3. Generating ICMP Messages for Labeled IP Packets 321 Section 2.4 and section 3 discuss situations in which it is desirable 322 to generate ICMP messages for labeled IP packets. In order for a 323 particular LSR to be able to generate an ICMP packet and have that 324 packet sent to the source of the IP packet, two conditions must hold: 326 1. it must be possible for that LSR to determine that a particular 327 labeled packet is an IP packet; 329 2. it must be possible for that LSR to route to the packet's IP 330 source address. 332 Condition 1 is discussed in section 2.2. The following two 333 subsections discuss condition 2. However, there will be some cases 334 in which condition 2 does not hold at all, and in these cases it will 335 not be possible to generate the ICMP message. 337 2.3.1. Tunneling through a Transit Routing Domain 339 Suppose one is using MPLS to "tunnel" through a transit routing 340 domain, where the external routes are not leaked into the domain's 341 interior routers. For example, the interior routers may be running 342 OSPF, and may only know how to reach destinations within that OSPF 343 domain. The domain might contain several Autonomous System Border 344 Routers (ASBRs), which talk BGP to each other. However, in this 345 example the routes from BGP are not distributed into OSPF, and the 346 LSRs which are not ASBRs do not run BGP. 348 In this example, only an ASBR will know how to route to the source of 349 some arbitrary packet. If an interior router needs to send an ICMP 350 message to the source of an IP packet, it will not know how to route 351 the ICMP message. 353 One solution is to have one or more of the ASBRs inject "default" 354 into the IGP. (N.B.: this does NOT require that there be a "default" 355 carried by BGP.) This would then ensure that any unlabeled packet 356 which must leave the domain (such as an ICMP packet) gets sent to a 357 router which has full routing information. The routers with full 358 routing information will label the packets before sending them back 359 through the transit domain, so the use of default routing within the 360 transit domain does not cause any loops. 362 This solution only works for packets which have globally unique 363 addresses, and for networks in which all the ASBRs have complete 364 routing information. The next subsection describes a solution which 365 works when these conditions do not hold. 367 2.3.2. Tunneling Private Addresses through a Public Backbone 369 In some cases where MPLS is used to tunnel through a routing domain, 370 it may not be possible to route to the source address of a fragmented 371 packet at all. This would be the case, for example, if the IP 372 addresses carried in the packet were private (i.e., not globally 373 unique) addresses, and MPLS were being used to tunnel those packets 374 through a public backbone. Default routing to an ASBR will not work 375 in this environment. 377 In this environment, in order to send an ICMP message to the source 378 of a packet, one can copy the label stack from the original packet to 379 the ICMP message, and then label switch the ICMP message. This will 380 cause the message to proceed in the direction of the original 381 packet's destination, rather than its source. Unless the message is 382 label switched all the way to the destination host, it will end up, 383 unlabeled, in a router which does know how to route to the source of 384 original packet, at which point the message will be sent in the 385 proper direction. 387 2.4. Processing the Time to Live Field 389 2.4.1. Definitions 391 The "incoming TTL" of a labeled packet is defined to be the value of 392 the TTL field of the top label stack entry when the packet is 393 received. 395 The "outgoing TTL" of a labeled packet is defined to be the larger 396 of: 398 (a) one less than the incoming TTL, 399 (b) zero. 401 2.4.2. Protocol-independent rules 403 If the outgoing TTL of a labeled packet is 0, then the labeled packet 404 MUST NOT be further forwarded; nor may the label stack be stripped 405 off and the packet forwarded as an unlabeled packet. The packet's 406 lifetime in the network is considered to have expired. 408 Depending on the label value in the label stack entry, the packet MAY 409 be simply discarded, or it may be passed to "ordinary" network layer 410 for error processing (e.g., for the generation of an ICMP error 411 message, see section 2.3). 413 When a labeled packet is forwarded, the TTL field of the label stack 414 entry at the top of the label stack must be set to the outgoing TTL 415 value. 417 Note that the outgoing TTL value is a function solely of the incoming 418 TTL value, and is independent of whether any labels are pushed or 419 popped before forwarding. There is no significance to the value of 420 the TTL field in any label stack entry which is not at the top of the 421 stack. 423 2.4.3. IP-dependent rules 425 We define the "IP TTL" field to be the value of the IPv4 TTL field, 426 or the value of the IPv6 Hop Limit field, whichever is applicable. 428 When an IP packet is first labeled, the TTL field of the label stack 429 entry MUST BE set to the value of the IP TTL field. (If the IP TTL 430 field needs to be decremented, as part of the IP processing, it is 431 assumed that this has already been done.) 433 When a label is popped, and the resulting label stack is empty, then 434 the value of the IP TTL field MUST BE replaced with the outgoing TTL 435 value, as defined above. In IPv4 this also requires modification of 436 the IP header checksum. 438 2.4.4. Translating Between Different Encapsulations 440 Sometimes an LSR may receive a labeled packet over, say, a label 441 switching controlled ATM (LC-ATM) interface [11], and may need to 442 send it out over a PPP or LAN link. Then the incoming packet will 443 not be received using the encapsulation specified in this document, 444 but the outgoing packet will be sent using the encapsulation 445 specified in this document. 447 In this case, the value of the "incoming TTL" is determined by the 448 procedures used for carrying labeled packets on, e.g., LC-ATM 449 interfaces. TTL processing then proceeds as described above. 451 Sometimes an LSR may receive a labeled packet over a PPP or a LAN 452 link, and may need to send it out, say, an LC-ATM interface. Then 453 the incoming packet will be received using the encapsulation 454 specified in this document, but the outgoing packet will not be send 455 using the encapsulation specified in this document. In this case, 456 the procedure for carrying the value of the "outgoing TTL" is 457 determined by the procedures used for carrying labeled packets on, 458 e.g., LC-ATM interfaces. 460 3. Fragmentation and Path MTU Discovery 462 Just as it is possible to receive an unlabeled IP datagram which is 463 too large to be transmitted on its output link, it is possible to 464 receive a labeled packet which is too large to be transmitted on its 465 output link. 467 It is also possible that a received packet (labeled or unlabeled) 468 which was originally small enough to be transmitted on that link 469 becomes too large by virtue of having one or more additional labels 470 pushed onto its label stack. In label switching, a packet may grow 471 in size if additional labels get pushed on. Thus if one receives a 472 labeled packet with a 1500-byte frame payload, and pushes on an 473 additional label, one needs to forward it as frame with a 1504-byte 474 payload. 476 This section specifies the rules for processing labeled packets which 477 are "too large". In particular, it provides rules which ensure that 478 hosts implementing RFC 1191 Path MTU Discovery, and hosts using IPv6, 479 will be able to generate IP datagrams that do not need fragmentation, 480 even if they get labeled as the traverse the network. 482 In general, IPv4 hosts which do not implement RFC 1191 Path MTU 483 Discovery send IP datagrams which contain no more than 576 bytes. 484 Since the MTUs in use on most data links today are 1500 bytes or 485 more, the probability that such datagrams will need to get 486 fragmented, even if they get labeled, is very small. 488 Some hosts that do not implement RFC 1191 Path MTU Discovery will 489 generate IP datagrams containing 1500 bytes, as long as the IP Source 490 and Destination addresses are on the same subnet. These datagrams 491 will not pass through routers, and hence will not get fragmented. 493 Unfortunately, some hosts will generate IP datagrams containing 1500 494 bytes, as long the IP Source and Destination addresses do not have 495 the same classful network number. This is the one case in which 496 there is any risk of fragmentation when such datagrams get labeled. 497 (Even so, fragmentation is not likely unless the packet must traverse 498 an ethernet of some sort between the time it first gets labeled and 499 the time it gets unlabeled.) 501 This document specifies procedures which allow one to configure the 502 network so that large datagrams from hosts which do not implement 503 Path MTU Discovery get fragmented just once, when they are first 504 labeled. These procedures make it possible (assuming suitable 505 configuration) to avoid any need to fragment packets which have 506 already been labeled. 508 3.1. Terminology 510 With respect to a particular data link, we can use the following 511 terms: 513 - Frame Payload: 515 The contents of a data link frame, excluding any data link layer 516 headers or trailers (e.g., MAC headers, LLC headers, 802.1Q 517 headers, PPP header, frame check sequences, etc.). 519 When a frame is carrying an an unlabeled IP datagram, the Frame 520 Payload is just the IP datagram itself. When a frame is carrying 521 a labeled IP datagram, the Frame Payload consists of the label 522 stack entries and the IP datagram. 524 - Conventional Maximum Frame Payload Size: 526 The maximum Frame Payload size allowed by data link standards. 527 For example, the Conventional Maximum Frame Payload Size for 528 ethernet is 1500 bytes. 530 - True Maximum Frame Payload Size: 532 The maximum size frame payload which can be sent and received 533 properly by the interface hardware attached to the data link. 535 On ethernet and 802.3 networks, it is believed that the True 536 Maximum Frame Payload Size is 4-8 bytes larger than the 537 Conventional Maximum Frame Payload Size (as long neither an 538 802.1Q header nor an 802.1p header is present, and as long as 539 neither can be added by a switch or bridge while a packet is in 540 transit to its next hop). For example, it is believed that most 541 ethernet equipment could correctly send and receive packets 542 carrying a payload of 1504 or perhaps even 1508 bytes, at least, 543 as long as the ethernet header does not have an 802.1Q or 802.1p 544 field. 546 On PPP links, the True Maximum Frame Payload Size may be 547 virtually unbounded. 549 - Effective Maximum Frame Payload Size for Labeled Packets: 551 This is either be the Conventional Maximum Frame Payload Size or 552 the True Maximum Frame Payload Size, depending on the 553 capabilities of the equipment on the data link and the size of 554 the ethernet header being used. 556 - Initially Labeled IP Datagram 558 Suppose that an unlabeled IP datagram is received at a particular 559 LSR, and that the the LSR pushes on a label before forwarding the 560 datagram. Such a datagram will be called an Initially Labeled IP 561 Datagram at that LSR. 563 - Previously Labeled IP Datagram 565 An IP datagram which had already been labeled before it was 566 received by a particular LSR. 568 3.2. Maximum Initially Labeled IP Datagram Size 570 Every LSR which is capable of 572 (a) receiving an unlabeled IP datagram, 573 (b) adding a label stack to the datagram, and 574 (c) forwarding the resulting labeled packet, 576 MUST support a configuration parameter known as the "Maximum IP 577 Datagram Size for Labeling", which can be set to a non-negative 578 value. 580 If this configuration parameter is set to zero, it has no effect. 582 If it is set to a positive value, it is used in the following way. 583 If: 584 (a) an unlabeled IP datagram is received, and 585 (b) that datagram does not have the DF bit set in its IP header, 586 and 587 (c) that datagram needs to be labeled before being forwarded, and 588 (d) the size of the datagram (before labeling) exceeds the value 589 of the parameter, 590 then 591 (a) the datagram must be broken into fragments, each of whose size 592 is no greater than the value of the parameter, and 593 (b) each fragment must be labeled and then forwarded. 595 If this configuration parameter is set to a value of 1488, for 596 example, then any unlabeled IP datagram containing more than 1488 597 bytes will be fragmented before being labeled. Each fragment will be 598 capable of being carried on a 1500-byte data link, without further 599 fragmentation, even if as many as three labels are pushed onto its 600 label stack. 602 In other words, setting this parameter to a non-zero value allows one 603 to eliminate all fragmentation of Previously Labeled IP Datagrams, 604 but it may cause some unnecessary fragmentation of Initially Labeled 605 IP Datagrams. 607 Note that the parameter has no effect on IP Datagrams that have the 608 DF bit set, which means that it has no effect on Path MTU Discovery. 610 3.3. When are Labeled IP Datagrams Too Big? 612 A labeled IP datagram whose size exceeds the Conventional Maximum 613 Frame Payload Size of the data link over which it is to be forwarded 614 MAY be considered to be "too big". 616 A labeled IP datagram whose size exceeds the True Maximum Frame 617 Payload Size of the data link over which it is to be forwarded MUST 618 be considered to be "too big". 620 A labeled IP datagram which is not "too big" MUST be transmitted 621 without fragmentation. 623 3.4. Processing Labeled IPv4 Datagrams which are Too Big 625 If a labeled IPv4 datagram is "too big", and the DF bit is not set in 626 its IP header, then the LSR MAY discard the datagram. 628 Note that discarding such datagrams is a sensible procedure only if 629 the "Maximum Initially Labeled IP Datagram Size" is set to a non-zero 630 value in every LSR in the network which is capable of adding a label 631 stack to an unlabeled IP datagram. 633 If the LSR chooses not to discard a labeled IPv4 datagram which is 634 too big, or if the DF bit is set in that datagram, then it MUST 635 execute the following algorithm: 637 1. Strip off the label stack entries to obtain the IP datagram. 639 2. Let N be the number of bytes in the label stack (i.e, 4 times 640 the number of label stack entries). 642 3. If the IP datagram does NOT have the "Don't Fragment" bit set 643 in its IP header: 645 a. convert it into fragments, each of which MUST be at least 646 N bytes less than the Effective Maximum Frame Payload 647 Size. 649 b. Prepend each fragment with the same label header that 650 would have been on the original datagram had 651 fragmentation not been necessary. 653 c. Forward the fragments 655 4. If the IP datagram has the "Don't Fragment" bit set in its IP 656 header: 658 a. the datagram MUST NOT be forwarded 660 b. Create an ICMP Destination Unreachable Message: 662 i. set its Code field (RFC 792) to "Fragmentation 663 Required and DF Set", 665 ii. set its Next-Hop MTU field (RFC 1191) to the 666 difference between the Effective Maximum Frame 667 Payload Size and the value of N 669 c. If possible, transmit the ICMP Destination Unreachable 670 Message to the source of the of the discarded datagram. 672 3.5. Processing Labeled IPv6 Datagrams which are Too Big 674 To process a labeled IPv6 datagram which is too big, an LSR MUST 675 execute the following algorithm: 677 1. Strip off the label stack entries to obtain the IP datagram. 679 2. Let N be the number of bytes in the label stack (i.e, 4 times 680 the number of label stack entries). 682 3. If the IP datagram contains more than 1280 bytes (not counting 683 the label stack entries), then: 685 a. Create an ICMP Packet Too Big Message, and set its Next- 686 Hop MTU field to the difference between the Effective 687 Maximum Frame Payload Size and the value of N 689 b. If possible, transmit the ICMP Packet Too Big Message to 690 the source of the datagram. 692 c. discard the labeled IPv6 datagram. 694 4. If the IP datagram is not larger than 1280 octets, then 696 a. Convert it into fragments, each of which MUST be at least 697 N bytes less than the Effective Maximum Frame Payload 698 Size. 700 b. Prepend each fragment with the same label header that 701 would have been on the original datagram had 702 fragmentation not been necessary. 704 c. Forward the fragments. 706 Reassembly of the fragments will be done at the destination 707 host. 709 3.6. Implications with respect to Path MTU Discovery 711 The procedures described above for handling datagrams which have the 712 DF bit set, but which are "too large", have an impact on the Path MTU 713 Discovery procedures of RFC 1191. Hosts which implement these 714 procedures will discover an MTU which is small enough to allow n 715 labels to be pushed on the datagrams, without need for fragmentation, 716 where n is the number of labels that actually get pushed on along the 717 path currently in use. 719 In other words, datagrams from hosts that use Path MTU Discovery will 720 never need to be fragmented due to the need to put on a label header, 721 or to add new labels to an existing label header. (Also, datagrams 722 from hosts that use Path MTU Discovery generally have the DF bit set, 723 and so will never get fragmented anyway.) 725 Note that Path MTU Discovery will only work properly if, at the point 726 where a labeled IP Datagram's fragmentation needs to occur, it is 727 possible to cause an ICMP Destination Unreachable message to be 728 routed to the packet's source address. See section 2.3. 730 If it is not possible to forward an ICMP message from within an MPLS 731 "tunnel" to a packet's source address, then the LSR at the 732 transmitting end of the tunnel MUST be able to determine the MTU of 733 the tunnel as a whole. It SHOULD do this by sending packets through 734 the tunnel to the tunnel's receiving endpoint, and performing Path 735 MTU Discovery with those packets. Then any time the transmitting 736 endpoint of the tunnel needs to send a packet into the tunnel, and 737 that packet has the DF bit set, and it exceeds the tunnel MTU, the 738 transmitting endpoint of the tunnel MUST send the ICMP Destination 739 Unreachable message to the source, with code "Fragmentation Required 740 and DF Set", and the Next-Hop MTU Field set as described above. 742 4. Transporting Labeled Packets over PPP 744 The Point-to-Point Protocol (PPP) [8] provides a standard method for 745 transporting multi-protocol datagrams over point-to-point links. PPP 746 defines an extensible Link Control Protocol, and proposes a family of 747 Network Control Protocols for establishing and configuring different 748 network-layer protocols. 750 This section defines the Network Control Protocol for establishing 751 and configuring label Switching over PPP. 753 4.1. Introduction 755 PPP has three main components: 757 1. A method for encapsulating multi-protocol datagrams. 759 2. A Link Control Protocol (LCP) for establishing, configuring, 760 and testing the data-link connection. 762 3. A family of Network Control Protocols for establishing and 763 configuring different network-layer protocols. 765 In order to establish communications over a point-to-point link, each 766 end of the PPP link must first send LCP packets to configure and test 767 the data link. After the link has been established and optional 768 facilities have been negotiated as needed by the LCP, PPP must send 769 "MPLS Control Protocol" packets to enable the transmission of labeled 770 packets. Once the "MPLS Control Protocol" has reached the Opened 771 state, labeled packets can be sent over the link. 773 The link will remain configured for communications until explicit LCP 774 or MPLS Control Protocol packets close the link down, or until some 775 external event occurs (an inactivity timer expires or network 776 administrator intervention). 778 4.2. A PPP Network Control Protocol for MPLS 780 The MPLS Control Protocol (MPLSCP) is responsible for enabling and 781 disabling the use of label switching on a PPP link. It uses the same 782 packet exchange mechanism as the Link Control Protocol (LCP). MPLSCP 783 packets may not be exchanged until PPP has reached the Network-Layer 784 Protocol phase. MPLSCP packets received before this phase is reached 785 should be silently discarded. 787 The MPLS Control Protocol is exactly the same as the Link Control 788 Protocol [8] with the following exceptions: 790 1. Frame Modifications 792 The packet may utilize any modifications to the basic frame 793 format which have been negotiated during the Link Establishment 794 phase. 796 2. Data Link Layer Protocol Field 798 Exactly one MPLSCP packet is encapsulated in the PPP 799 Information field, where the PPP Protocol field indicates type 800 hex 8281 (MPLS). 802 3. Code field 804 Only Codes 1 through 7 (Configure-Request, Configure-Ack, 805 Configure-Nak, Configure-Reject, Terminate-Request, Terminate- 806 Ack and Code-Reject) are used. Other Codes should be treated 807 as unrecognized and should result in Code-Rejects. 809 4. Timeouts 811 MPLSCP packets may not be exchanged until PPP has reached the 812 Network-Layer Protocol phase. An implementation should be 813 prepared to wait for Authentication and Link Quality 814 Determination to finish before timing out waiting for a 815 Configure-Ack or other response. It is suggested that an 816 implementation give up only after user intervention or a 817 configurable amount of time. 819 5. Configuration Option Types 821 None. 823 4.3. Sending Labeled Packets 825 Before any labeled packets may be communicated, PPP must reach the 826 Network-Layer Protocol phase, and the MPLS Control Protocol must 827 reach the Opened state. 829 Exactly one labeled packet is encapsulated in the PPP Information 830 field, where the PPP Protocol field indicates either type hex 0281 831 (MPLS Unicast) or type hex 0283 (MPLS Multicast). The maximum length 832 of a labeled packet transmitted over a PPP link is the same as the 833 maximum length of the Information field of a PPP encapsulated packet. 835 The format of the Information field itself is as defined in section 836 2. 838 Note that two codepoints are defined for labeled packets; one for 839 multicast and one for unicast. Once the MPLSCP has reached the 840 Opened state, both label Switched multicasts and label Switched 841 unicasts can be sent over the PPP link. 843 4.4. Label Switching Control Protocol Configuration Options 845 There are no configuration options. 847 5. Transporting Labeled Packets over LAN Media 849 Exactly one labeled packet is carried in each frame. 851 The label stack entries immediately precede the network layer header, 852 and follow any data link layer headers, including, e.g., any 802.1Q 853 headers that may exist. 855 The ethertype value 8847 hex is used to indicate that a frame is 856 carrying an MPLS unicast packet. 858 The ethertype value 8848 hex is used to indicate that a frame is 859 carrying an MPLS multicast packet. 861 These ethertype values can be used with either the ethernet 862 encapsulation or the 802.3 SNAP/SAP encapsulation to carry labeled 863 packets. 865 6. Security Considerations 867 Security considerations are not discussed in this document. 869 7. Authors' Addresses 871 Eric C. Rosen 872 Cisco Systems, Inc. 873 250 Apollo Drive 874 Chelmsford, MA, 01824 875 E-mail: erosen@cisco.com 877 Dan Tappan 878 Cisco Systems, Inc. 880 250 Apollo Drive 881 Chelmsford, MA, 01824 882 E-mail: tappan@cisco.com 884 Dino Farinacci 885 Cisco Systems, Inc. 886 170 Tasman Drive 887 San Jose, CA, 95134 888 E-mail: dino@cisco.com 890 Yakov Rekhter 891 Cisco Systems, Inc. 892 170 Tasman Drive 893 San Jose, CA, 95134 894 E-mail: yakov@cisco.com 896 Guy Fedorkow 897 Cisco Systems, Inc. 898 250 Apollo Drive 899 Chelmsford, MA, 01824 900 E-mail: fedorkow@cisco.com 902 Tony Li 903 Juniper Networks 904 385 Ravendale Dr. 905 Mountain View, CA, 94043 906 E-mail: tli@juniper.net 908 Alex Conta 909 Lucent Technologies 910 300 Baker Avenue 911 Concord, MA, 01742 912 E-mail: aconta@lucent.com 914 8. References 916 [1], "Multiprotocol Label Switching Architecture", 7/98, draft-ietf- 917 mpls-arch-02.txt, Rosen, Viswanathan, Callon 919 [2] "A Framework for Multiprotocol Label Switching", 11/97, draft- 920 ietf-mpls-framework-02.txt, Callon, Doolan, Feldman, Fredette, 921 Swallow, Viswanathan 923 [3] "Tag Switching Architecture - Overview", 7/97, draft-rekhter- 924 tagswitch-arch-01.txt, Rekhter, Davie, Katz, Rosen, Swallow 926 [4] "Internet Protocol", RFC 791, 9/81, Postel 928 [5] "Internet Control Message Protocol", RFC 792, 9/81, Postel 930 [6] "Path MTU Discovery", RFC 1191, 11/90, Mogul & Deering 932 [7] "IP Router Alert Option", RFC 2113, 2/97, Katz 934 [8] "The Point-to-Point Protocol (PPP)", RFC 1661, 7/94, Simpson 936 [9] "Internet Control Message Protocol (ICMPv6) for the Internet 937 Protocol Version 6 (IPv6) Specification", RFC 1885, 12/95, Conta, 938 Deering 940 [10] "Path MTU Discovery for IP version 6", [RFC-1981] McCann, J., S. 941 Deering, J. Mogul 943 [11] "Use of Label Switching with ATM", draft-davie-mpls-atm-01.txt, 944 7/98, Davie, Lawrence, McCloghrie, Rekhter, Rosen, Swallow, Doolan