idnits 2.17.1 draft-ietf-mpls-label-encaps-01.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 51: '... described here MUST be used to encod...' RFC 2119 keyword, line 113: '... document MUST be used for the addit...' RFC 2119 keyword, line 120: '... MUST...' RFC 2119 keyword, line 125: '... MUST NOT...' RFC 2119 keyword, line 130: '... SHOULD...' (22 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 (February 1998) is 9567 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 877, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 879, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 881, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 887, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 891, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-mpls-arch-00 == 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) == Outdated reference: A later version (-01) exists of draft-davie-mpls-atm-00 -- Possible downref: Normative reference to a draft: ref. '11' Summary: 12 errors (**), 0 flaws (~~), 9 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: August 1998 Daniel Tappan 4 Dino Farinacci 5 Guy Fedorkow 6 Cisco Systems, Inc. 8 Tony Li 9 Juniper Networks, Inc. 11 Alex Conta 12 Lucent Technologies 14 February 1998 16 MPLS Label Stack Encoding 18 draft-ietf-mpls-label-encaps-01.txt 20 Status of this Memo 22 This document is an Internet-Draft. Internet-Drafts are working 23 documents of the Internet Engineering Task Force (IETF), its areas, 24 and its working groups. Note that other groups may also distribute 25 working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 To learn the current status of any Internet-Draft, please check the 33 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 34 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 35 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 36 ftp.isi.edu (US West Coast). 38 Abstract 40 "Multi-Protocol Label Switching (MPLS)" [1,2,3] requires a set of 41 procedures for augmenting network layer packets with "label stacks", 42 thereby turning them into "labeled packets". Routers which support 43 MPLS are known as "Label Switching Routers", or "LSRs". In order to 44 transmit a labeled packet on a particular data link, an LSR must 45 support an encoding technique which, given a label stack and a 46 network layer packet, produces a labeled packet. This document 47 specifies the encoding to be used by an LSR in order to transmit 48 labeled packets on PPP data links, on LAN data links, and possibly on 49 other data links as well. On some data links, the label at the top 50 of the stack may be encoded in a different manner, but the techniques 51 described here MUST be used to encode the remainder of the label 52 stack. This document also specifies rules and procedures for 53 processing the various fields of the label stack encoding. 55 Table of Contents 57 1 Introduction ........................................... 3 58 1.1 Specification of Requirements .......................... 3 59 2 The Label Stack ........................................ 4 60 2.1 Encoding the Label Stack ............................... 4 61 2.2 Determining the Network Layer Protocol ................. 7 62 2.3 Processing the Time to Live Field ...................... 8 63 2.3.1 Definitions ............................................ 8 64 2.3.2 Protocol-independent rules ............................. 8 65 2.3.3 IP-dependent rules ..................................... 8 66 2.3.4 Translating Between Different Encapsulations ........... 9 67 3 Fragmentation and Path MTU Discovery ................... 9 68 3.1 Terminology ............................................ 10 69 3.2 Maximum Initially Labeled IP Datagram Size ............. 12 70 3.3 When are Labeled IP Datagrams Too Big? ................. 13 71 3.4 Processing Labeled IPv4 Datagrams which are Too Big .... 13 72 3.5 Processing Labeled IPv6 Datagrams which are Too Big .... 14 73 3.6 Implications with respect to Path MTU Discovery ........ 15 74 3.6.1 Tunneling through a Transit Routing Domain ............. 15 75 3.6.2 Tunneling Private Addresses through a Public Backbone .. 16 76 4 Transporting Labeled Packets over PPP .................. 16 77 4.1 Introduction ........................................... 16 78 4.2 A PPP Network Control Protocol for MPLS ................ 17 79 4.3 Sending Labeled Packets ................................ 18 80 4.4 Label Switching Control Protocol Configuration Options . 18 81 5 Transporting Labeled Packets over LAN Media ............ 18 82 6 Security Considerations ................................ 19 83 7 Authors' Addresses ..................................... 19 84 8 References ............................................. 20 86 1. Introduction 88 "Multi-Protocol Label Switching (MPLS)" [1,2,3] requires a set of 89 procedures for augmenting network layer packets with "label stacks", 90 thereby turning them into "labeled packets". Routers which support 91 MPLS are known as "Label Switching Routers", or "LSRs". In order to 92 transmit a labeled packet on a particular data link, an LSR must 93 support an encoding technique which, given a label stack and a 94 network layer packet, produces a labeled packet. 96 This document specifies the encoding to be used by an LSR in order to 97 transmit labeled packets on PPP data links and on LAN data links. 98 The specified encoding may also be useful for other data links as 99 well. 101 This document also specifies rules and procedures for processing the 102 various fields of the label stack encoding. Since MPLS is 103 independent of any particular network layer protocol, the majority of 104 such procedures are also protocol-independent. A few, however, do 105 differ for different protocols. In this document, we specify the 106 protocol-independent procedures, and we specify the protocol- 107 dependent procedures for IPv4 and IPv6. 109 LSRs that are implemented on certain switching devices (such as ATM 110 switches) may use different encoding techniques for encoding the top 111 one or two entries of the label stack. When the label stack has 112 additional entries, however, the encoding technique described in this 113 document MUST be used for the additional label stack entries. 115 1.1. Specification of Requirements 117 In this document, several words are used to signify the requirements 118 of the specification. These words are often capitalized. 120 MUST 122 This word, or the adjective "required", means that the 123 definition is an absolute requirement of the specification. 125 MUST NOT 127 This phrase means that the definition is an absolute prohibition 128 of the specification. 130 SHOULD 132 This word, or the adjective "recommended", means that there may 133 exist valid reasons in particular circumstances to ignore this 134 item, but the full implications must be understood and carefully 135 weighed before choosing a different course. 137 MAY 139 This word, or the adjective "optional", means that this item is 140 one of an allowed set of alternatives. An implementation which 141 does not include this option MUST be prepared to interoperate 142 with another implementation which does include the option. 144 2. The Label Stack 146 2.1. Encoding the Label Stack 148 The label stack is represented as a sequence of "label stack 149 entries". Each label stack entry is represented by 4 octets. This 150 is shown in Figure 1. 152 0 1 2 3 153 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 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label 155 | Label | CoS |S| TTL | Stack 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry 158 Label: Label Value, 20 bits 159 CoS: Class of Service, 3 bits 160 S: Bottom of Stack, 1 bit 161 TTL: Time to Live, 8 bits 163 Figure 1 165 The label stack entries appear AFTER the data link layer headers, but 166 BEFORE any network layer headers. The top of the label stack appears 167 earliest in the packet, and the bottom appears latest. The network 168 layer packet immediately follows the label stack entry which has the 169 S bit set. 171 Each label stack entry is broken down into the following fields: 173 1. Bottom of Stack (S) 175 This bit is set to one for the last entry in the label stack 176 (i.e., for the bottom of the stack), and zero for all other 177 label stack entries. 179 2. Time to Live (TTL) 181 This eight-bit field is used to encode a time-to-live value. 182 The processing of this field is described in section 2.3. 184 3. Class of Service (CoS) 186 This three-bit field is used to identify a "Class of Service". 187 The setting of this field is intended to affect the scheduling 188 and/or discard algorithms which are applied to the packet as it 189 is transmitted through the network. 191 When an unlabeled packet is initially labeled, the value 192 assigned to the CoS field in the label stack entry is 193 determined by policy. Some possible policies are: 195 - the CoS value is a function of the IP ToS value 197 - the CoS value is a function of the packet's input interface 199 - the CoS value is a function of the "flow type" 201 Of course, many other policies are also possible. 203 When an additional label is pushed onto the stack of a packet 204 that is already labeled: 206 - in general, the value of the CoS field in the new top stack 207 entry should be equal to the value of the CoS field of the 208 old top stack entry; 210 - however, in some cases, most likely at boundaries between 211 network service providers, the value of the CoS field in 212 the new top stack entry may be determined by policy. 214 4. Label Value 216 This 20-bit field carries the actual value of the Label. 218 When a labeled packet is received, the label value at the top 219 of the stack is looked up. As a result of a successful lookup 220 one learns: 222 (a) information needed to forward the packet, such as the 223 next hop and the outgoing data link encapsulation; 224 however, the precise queue to put the packet on, or 225 information as to how to schedule the packet, may be a 226 function of both the label value AND the CoS field 227 value; 229 (b) the operation to be performed on the label stack before 230 forwarding; this operation may be to replace the top 231 label stack entry with another, or to pop an entry off 232 the label stack, or to replace the top label stack entry 233 and then to push one or more additional entries on the 234 label stack. 236 There are several reserved label values: 238 i. A value of 0 represents the "IPv4 Explicit NULL Label". 239 This label value is only legal when it is the sole 240 label stack entry. It indicates that the label stack 241 must be popped, and the forwarding of the packet must 242 then be based on the IPv4 header. 244 ii. A value of 1 represents the "Router Alert Label". This 245 label value is legal anywhere in the label stack except 246 at the bottom. When a received packet contains this 247 label value at the top of the label stack, it is 248 delivered to a local software module for processing. 249 The actual forwarding of the packet is determined by 250 the label beneath it in the stack. However, if the 251 packet is forwarded further, the Router Alert Label 252 should be pushed back onto the label stack before 253 forwarding. The use of this label is analogous to the 254 use of the "Router Alert Option" in IP packets [7]. 255 Since this label cannot occur at the bottom of the 256 stack, it is not associated with a particular network 257 layer protocol. 259 iii. A value of 2 represents the "IPv6 Explicit NULL Label". 260 This label value is only legal when it is the sole 261 label stack entry. It indicates that the label stack 262 must be popped, and the forwarding of the packet must 263 then be based on the IPv6 header. 265 iv. A value of 3 represents the "Implicit NULL Label". 266 This is a label that an LSR may assign and distribute, 267 but which never actually appears in the encapsulation. 268 When an LSR would otherwise replace the label at the 269 top of the stack with a new label, but the new label is 270 "Implicit NULL", the LSR will pop the stack instead of 271 doing the replacement. Although this value may never 272 appear in the encapsulation, it needs to be specified 273 in the Label Distribution Protocol, so a value is 274 reserved. 276 v. Values 4-16 are reserved. 278 2.2. Determining the Network Layer Protocol 280 When the last label is popped from a packet's label stack (resulting 281 in the stack being emptied), further processing of the packet is 282 based on the packet's network layer header. The LSR which pops the 283 last label off the stack must therefore be able to identify the 284 packet's network layer protocol. However, the label stack does not 285 contain any field which explicitly identifies the network layer 286 protocol. This means that the identity of the network layer protocol 287 must be inferable from the value of the label which is popped from 288 the bottom of the stack, possibly along with the contents of the 289 network layer header itself. 291 Therefore, when the first label is pushed onto a network layer 292 packet, either the label must be one which is used ONLY for packets 293 of a particular network layer, or the label must be one which is used 294 ONLY for a specified set of network layer protocols, where packets of 295 the specified network layers can be distinguished by inspection of 296 the network layer header. Furthermore, whenever that label is 297 replaced by another label value during a packet's transit, the new 298 value must also be one which meets the same criteria. If these 299 conditions are not met, the LSR which pops the last label off a 300 packet will not be able to identify the packet's network layer 301 protocol. 303 Adherence to these conditions does not necessarily enable 304 intermediate nodes to identify a packet's network layer protocol. 305 Under ordinary conditions, this is not necessary, but there are error 306 conditions under which it is desirable. For instance, if an 307 intermediate LSR determines that a labeled packet is undeliverable, 308 it may be desirable for that LSR to generate error messages which are 309 specific to the packet's network layer. The only means the 310 intermediate LSR has for identifying the network layer is inspection 311 of the top label and the network layer header. So if intermediate 312 nodes are to be able to generate protocol-specific error messages for 313 labeled packets, all labels in the stack must meet the criteria 314 specified above for labels which appear at the bottom of the stack. 316 2.3. Processing the Time to Live Field 318 2.3.1. Definitions 320 The "incoming TTL" of a labeled packet is defined to be the value of 321 the TTL field of the top label stack entry when the packet is 322 received. 324 The "outgoing TTL" of a labeled packet is defined to be the larger 325 of: 327 (a) one less than the incoming TTL, 328 (b) zero. 330 2.3.2. Protocol-independent rules 332 If the outgoing TTL of a labeled packet is 0, then the labeled packet 333 MUST NOT be further forwarded; the packet's lifetime in the network 334 is considered to have expired. 336 Depending on the label value in the label stack entry, the packet MAY 337 be silently discarded, or the packet MAY have its label stack 338 stripped off, and passed as an unlabeled packet to the ordinary 339 processing for network layer packets which have exceeded their 340 maximum lifetime in the network. However, even if the label stack is 341 stripped, the packet MUST NOT be further forwarded. 343 When a labeled packet is forwarded, the TTL field of the label stack 344 entry at the top of the label stack must be set to the outgoing TTL 345 value. 347 Note that the outgoing TTL value is a function solely of the incoming 348 TTL value, and is independent of whether any labels are pushed or 349 popped before forwarding. There is no significance to the value of 350 the TTL field in any label stack entry which is not at the top of the 351 stack. 353 2.3.3. IP-dependent rules 355 We define the "IP TTL" field to be the value of the IPv4 TTL field, 356 or the value of the IPv6 Hop Limit field, whichever is applicable. 358 When an IP packet is first labeled, the TTL field of the label stack 359 entry MUST BE set to the value of the IP TTL field. (If the IP TTL 360 field needs to be decremented, as part of the IP processing, it is 361 assumed that this has already been done.) 362 When a label is popped, and the resulting label stack is empty, then 363 the value of the IP TTL field MUST BE replaced with the outgoing TTL 364 value, as defined above. In IPv4 this also requires modification of 365 the IP header checksum. 367 2.3.4. Translating Between Different Encapsulations 369 Sometimes an LSR may receive a labeled packet over, say, a label 370 switching controlled ATM (LC-ATM) interface [11], and may need to 371 send it out over a PPP or LAN link. Then the incoming packet will 372 not be received using the encapsulation specified in this document, 373 but the outgoing packet will be sent using the encapsulation 374 specified in this document. 376 In this case, the value of the "incoming TTL" is determined by the 377 procedures used for carrying labeled packets on, e.g., LC-ATM 378 interfaces. TTL processing then proceeds as described above. 380 Sometimes an LSR may receive a labeled packet over a PPP or a LAN 381 link, and may need to send it out, say, an LC-ATM interface. Then 382 the incoming packet will be received using the encapsulation 383 specified in this document, but the outgoing packet will not be send 384 using the encapsulation specified in this document. In this case, 385 the procedure for carrying the value of the "outgoing TTL" is 386 determined by the procedures used for carrying labeled packets on, 387 e.g., LC-ATM interfaces. 389 3. Fragmentation and Path MTU Discovery 391 Just as it is possible to receive an unlabeled IP datagram which is 392 too large to be transmitted on its output link, it is possible to 393 receive a labeled packet which is too large to be transmitted on its 394 output link. 396 It is also possible that a received packet (labeled or unlabeled) 397 which was originally small enough to be transmitted on that link 398 becomes too large by virtue of having one or more additional labels 399 pushed onto its label stack. In label switching, a packet may grow 400 in size if additional labels get pushed on. Thus if one receives a 401 labeled packet with a 1500-byte frame payload, and pushes on an 402 additional label, one needs to forward it as frame with a 1504-byte 403 payload. 405 This section specifies the rules for processing labeled packets which 406 are "too large". In particular, it provides rules which ensure that 407 hosts implementing RFC 1191 Path MTU Discovery, and hosts using IPv6, 408 will be able to generate IP datagrams that do not need fragmentation, 409 even if they get labeled as the traverse the network. 411 In general, hosts which do not implement RFC 1191 Path MTU Discovery 412 send IP datagrams which contain no more than 576 bytes. Since the 413 MTUs in use on most data links today are 1500 bytes or more, the 414 probability that such datagrams will need to get fragmented, even if 415 they get labeled, is very small. 417 Some hosts that do not implement RFC 1191 Path MTU Discovery will 418 generate IP datagrams containing 1500 bytes, as long as the IP Source 419 and Destination addresses are on the same subnet. These datagrams 420 will not pass through routers, and hence will not get fragmented. 422 Unfortunately, some hosts will generate IP datagrams containing 1500 423 bytes, as long the IP Source and Destination addresses do not have 424 the same classful network number. This is the one case in which 425 there is any risk of fragmentation when such datagrams get labeled. 426 (Even so, fragmentation is not likely unless the packet must traverse 427 an ethernet of some sort between the time it first gets labeled and 428 the time it gets unlabeled.) 430 This document specifies procedures which allow one to configure the 431 network so that large datagrams from hosts which do not implement 432 Path MTU Discovery get fragmented just once, when they are first 433 labeled. These procedures make it possible (assuming suitable 434 configuration) to avoid any need to fragment packets which have 435 already been labeled. 437 3.1. Terminology 439 With respect to a particular data link, we can use the following 440 terms: 442 - Frame Payload: 444 The contents of a data link frame, excluding any data link layer 445 headers or trailers (e.g., MAC headers, LLC headers, 802.1Q 446 headers, PPP header, frame check sequences, etc.). 448 When a frame is carrying an an unlabeled IP datagram, the Frame 449 Payload is just the IP datagram itself. When a frame is carrying 450 a labeled IP datagram, the Frame Payload consists of the label 451 stack entries and the IP datagram. 453 - Conventional Maximum Frame Payload Size: 455 The maximum Frame Payload size allowed by data link standards. 456 For example, the Conventional Maximum Frame Payload Size for 457 ethernet is 1500 bytes. 459 - True Maximum Frame Payload Size: 461 The maximum size frame payload which can be sent and received 462 properly by the interface hardware attached to the data link. 464 On ethernet and 802.3 networks, it is believed that the True 465 Maximum Frame Payload Size is 4-8 bytes larger than the 466 Conventional Maximum Frame Payload Size (as long neither an 467 802.1Q header nor an 802.1p header is present, and as long as 468 neither can be added by a switch or bridge while a packet is in 469 transit to its next hop). For example, it is believed that most 470 ethernet equipment could correctly send and receive packets 471 carrying a payload of 1504 or perhaps even 1508 bytes, at least, 472 as long as the ethernet header does not have an 802.1Q or 802.1p 473 field. 475 On PPP links, the True Maximum Frame Payload Size may be 476 virtually unbounded. 478 - Effective Maximum Frame Payload Size for Labeled Packets: 480 This is either be the Conventional Maximum Frame Payload Size or 481 the True Maximum Frame Payload Size, depending on the 482 capabilities of the equipment on the data link and the size of 483 the ethernet header being used. 485 - Initially Labeled IP Datagram 487 Suppose that an unlabeled IP datagram is received at a particular 488 LSR, and that the the LSR pushes on a label before forwarding the 489 datagram. Such a datagram will be called an Initially Labeled IP 490 Datagram at that LSR. 492 - Previously Labeled IP Datagram 494 An IP datagram which had already been labeled before it was 495 received by a particular LSR. 497 3.2. Maximum Initially Labeled IP Datagram Size 499 Every LSR which is capable of 501 (a) receiving an unlabeled IP datagram, 502 (b) adding a label stack to the datagram, and 503 (c) forwarding the resulting labeled packet, 505 MUST support a configuration parameter known as the "Maximum IP 506 Datagram Size for Labeling", which can be set to a non-negative 507 value. 509 If this configuration parameter is set to zero, it has no effect. 511 If it is set to a positive value, it is used in the following way. 512 If: 513 (a) an unlabeled IP datagram is received, and 514 (b) that datagram does not have the DF bit set in its IP header, 515 and 516 (c) that datagram needs to be labeled before being forwarded, and 517 (d) the size of the datagram (before labeling) exceeds the value 518 of the parameter, 519 then 520 (a) the datagram must be broken into fragments, each of whose size 521 is no greater than the value of the parameter, and 522 (b) each fragment must be labeled and then forwarded. 524 If this configuration parameter is set to a value of 1488, for 525 example, then any unlabeled IP datagram containing more than 1488 526 bytes will be fragmented before being labeled. Each fragment will be 527 capable of being carried on a 1500-byte data link, without further 528 fragmentation, even if as many as three labels are pushed onto its 529 label stack. 531 In other words, setting this parameter to a non-zero value allows one 532 to eliminate all fragmentation of Previously Labeled IP Datagrams, 533 but it may cause some unnecessary fragmentation of Initially Labeled 534 IP Datagrams. 536 Note that the parameter has no effect on IP Datagrams that have the 537 DF bit set, which means that it has no effect on Path MTU Discovery. 539 3.3. When are Labeled IP Datagrams Too Big? 541 A labeled IP datagram whose size exceeds the Conventional Maximum 542 Frame Payload Size of the data link over which it is to be forwarded 543 MAY be considered to be "too big". 545 A labeled IP datagram whose size exceeds the True Maximum Frame 546 Payload Size of the data link over which it is to be forwarded MUST 547 be considered to be "too big". 549 A labeled IP datagram which is not "too big" MUST be transmitted 550 without fragmentation. 552 3.4. Processing Labeled IPv4 Datagrams which are Too Big 554 If a labeled IPv4 datagram is "too big", and the DF bit is not set in 555 its IP header, then the LSR MAY discard the datagram. 557 Note that discarding such datagrams is a sensible procedure only if 558 the "Maximum Initially Labeled IP Datagram Size" is set to a non-zero 559 value in every LSR in the network which is capable of adding a label 560 stack to an unlabeled IP datagram. 562 If the LSR chooses not to discard a labeled IPv4 datagram which is 563 too big, or if the DF bit is set in that datagram, then it MUST 564 execute the following algorithm: 566 1. Strip off the label stack entries to obtain the IP datagram. 568 2. Let N be the number of bytes in the label stack (i.e, 4 times 569 the number of label stack entries). 571 3. If the IP datagram does NOT have the "Don't Fragment" bit set 572 in its IP header: 574 a. convert it into fragments, each of which MUST be at least 575 N bytes less than the Effective Maximum Frame Payload 576 Size. 578 b. Prepend each fragment with the same label header that 579 would have been on the original datagram had 580 fragmentation not been necessary. 582 c. Forward the fragments 584 4. If the IP datagram has the "Don't Fragment" bit set in its IP 585 header: 587 a. the datagram MUST NOT be forwarded 589 b. Create an ICMP Destination Unreachable Message: 591 i. set its Code field (RFC 792) to "Fragmentation 592 Required and DF Set", 594 ii. set its Next-Hop MTU field (RFC 1191) to the 595 difference between the Effective Maximum Frame 596 Payload Size and the value of N 598 c. If possible, transmit the ICMP Destination Unreachable 599 Message to the source of the of the discarded datagram. 601 3.5. Processing Labeled IPv6 Datagrams which are Too Big 603 To process a labeled IPv6 datagram which is too big, an LSR MUST 604 execute the following algorithm: 606 1. Strip off the label stack entries to obtain the IP datagram. 608 2. Let N be the number of bytes in the label stack (i.e, 4 times 609 the number of label stack entries). 611 3. If the IP datagram contains more than 576 bytes (not counting 612 the label stack entries), then: 614 a. Create an ICMP Packet Too Big Message, and set its Next- 615 Hop MTU field to the difference between the Effective 616 Maximum Frame Payload Size and the value of N 618 b. If possible, transmit the ICMP Packet Too Big Message to 619 the source of the datagram. 621 c. discard the labeled IPv6 datagram. 623 4. If the IP datagram is not larger than 576 octets, then 625 a. Convert it into fragments, each of which MUST be at least 626 N bytes less than the Effective Maximum Frame Payload 627 Size. 629 b. Prepend each fragment with the same label header that 630 would have been on the original datagram had 631 fragmentation not been necessary. 633 c. Forward the fragments. 635 Reassembly of the fragments will be done at the destination 636 host. 638 3.6. Implications with respect to Path MTU Discovery 640 The procedures described above for handling datagrams which have the 641 DF bit set, but which are "too large", have an impact on the Path MTU 642 Discovery procedures of RFC 1191. Hosts which implement these 643 procedures will discover an MTU which is small enough to allow n 644 labels to be pushed on the datagrams, without need for fragmentation, 645 where n is the number of labels that actually get pushed on along the 646 path currently in use. 648 In other words, datagrams from hosts that use Path MTU Discovery will 649 never need to be fragmented due to the need to put on a label header, 650 or to add new labels to an existing label header. (Also, datagrams 651 from hosts that use Path MTU Discovery generally have the DF bit set, 652 and so will never get fragmented anyway.) 654 However, note that Path MTU Discovery will only work properly if, at 655 the point where a labeled IP Datagram's fragmentation needs to occur, 656 it is possible to route to the packet's source address. If this is 657 not possible, then the ICMP Destination Unreachable message cannot be 658 sent to the source. 660 3.6.1. Tunneling through a Transit Routing Domain 662 Suppose one is using MPLS to "tunnel" through a transit routing 663 domain, where the external routes are not leaked into the domain's 664 interior routers. If a packet needs fragmentation at some router 665 within the domain, and the packet's DF bit is set, it is necessary to 666 be able to originate an ICMP message at that router and have it 667 routed correctly to the source of the fragmented packet. If the 668 packet's source address is an external address, this poses a problem. 670 Therefore, in order for Path MTU Discovery to work, any routing 671 domain in which external routes are not leaked into the interior 672 routers MUST have a default route which causes all packets carrying 673 external destination addresses to be sent to a border router. For 674 example, one of the border routers may inject "default" into the IGP. 676 3.6.2. Tunneling Private Addresses through a Public Backbone 678 In other cases where MPLS is used to tunnel through a routing domain, 679 it may not be possible to route to the source address of a fragmented 680 packet at all. This would be the case, for example, if the IP 681 addresses carried in the packet were private addresses, and MPLS were 682 being used to tunnel those packets through a public backbone. 684 In such cases, the LSR at the transmitting end of the tunnel MUST be 685 able to determine the MTU of the tunnel as a whole. It SHOULD do 686 this by sending packets through the tunnel to the tunnel's receiving 687 endpoint, and performing Path MTU Discovery with those packets. Then 688 any time the transmitting endpoint of the tunnel needs to send a 689 packet into the tunnel, and that packet has the DF bit set, and it 690 exceeds the tunnel MTU, the transmitting endpoint of the tunnel MUST 691 send the ICMP Destination Unreachable message to the source, with 692 code "Fragmentation Required and DF Set", and the Next-Hop MTU Field 693 set as described above. 695 4. Transporting Labeled Packets over PPP 697 The Point-to-Point Protocol (PPP) [8] provides a standard method for 698 transporting multi-protocol datagrams over point-to-point links. PPP 699 defines an extensible Link Control Protocol, and proposes a family of 700 Network Control Protocols for establishing and configuring different 701 network-layer protocols. 703 This section defines the Network Control Protocol for establishing 704 and configuring label Switching over PPP. 706 4.1. Introduction 708 PPP has three main components: 710 1. A method for encapsulating multi-protocol datagrams. 712 2. A Link Control Protocol (LCP) for establishing, configuring, 713 and testing the data-link connection. 715 3. A family of Network Control Protocols for establishing and 716 configuring different network-layer protocols. 718 In order to establish communications over a point-to-point link, each 719 end of the PPP link must first send LCP packets to configure and test 720 the data link. After the link has been established and optional 721 facilities have been negotiated as needed by the LCP, PPP must send 722 "MPLS Control Protocol" packets to enable the transmission of labeled 723 packets. Once the "MPLS Control Protocol" has reached the Opened 724 state, labeled packets can be sent over the link. 726 The link will remain configured for communications until explicit LCP 727 or MPLS Control Protocol packets close the link down, or until some 728 external event occurs (an inactivity timer expires or network 729 administrator intervention). 731 4.2. A PPP Network Control Protocol for MPLS 733 The MPLS Control Protocol (MPLSCP) is responsible for enabling and 734 disabling the use of label switching on a PPP link. It uses the same 735 packet exchange mechanism as the Link Control Protocol (LCP). MPLSCP 736 packets may not be exchanged until PPP has reached the Network-Layer 737 Protocol phase. MPLSCP packets received before this phase is reached 738 should be silently discarded. 740 The MPLS Control Protocol is exactly the same as the Link Control 741 Protocol [8] with the following exceptions: 743 1. Frame Modifications 745 The packet may utilize any modifications to the basic frame 746 format which have been negotiated during the Link Establishment 747 phase. 749 2. Data Link Layer Protocol Field 751 Exactly one MPLSCP packet is encapsulated in the PPP 752 Information field, where the PPP Protocol field indicates type 753 hex 8281 (MPLS). 755 3. Code field 757 Only Codes 1 through 7 (Configure-Request, Configure-Ack, 758 Configure-Nak, Configure-Reject, Terminate-Request, Terminate- 759 Ack and Code-Reject) are used. Other Codes should be treated 760 as unrecognized and should result in Code-Rejects. 762 4. Timeouts 764 MPLSCP packets may not be exchanged until PPP has reached the 765 Network-Layer Protocol phase. An implementation should be 766 prepared to wait for Authentication and Link Quality 767 Determination to finish before timing out waiting for a 768 Configure-Ack or other response. It is suggested that an 769 implementation give up only after user intervention or a 770 configurable amount of time. 772 5. Configuration Option Types 774 None. 776 4.3. Sending Labeled Packets 778 Before any labeled packets may be communicated, PPP must reach the 779 Network-Layer Protocol phase, and the MPLS Control Protocol must 780 reach the Opened state. 782 Exactly one labeled packet is encapsulated in the PPP Information 783 field, where the PPP Protocol field indicates either type hex 8281 784 (MPLS Unicast) or type hex 8283 (MPLS Multicast). The maximum length 785 of a labeled packet transmitted over a PPP link is the same as the 786 maximum length of the Information field of a PPP encapsulated packet. 788 The format of the Information field itself is as defined in section 789 2. 791 Note that two codepoints are defined for labeled packets; one for 792 multicast and one for unicast. Once the MPLSCP has reached the 793 Opened state, both label Switched multicasts and label Switched 794 unicasts can be sent over the PPP link. 796 4.4. Label Switching Control Protocol Configuration Options 798 There are no configuration options. 800 5. Transporting Labeled Packets over LAN Media 802 Exactly one labeled packet is carried in each frame. 804 The label stack entries immediately precede the network layer header, 805 and follow any data link layer headers, including, e.g., any 802.1Q 806 headers that may exist. 808 The ethertype value 8847 hex is used to indicate that a frame is 809 carrying an MPLS unicast packet. 811 The ethertype value 8848 hex is used to indicate that a frame is 812 carrying an MPLS multicast packet. 814 These ethertype values can be used with either the ethernet 815 encapsulation or the 802.3 SNAP/SAP encapsulation to carry labeled 816 packets. 818 6. Security Considerations 820 Security considerations are not discussed in this document. 822 7. Authors' Addresses 824 Eric C. Rosen 825 Cisco Systems, Inc. 826 250 Apollo Drive 827 Chelmsford, MA, 01824 828 E-mail: erosen@cisco.com 830 Dan Tappan 831 Cisco Systems, Inc. 832 250 Apollo Drive 833 Chelmsford, MA, 01824 834 E-mail: tappan@cisco.com 836 Dino Farinacci 837 Cisco Systems, Inc. 838 170 Tasman Drive 839 San Jose, CA, 95134 840 E-mail: dino@cisco.com 842 Yakov Rekhter 843 Cisco Systems, Inc. 844 170 Tasman Drive 845 San Jose, CA, 95134 846 E-mail: yakov@cisco.com 848 Guy Fedorkow 849 Cisco Systems, Inc. 850 250 Apollo Drive 851 Chelmsford, MA, 01824 852 E-mail: fedorkow@cisco.com 854 Tony Li 855 Juniper Networks 856 385 Ravendale Dr. 857 Mountain View, CA, 94043 858 E-mail: tli@juniper.net 859 Alex Conta 860 Lucent Technologies 861 300 Baker Avenue 862 Concord, MA, 01742 863 E-mail: aconta@lucent.com 865 8. References 867 [1], "A Proposed Architecture for MPLS", 7/97, draft-ietf-mpls-arch- 868 00.txt, Rosen, Viswanathan, Callon 870 [2] "A Framework for Multiprotocol Label Switching", 11/97, draft- 871 ietf-mpls-framework-02.txt, Callon, Doolan, Feldman, Fredette, 872 Swallow, Viswanathan 874 [3] "Tag Switching Architecture - Overview", 7/97, draft-rekhter- 875 tagswitch-arch-01.txt, Rekhter, Davie, Katz, Rosen, Swallow 877 [4] "Internet Protocol", RFC 791, 9/81, Postel 879 [5] "Internet Control Message Protocol", RFC 792, 9/81, Postel 881 [6] "Path MTU Discovery", RFC 1191, 11/90, Mogul & Deering 883 [7] "IP Router Alert Option", RFC 2113, 2/97, Katz 885 [8] "The Point-to-Point Protocol (PPP)", RFC 1661, 7/94, Simpson 887 [9] "Internet Control Message Protocol (ICMPv6) for the Internet 888 Protocol Version 6 (IPv6) Specification", RFC 1885, 12/95, Conta, 889 Deering 891 [10] "Path MTU Discovery for IP version 6", [RFC-1981] McCann, J., S. 892 Deering, J. Mogul 894 [11] "Use of Label Switching with ATM", draft-davie-mpls-atm-00.txt, 895 Davie, Lawrence, McCloghrie, Rekhter, Rosen, Swallow, Doolan