idnits 2.17.1 draft-ietf-mpls-label-encaps-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 22 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 359 has weird spacing: '...sage is never...' -- 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 (April 1999) is 9135 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 1885 (ref. '8') (Obsoleted by RFC 2463) ** Obsolete normative reference: RFC 1981 (ref. '9') (Obsoleted by RFC 8201) -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 7 errors (**), 0 flaws (~~), 3 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: October 1999 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 April 1999 16 MPLS Label Stack Encoding 18 draft-ietf-mpls-label-encaps-04.txt 20 Status of this Memo 22 This document is an Internet-Draft and is in full conformance with 23 all provisions of Section 10 of RFC2026. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Abstract 43 'Multi-Protocol Label Switching (MPLS)' [1,2] requires a set of 44 procedures for augmenting network layer packets with 'label stacks', 45 thereby turning them into 'labeled packets'. Routers which support 46 MPLS are known as 'Label Switching Routers', or 'LSRs'. In order to 47 transmit a labeled packet on a particular data link, an LSR must 48 support an encoding technique which, given a label stack and a 49 network layer packet, produces a labeled packet. This document 50 specifies the encoding to be used by an LSR in order to transmit 51 labeled packets on PPP data links, on LAN data links, and possibly on 52 other data links as well. On some data links, the label at the top 53 of the stack may be encoded in a different manner, but the techniques 54 described here MUST be used to encode the remainder of the label 55 stack. This document also specifies rules and procedures for 56 processing the various fields of the label stack encoding. 58 Table of Contents 60 1 Introduction ........................................... 3 61 1.1 Specification of Requirements .......................... 3 62 2 The Label Stack ........................................ 3 63 2.1 Encoding the Label Stack ............................... 3 64 2.2 Determining the Network Layer Protocol ................. 6 65 2.3 Generating ICMP Messages for Labeled IP Packets ........ 7 66 2.3.1 Tunneling through a Transit Routing Domain ............. 7 67 2.3.2 Tunneling Private Addresses through a Public Backbone .. 8 68 2.4 Processing the Time to Live Field ...................... 9 69 2.4.1 Definitions ............................................ 9 70 2.4.2 Protocol-independent rules ............................. 9 71 2.4.3 IP-dependent rules ..................................... 10 72 2.4.4 Translating Between Different Encapsulations ........... 10 73 3 Fragmentation and Path MTU Discovery ................... 11 74 3.1 Terminology ............................................ 12 75 3.2 Maximum Initially Labeled IP Datagram Size ............. 13 76 3.3 When are Labeled IP Datagrams Too Big? ................. 14 77 3.4 Processing Labeled IPv4 Datagrams which are Too Big .... 14 78 3.5 Processing Labeled IPv6 Datagrams which are Too Big .... 15 79 3.6 Implications with respect to Path MTU Discovery ........ 16 80 4 Transporting Labeled Packets over PPP .................. 17 81 4.1 Introduction ........................................... 17 82 4.2 A PPP Network Control Protocol for MPLS ................ 18 83 4.3 Sending Labeled Packets ................................ 19 84 4.4 Label Switching Control Protocol Configuration Options . 19 85 5 Transporting Labeled Packets over LAN Media ............ 19 86 6 IANA Considerations .................................... 20 87 7 Security Considerations ................................ 20 88 8 Authors' Addresses ..................................... 20 89 9 References ............................................. 21 91 1. Introduction 93 "Multi-Protocol Label Switching (MPLS)" [1,2] requires a set of 94 procedures for augmenting network layer packets with "label stacks", 95 thereby turning them into "labeled packets". Routers which support 96 MPLS are known as "Label Switching Routers", or "LSRs". In order to 97 transmit a labeled packet on a particular data link, an LSR must 98 support an encoding technique which, given a label stack and a 99 network layer packet, produces a labeled packet. 101 This document specifies the encoding to be used by an LSR in order to 102 transmit labeled packets on PPP data links and on LAN data links. 103 The specified encoding may also be useful for other data links as 104 well. 106 This document also specifies rules and procedures for processing the 107 various fields of the label stack encoding. Since MPLS is 108 independent of any particular network layer protocol, the majority of 109 such procedures are also protocol-independent. A few, however, do 110 differ for different protocols. In this document, we specify the 111 protocol-independent procedures, and we specify the protocol- 112 dependent procedures for IPv4 and IPv6. 114 LSRs that are implemented on certain switching devices (such as ATM 115 switches) may use different encoding techniques for encoding the top 116 one or two entries of the label stack. When the label stack has 117 additional entries, however, the encoding technique described in this 118 document MUST be used for the additional label stack entries. 120 1.1. Specification of Requirements 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [3]. 126 2. The Label Stack 128 2.1. Encoding the Label Stack 130 The label stack is represented as a sequence of "label stack 131 entries". Each label stack entry is represented by 4 octets. This 132 is shown in Figure 1. 134 0 1 2 3 135 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 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label 137 | Label | Exp |S| TTL | Stack 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry 140 Label: Label Value, 20 bits 141 Exp: Experimental Use, 3 bits 142 S: Bottom of Stack, 1 bit 143 TTL: Time to Live, 8 bits 145 Figure 1 147 The label stack entries appear AFTER the data link layer headers, but 148 BEFORE any network layer headers. The top of the label stack appears 149 earliest in the packet, and the bottom appears latest. The network 150 layer packet immediately follows the label stack entry which has the 151 S bit set. 153 Each label stack entry is broken down into the following fields: 155 1. Bottom of Stack (S) 157 This bit is set to one for the last entry in the label stack 158 (i.e., for the bottom of the stack), and zero for all other 159 label stack entries. 161 2. Time to Live (TTL) 163 This eight-bit field is used to encode a time-to-live value. 164 The processing of this field is described in section 2.4. 166 3. Experimental Use 168 This three-bit field is reserved for experimental use. 170 4. Label Value 172 This 20-bit field carries the actual value of the Label. 174 When a labeled packet is received, the label value at the top 175 of the stack is looked up. As a result of a successful lookup 176 one learns: 178 (a) the next hop to which the packet is to be forwarded; 180 (b) the operation to be performed on the label stack before 181 forwarding; this operation may be to replace the top 182 label stack entry with another, or to pop an entry off 183 the label stack, or to replace the top label stack entry 184 and then to push one or more additional entries on the 185 label stack. 187 In addition to learning the next hop and the label stack 188 operation, one may also learn the outgoing data link 189 encapsulation, and possibly other information which is needed 190 in order to properly forward the packet. 192 There are several reserved label values: 194 i. A value of 0 represents the "IPv4 Explicit NULL Label". 195 This label value is only legal when it is the sole 196 label stack entry. It indicates that the label stack 197 must be popped, and the forwarding of the packet must 198 then be based on the IPv4 header. 200 ii. A value of 1 represents the "Router Alert Label". This 201 label value is legal anywhere in the label stack except 202 at the bottom. When a received packet contains this 203 label value at the top of the label stack, it is 204 delivered to a local software module for processing. 205 The actual forwarding of the packet is determined by 206 the label beneath it in the stack. However, if the 207 packet is forwarded further, the Router Alert Label 208 should be pushed back onto the label stack before 209 forwarding. The use of this label is analogous to the 210 use of the "Router Alert Option" in IP packets [6]. 211 Since this label cannot occur at the bottom of the 212 stack, it is not associated with a particular network 213 layer protocol. 215 iii. A value of 2 represents the "IPv6 Explicit NULL Label". 216 This label value is only legal when it is the sole 217 label stack entry. It indicates that the label stack 218 must be popped, and the forwarding of the packet must 219 then be based on the IPv6 header. 221 iv. A value of 3 represents the "Implicit NULL Label". 222 This is a label that an LSR may assign and distribute, 223 but which never actually appears in the encapsulation. 224 When an LSR would otherwise replace the label at the 225 top of the stack with a new label, but the new label is 226 "Implicit NULL", the LSR will pop the stack instead of 227 doing the replacement. Although this value may never 228 appear in the encapsulation, it needs to be specified 229 in the Label Distribution Protocol, so a value is 230 reserved. 232 v. Values 4-15 are reserved. 234 2.2. Determining the Network Layer Protocol 236 When the last label is popped from a packet's label stack (resulting 237 in the stack being emptied), further processing of the packet is 238 based on the packet's network layer header. The LSR which pops the 239 last label off the stack must therefore be able to identify the 240 packet's network layer protocol. However, the label stack does not 241 contain any field which explicitly identifies the network layer 242 protocol. This means that the identity of the network layer protocol 243 must be inferable from the value of the label which is popped from 244 the bottom of the stack, possibly along with the contents of the 245 network layer header itself. 247 Therefore, when the first label is pushed onto a network layer 248 packet, either the label must be one which is used ONLY for packets 249 of a particular network layer, or the label must be one which is used 250 ONLY for a specified set of network layer protocols, where packets of 251 the specified network layers can be distinguished by inspection of 252 the network layer header. Furthermore, whenever that label is 253 replaced by another label value during a packet's transit, the new 254 value must also be one which meets the same criteria. If these 255 conditions are not met, the LSR which pops the last label off a 256 packet will not be able to identify the packet's network layer 257 protocol. 259 Adherence to these conditions does not necessarily enable 260 intermediate nodes to identify a packet's network layer protocol. 261 Under ordinary conditions, this is not necessary, but there are error 262 conditions under which it is desirable. For instance, if an 263 intermediate LSR determines that a labeled packet is undeliverable, 264 it may be desirable for that LSR to generate error messages which are 265 specific to the packet's network layer. The only means the 266 intermediate LSR has for identifying the network layer is inspection 267 of the top label and the network layer header. So if intermediate 268 nodes are to be able to generate protocol-specific error messages for 269 labeled packets, all labels in the stack must meet the criteria 270 specified above for labels which appear at the bottom of the stack. 272 If a packet cannot be forwarded for some reason (e.g., it exceeds the 273 data link MTU), and either its network layer protocol cannot be 274 identified, or there are no specified protocol-dependent rules for 275 handling the error condition, then the packet MUST be silently 276 discarded. 278 2.3. Generating ICMP Messages for Labeled IP Packets 280 Section 2.4 and section 3 discuss situations in which it is desirable 281 to generate ICMP messages for labeled IP packets. In order for a 282 particular LSR to be able to generate an ICMP packet and have that 283 packet sent to the source of the IP packet, two conditions must hold: 285 1. it must be possible for that LSR to determine that a particular 286 labeled packet is an IP packet; 288 2. it must be possible for that LSR to route to the packet's IP 289 source address. 291 Condition 1 is discussed in section 2.2. The following two 292 subsections discuss condition 2. However, there will be some cases 293 in which condition 2 does not hold at all, and in these cases it will 294 not be possible to generate the ICMP message. 296 2.3.1. Tunneling through a Transit Routing Domain 298 Suppose one is using MPLS to "tunnel" through a transit routing 299 domain, where the external routes are not leaked into the domain's 300 interior routers. For example, the interior routers may be running 301 OSPF, and may only know how to reach destinations within that OSPF 302 domain. The domain might contain several Autonomous System Border 303 Routers (ASBRs), which talk BGP to each other. However, in this 304 example the routes from BGP are not distributed into OSPF, and the 305 LSRs which are not ASBRs do not run BGP. 307 In this example, only an ASBR will know how to route to the source of 308 some arbitrary packet. If an interior router needs to send an ICMP 309 message to the source of an IP packet, it will not know how to route 310 the ICMP message. 312 One solution is to have one or more of the ASBRs inject "default" 313 into the IGP. (N.B.: this does NOT require that there be a "default" 314 carried by BGP.) This would then ensure that any unlabeled packet 315 which must leave the domain (such as an ICMP packet) gets sent to a 316 router which has full routing information. The routers with full 317 routing information will label the packets before sending them back 318 through the transit domain, so the use of default routing within the 319 transit domain does not cause any loops. 321 This solution only works for packets which have globally unique 322 addresses, and for networks in which all the ASBRs have complete 323 routing information. The next subsection describes a solution which 324 works when these conditions do not hold. 326 2.3.2. Tunneling Private Addresses through a Public Backbone 328 In some cases where MPLS is used to tunnel through a routing domain, 329 it may not be possible to route to the source address of a fragmented 330 packet at all. This would be the case, for example, if the IP 331 addresses carried in the packet were private (i.e., not globally 332 unique) addresses, and MPLS were being used to tunnel those packets 333 through a public backbone. Default routing to an ASBR will not work 334 in this environment. 336 In this environment, in order to send an ICMP message to the source 337 of a packet, one can copy the label stack from the original packet to 338 the ICMP message, and then label switch the ICMP message. This will 339 cause the message to proceed in the direction of the original 340 packet's destination, rather than its source. Unless the message is 341 label switched all the way to the destination host, it will end up, 342 unlabeled, in a router which does know how to route to the source of 343 original packet, at which point the message will be sent in the 344 proper direction. 346 This technique can be very useful if the ICMP message is a "Time 347 Exceeded" message or a "Destination Unreachable because fragmentation 348 needed and DF set" message. 350 When copying the label stack from the original packet to the ICMP 351 message, the label values must be copied exactly, but the TTL values 352 in the label stack should be set to the TTL value that is placed in 353 the IP header of the ICMP message. This TTL value should be long 354 enough to allow the circuitous route that the ICMP message will need 355 to follow. 357 Note that if a packet's TTL expiration is due to the presence of a 358 routing loop, then if this technique is used, the ICMP message may 359 loop as well. Since an ICMP message is never sent as a result of 360 receiving an ICMP message, and since many implementations throttle 361 the rate at which ICMP messages can be generated, this is not 362 expected to pose a problem. 364 2.4. Processing the Time to Live Field 366 2.4.1. Definitions 368 The "incoming TTL" of a labeled packet is defined to be the value of 369 the TTL field of the top label stack entry when the packet is 370 received. 372 The "outgoing TTL" of a labeled packet is defined to be the larger 373 of: 375 (a) one less than the incoming TTL, 376 (b) zero. 378 2.4.2. Protocol-independent rules 380 If the outgoing TTL of a labeled packet is 0, then the labeled packet 381 MUST NOT be further forwarded; nor may the label stack be stripped 382 off and the packet forwarded as an unlabeled packet. The packet's 383 lifetime in the network is considered to have expired. 385 Depending on the label value in the label stack entry, the packet MAY 386 be simply discarded, or it may be passed to the appropriate 387 "ordinary" network layer for error processing (e.g., for the 388 generation of an ICMP error message, see section 2.3). 390 When a labeled packet is forwarded, the TTL field of the label stack 391 entry at the top of the label stack MUST be set to the outgoing TTL 392 value. 394 Note that the outgoing TTL value is a function solely of the incoming 395 TTL value, and is independent of whether any labels are pushed or 396 popped before forwarding. There is no significance to the value of 397 the TTL field in any label stack entry which is not at the top of the 398 stack. 400 2.4.3. IP-dependent rules 402 We define the "IP TTL" field to be the value of the IPv4 TTL field, 403 or the value of the IPv6 Hop Limit field, whichever is applicable. 405 When an IP packet is first labeled, the TTL field of the label stack 406 entry MUST BE set to the value of the IP TTL field. (If the IP TTL 407 field needs to be decremented, as part of the IP processing, it is 408 assumed that this has already been done.) 410 When a label is popped, and the resulting label stack is empty, then 411 the value of the IP TTL field SHOULD BE replaced with the outgoing 412 TTL value, as defined above. In IPv4 this also requires modification 413 of the IP header checksum. 415 It is recognized that there may be situations where a network 416 administration prefers to decrement the IPv4 TTL by one as it 417 traverses an MPLS domain, instead of decrementing the IPv4 TTL by the 418 number of LSP hops within the domain. 420 2.4.4. Translating Between Different Encapsulations 422 Sometimes an LSR may receive a labeled packet over, e.g., a label 423 switching controlled ATM (LC-ATM) interface [10], and may need to 424 send it out over a PPP or LAN link. Then the incoming packet will 425 not be received using the encapsulation specified in this document, 426 but the outgoing packet will be sent using the encapsulation 427 specified in this document. 429 In this case, the value of the "incoming TTL" is determined by the 430 procedures used for carrying labeled packets on, e.g., LC-ATM 431 interfaces. TTL processing then proceeds as described above. 433 Sometimes an LSR may receive a labeled packet over a PPP or a LAN 434 link, and may need to send it out, say, an LC-ATM interface. Then 435 the incoming packet will be received using the encapsulation 436 specified in this document, but the outgoing packet will not be sent 437 using the encapsulation specified in this document. In this case, 438 the procedure for carrying the value of the "outgoing TTL" is 439 determined by the procedures used for carrying labeled packets on, 440 e.g., LC-ATM interfaces. 442 3. Fragmentation and Path MTU Discovery 444 Just as it is possible to receive an unlabeled IP datagram which is 445 too large to be transmitted on its output link, it is possible to 446 receive a labeled packet which is too large to be transmitted on its 447 output link. 449 It is also possible that a received packet (labeled or unlabeled) 450 which was originally small enough to be transmitted on that link 451 becomes too large by virtue of having one or more additional labels 452 pushed onto its label stack. In label switching, a packet may grow 453 in size if additional labels get pushed on. Thus if one receives a 454 labeled packet with a 1500-byte frame payload, and pushes on an 455 additional label, one needs to forward it as frame with a 1504-byte 456 payload. 458 This section specifies the rules for processing labeled packets which 459 are "too large". In particular, it provides rules which ensure that 460 hosts implementing Path MTU Discovery [5], and hosts using IPv6 461 [8,9], will be able to generate IP datagrams that do not need 462 fragmentation, even if those datagrams get labeled as they traverse 463 the network. 465 In general, IPv4 hosts which do not implement Path MTU Discovery [5] 466 send IP datagrams which contain no more than 576 bytes. Since the 467 MTUs in use on most data links today are 1500 bytes or more, the 468 probability that such datagrams will need to get fragmented, even if 469 they get labeled, is very small. 471 Some hosts that do not implement Path MTU Discovery [5] will generate 472 IP datagrams containing 1500 bytes, as long as the IP Source and 473 Destination addresses are on the same subnet. These datagrams will 474 not pass through routers, and hence will not get fragmented. 476 Unfortunately, some hosts will generate IP datagrams containing 1500 477 bytes, as long the IP Source and Destination addresses have the same 478 classful network number. This is the one case in which there is any 479 risk of fragmentation when such datagrams get labeled. (Even so, 480 fragmentation is not likely unless the packet must traverse an 481 ethernet of some sort between the time it first gets labeled and the 482 time it gets unlabeled.) 484 This document specifies procedures which allow one to configure the 485 network so that large datagrams from hosts which do not implement 486 Path MTU Discovery get fragmented just once, when they are first 487 labeled. These procedures make it possible (assuming suitable 488 configuration) to avoid any need to fragment packets which have 489 already been labeled. 491 3.1. Terminology 493 With respect to a particular data link, we can use the following 494 terms: 496 - Frame Payload: 498 The contents of a data link frame, excluding any data link layer 499 headers or trailers (e.g., MAC headers, LLC headers, 802.1Q 500 headers, PPP header, frame check sequences, etc.). 502 When a frame is carrying an unlabeled IP datagram, the Frame 503 Payload is just the IP datagram itself. When a frame is carrying 504 a labeled IP datagram, the Frame Payload consists of the label 505 stack entries and the IP datagram. 507 - Conventional Maximum Frame Payload Size: 509 The maximum Frame Payload size allowed by data link standards. 510 For example, the Conventional Maximum Frame Payload Size for 511 ethernet is 1500 bytes. 513 - True Maximum Frame Payload Size: 515 The maximum size frame payload which can be sent and received 516 properly by the interface hardware attached to the data link. 518 On ethernet and 802.3 networks, it is believed that the True 519 Maximum Frame Payload Size is 4-8 bytes larger than the 520 Conventional Maximum Frame Payload Size (as long as neither an 521 802.1Q header nor an 802.1p header is present, and as long as 522 neither can be added by a switch or bridge while a packet is in 523 transit to its next hop). For example, it is believed that most 524 ethernet equipment could correctly send and receive packets 525 carrying a payload of 1504 or perhaps even 1508 bytes, at least, 526 as long as the ethernet header does not have an 802.1Q or 802.1p 527 field. 529 On PPP links, the True Maximum Frame Payload Size may be 530 virtually unbounded. 532 - Effective Maximum Frame Payload Size for Labeled Packets: 534 This is either the Conventional Maximum Frame Payload Size or the 535 True Maximum Frame Payload Size, depending on the capabilities of 536 the equipment on the data link and the size of the data link 537 header being used. 539 - Initially Labeled IP Datagram: 541 Suppose that an unlabeled IP datagram is received at a particular 542 LSR, and that the the LSR pushes on a label before forwarding the 543 datagram. Such a datagram will be called an Initially Labeled IP 544 Datagram at that LSR. 546 - Previously Labeled IP Datagram: 548 An IP datagram which had already been labeled before it was 549 received by a particular LSR. 551 3.2. Maximum Initially Labeled IP Datagram Size 553 Every LSR which is capable of 555 (a) receiving an unlabeled IP datagram, 556 (b) adding a label stack to the datagram, and 557 (c) forwarding the resulting labeled packet, 559 SHOULD support a configuration parameter known as the "Maximum 560 Initially Labeled IP Datagram Size", which can be set to a non- 561 negative value. 563 If this configuration parameter is set to zero, it has no effect. 565 If it is set to a positive value, it is used in the following way. 566 If: 567 (a) an unlabeled IP datagram is received, and 568 (b) that datagram does not have the DF bit set in its IP header, 569 and 570 (c) that datagram needs to be labeled before being forwarded, and 571 (d) the size of the datagram (before labeling) exceeds the value 572 of the parameter, 573 then 574 (a) the datagram must be broken into fragments, each of whose size 575 is no greater than the value of the parameter, and 576 (b) each fragment must be labeled and then forwarded. 578 For example, if this configuration parameter is set to a value of 579 1488, then any unlabeled IP datagram containing more than 1488 bytes 580 will be fragmented before being labeled. Each fragment will be 581 capable of being carried on a 1500-byte data link, without further 582 fragmentation, even if as many as three labels are pushed onto its 583 label stack. 585 In other words, setting this parameter to a non-zero value allows one 586 to eliminate all fragmentation of Previously Labeled IP Datagrams, 587 but it may cause some unnecessary fragmentation of Initially Labeled 588 IP Datagrams. 590 Note that the setting of this parameter does not affect the 591 processing of IP datagrams that have the DF bit set; hence the result 592 of Path MTU discovery is unaffected by the setting of this parameter. 594 3.3. When are Labeled IP Datagrams Too Big? 596 A labeled IP datagram whose size exceeds the Conventional Maximum 597 Frame Payload Size of the data link over which it is to be forwarded 598 MAY be considered to be "too big". 600 A labeled IP datagram whose size exceeds the True Maximum Frame 601 Payload Size of the data link over which it is to be forwarded MUST 602 be considered to be "too big". 604 A labeled IP datagram which is not "too big" MUST be transmitted 605 without fragmentation. 607 3.4. Processing Labeled IPv4 Datagrams which are Too Big 609 If a labeled IPv4 datagram is "too big", and the DF bit is not set in 610 its IP header, then the LSR MAY silently discard the datagram. 612 Note that discarding such datagrams is a sensible procedure only if 613 the "Maximum Initially Labeled IP Datagram Size" is set to a non-zero 614 value in every LSR in the network which is capable of adding a label 615 stack to an unlabeled IP datagram. 617 If the LSR chooses not to discard a labeled IPv4 datagram which is 618 too big, or if the DF bit is set in that datagram, then it MUST 619 execute the following algorithm: 621 1. Strip off the label stack entries to obtain the IP datagram. 623 2. Let N be the number of bytes in the label stack (i.e, 4 times 624 the number of label stack entries). 626 3. If the IP datagram does NOT have the "Don't Fragment" bit set 627 in its IP header: 629 a. convert it into fragments, each of which MUST be at least 630 N bytes less than the Effective Maximum Frame Payload 631 Size. 633 b. Prepend each fragment with the same label header that 634 would have been on the original datagram had 635 fragmentation not been necessary. 637 c. Forward the fragments 639 4. If the IP datagram has the "Don't Fragment" bit set in its IP 640 header: 642 a. the datagram MUST NOT be forwarded 644 b. Create an ICMP Destination Unreachable Message: 646 i. set its Code field [4] to "Fragmentation Required 647 and DF Set", 649 ii. set its Next-Hop MTU field [5] to the difference 650 between the Effective Maximum Frame Payload Size 651 and the value of N 653 c. If possible, transmit the ICMP Destination Unreachable 654 Message to the source of the of the discarded datagram. 656 3.5. Processing Labeled IPv6 Datagrams which are Too Big 658 To process a labeled IPv6 datagram which is too big, an LSR MUST 659 execute the following algorithm: 661 1. Strip off the label stack entries to obtain the IP datagram. 663 2. Let N be the number of bytes in the label stack (i.e, 4 times 664 the number of label stack entries). 666 3. If the IP datagram contains more than 1280 bytes (not counting 667 the label stack entries), then: 669 a. Create an ICMP Packet Too Big Message, and set its Next- 670 Hop MTU field to the difference between the Effective 671 Maximum Frame Payload Size and the value of N 673 b. If possible, transmit the ICMP Packet Too Big Message to 674 the source of the datagram. 676 c. discard the labeled IPv6 datagram. 678 4. If the IP datagram is not larger than 1280 octets, then 680 a. Convert it into fragments, each of which MUST be at least 681 N bytes less than the Effective Maximum Frame Payload 682 Size. 684 b. Prepend each fragment with the same label header that 685 would have been on the original datagram had 686 fragmentation not been necessary. 688 c. Forward the fragments. 690 Reassembly of the fragments will be done at the destination 691 host. 693 3.6. Implications with respect to Path MTU Discovery 695 The procedures described above for handling datagrams which have the 696 DF bit set, but which are "too large", have an impact on the Path MTU 697 Discovery procedures of RFC 1191 [5]. Hosts which implement these 698 procedures will discover an MTU which is small enough to allow n 699 labels to be pushed on the datagrams, without need for fragmentation, 700 where n is the number of labels that actually get pushed on along the 701 path currently in use. 703 In other words, datagrams from hosts that use Path MTU Discovery will 704 never need to be fragmented due to the need to put on a label header, 705 or to add new labels to an existing label header. (Also, datagrams 706 from hosts that use Path MTU Discovery generally have the DF bit set, 707 and so will never get fragmented anyway.) 709 Note that Path MTU Discovery will only work properly if, at the point 710 where a labeled IP Datagram's fragmentation needs to occur, it is 711 possible to cause an ICMP Destination Unreachable message to be 712 routed to the packet's source address. See section 2.3. 714 If it is not possible to forward an ICMP message from within an MPLS 715 "tunnel" to a packet's source address, but the network configuration 716 makes it possible for the LSR at the transmitting end of the tunnel 717 to receive packets that must go through the tunnel, but are too large 718 to pass through the tunnel unfragmented, then: 720 - The LSR at the transmitting end of the tunnel MUST be able to 721 determine the MTU of the tunnel as a whole. It MAY do this by 722 sending packets through the tunnel to the tunnel's receiving 723 endpoint, and performing Path MTU Discovery with those packets. 725 - Any time the transmitting endpoint of the tunnel needs to send a 726 packet into the tunnel, and that packet has the DF bit set, and 727 it exceeds the tunnel MTU, the transmitting endpoint of the 728 tunnel MUST send the ICMP Destination Unreachable message to the 729 source, with code "Fragmentation Required and DF Set", and the 730 Next-Hop MTU Field set as described above. 732 4. Transporting Labeled Packets over PPP 734 The Point-to-Point Protocol (PPP) [7] provides a standard method for 735 transporting multi-protocol datagrams over point-to-point links. PPP 736 defines an extensible Link Control Protocol, and proposes a family of 737 Network Control Protocols for establishing and configuring different 738 network-layer protocols. 740 This section defines the Network Control Protocol for establishing 741 and configuring label Switching over PPP. 743 4.1. Introduction 745 PPP has three main components: 747 1. A method for encapsulating multi-protocol datagrams. 749 2. A Link Control Protocol (LCP) for establishing, configuring, 750 and testing the data-link connection. 752 3. A family of Network Control Protocols for establishing and 753 configuring different network-layer protocols. 755 In order to establish communications over a point-to-point link, each 756 end of the PPP link must first send LCP packets to configure and test 757 the data link. After the link has been established and optional 758 facilities have been negotiated as needed by the LCP, PPP must send 759 "MPLS Control Protocol" packets to enable the transmission of labeled 760 packets. Once the "MPLS Control Protocol" has reached the Opened 761 state, labeled packets can be sent over the link. 763 The link will remain configured for communications until explicit LCP 764 or MPLS Control Protocol packets close the link down, or until some 765 external event occurs (an inactivity timer expires or network 766 administrator intervention). 768 4.2. A PPP Network Control Protocol for MPLS 770 The MPLS Control Protocol (MPLSCP) is responsible for enabling and 771 disabling the use of label switching on a PPP link. It uses the same 772 packet exchange mechanism as the Link Control Protocol (LCP). MPLSCP 773 packets may not be exchanged until PPP has reached the Network-Layer 774 Protocol phase. MPLSCP packets received before this phase is reached 775 should be silently discarded. 777 The MPLS Control Protocol is exactly the same as the Link Control 778 Protocol [7] with the following exceptions: 780 1. Frame Modifications 782 The packet may utilize any modifications to the basic frame 783 format which have been negotiated during the Link Establishment 784 phase. 786 2. Data Link Layer Protocol Field 788 Exactly one MPLSCP packet is encapsulated in the PPP 789 Information field, where the PPP Protocol field indicates type 790 hex 8281 (MPLS). 792 3. Code field 794 Only Codes 1 through 7 (Configure-Request, Configure-Ack, 795 Configure-Nak, Configure-Reject, Terminate-Request, Terminate- 796 Ack and Code-Reject) are used. Other Codes should be treated 797 as unrecognized and should result in Code-Rejects. 799 4. Timeouts 801 MPLSCP packets may not be exchanged until PPP has reached the 802 Network-Layer Protocol phase. An implementation should be 803 prepared to wait for Authentication and Link Quality 804 Determination to finish before timing out waiting for a 805 Configure-Ack or other response. It is suggested that an 806 implementation give up only after user intervention or a 807 configurable amount of time. 809 5. Configuration Option Types 811 None. 813 4.3. Sending Labeled Packets 815 Before any labeled packets may be communicated, PPP must reach the 816 Network-Layer Protocol phase, and the MPLS Control Protocol must 817 reach the Opened state. 819 Exactly one labeled packet is encapsulated in the PPP Information 820 field, where the PPP Protocol field indicates either type hex 0281 821 (MPLS Unicast) or type hex 0283 (MPLS Multicast). The maximum length 822 of a labeled packet transmitted over a PPP link is the same as the 823 maximum length of the Information field of a PPP encapsulated packet. 825 The format of the Information field itself is as defined in section 826 2. 828 Note that two codepoints are defined for labeled packets; one for 829 multicast and one for unicast. Once the MPLSCP has reached the 830 Opened state, both label switched multicasts and label switched 831 unicasts can be sent over the PPP link. 833 4.4. Label Switching Control Protocol Configuration Options 835 There are no configuration options. 837 5. Transporting Labeled Packets over LAN Media 839 Exactly one labeled packet is carried in each frame. 841 The label stack entries immediately precede the network layer header, 842 and follow any data link layer headers, including, e.g., any 802.1Q 843 headers that may exist. 845 The ethertype value 8847 hex is used to indicate that a frame is 846 carrying an MPLS unicast packet. 848 The ethertype value 8848 hex is used to indicate that a frame is 849 carrying an MPLS multicast packet. 851 These ethertype values can be used with either the ethernet 852 encapsulation or the 802.3 LLC/SNAP encapsulation to carry labeled 853 packets. 855 6. IANA Considerations 857 Label values 0-15 inclusive have special meaning, as specified in 858 this document, or as further assigned by IANA. 860 In this document, label values 0-3 are specified in section 2.1. 862 Label values 4-15 may be assigned by IANA, based on IETF Consensus. 864 7. Security Considerations 866 The MPLS encapsulation that is specified herein does not raise any 867 security issues that are not already present in either the MPLS 868 architecture [1] or in the architecture of the network layer protocol 869 contained within the encapsulation. 871 There are two security considerations inherited from the MPLS 872 architecture which may be pointed out here: 874 - Some routers may implement security procedures which depend on 875 the network layer header being in a fixed place relative to the 876 data link layer header. These procedures will not work when the 877 MPLS encapsulation is used, because that encapsulation is of a 878 variable size. 880 - An MPLS label has its meaning by virtue of an agreement between 881 the LSR that puts the label in the label stack (the "label 882 writer") , and the LSR that interprets that label (the "label 883 reader"). However, the label stack does not provide any means of 884 determining who the label writer was for any particular label. 885 If labeled packets are accepted from untrusted sources, the 886 result may be that packets are routed in an illegitimate manner. 888 8. Authors' Addresses 890 Eric C. Rosen 891 Cisco Systems, Inc. 892 250 Apollo Drive 893 Chelmsford, MA, 01824 894 E-mail: erosen@cisco.com 896 Dan Tappan 897 Cisco Systems, Inc. 898 250 Apollo Drive 899 Chelmsford, MA, 01824 900 E-mail: tappan@cisco.com 902 Dino Farinacci 903 Cisco Systems, Inc. 904 170 Tasman Drive 905 San Jose, CA, 95134 906 E-mail: dino@cisco.com 908 Yakov Rekhter 909 Cisco Systems, Inc. 910 170 Tasman Drive 911 San Jose, CA, 95134 912 E-mail: yakov@cisco.com 914 Guy Fedorkow 915 Cisco Systems, Inc. 916 250 Apollo Drive 917 Chelmsford, MA, 01824 918 E-mail: fedorkow@cisco.com 920 Tony Li 921 Juniper Networks 922 385 Ravendale Dr. 923 Mountain View, CA, 94043 924 E-mail: tli@juniper.net 926 Alex Conta 927 Lucent Technologies 928 300 Baker Avenue 929 Concord, MA, 01742 930 E-mail: aconta@lucent.com 932 9. References 934 [1] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol Label 935 Switching Architecture", Work in Progress, April 1999. 937 [2] Callon, R., Doolan, P., Feldman, N., Fredette, A., Swallow, G., 938 Viswanathan, A., "A Framework for Multiprotocol Label Switching", 939 Work in Progress, November 1997. 941 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 942 Levels", RFC 2119, BCP 14, March 1997. 944 [4] Postel, J., "Internet Control Message Protocol", RFC 792, 945 September 1981. 947 [5] Mogul, J. and Deering S., "Path MTU Discovery", RFC 1191, 948 November 1990. 950 [6] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. 952 [7] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC 953 1661, STD 51, July 1994. 955 [8] Conta, A. and Deering, S., "Internet Control Message Protocol 956 (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", 957 RFC 1885, December 1995. 959 [9] McCann, J., Deering, S. and Mogul, J., "Path MTU Discovery for IP 960 version 6", RFC 1981, August 1996. 962 [10] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E. 963 and Swallow G., "MPLS Using LDP and ATM VC Switching", Work in 964 Progress, April 1999.