idnits 2.17.1 draft-ietf-mpls-label-encaps-05.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: ---------------------------------------------------------------------------- == 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 360 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 (August 1999) is 9019 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: 6 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: February 2000 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 August 1999 16 MPLS Label Stack Encoding 18 draft-ietf-mpls-label-encaps-05.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 Intellectual Property .................................. 20 89 9 Authors' Addresses ..................................... 21 90 10 References ............................................. 22 92 1. Introduction 94 "Multi-Protocol Label Switching (MPLS)" [1,2] requires a set of 95 procedures for augmenting network layer packets with "label stacks", 96 thereby turning them into "labeled packets". Routers which support 97 MPLS are known as "Label Switching Routers", or "LSRs". In order to 98 transmit a labeled packet on a particular data link, an LSR must 99 support an encoding technique which, given a label stack and a 100 network layer packet, produces a labeled packet. 102 This document specifies the encoding to be used by an LSR in order to 103 transmit labeled packets on PPP data links and on LAN data links. 104 The specified encoding may also be useful for other data links as 105 well. 107 This document also specifies rules and procedures for processing the 108 various fields of the label stack encoding. Since MPLS is 109 independent of any particular network layer protocol, the majority of 110 such procedures are also protocol-independent. A few, however, do 111 differ for different protocols. In this document, we specify the 112 protocol-independent procedures, and we specify the protocol- 113 dependent procedures for IPv4 and IPv6. 115 LSRs that are implemented on certain switching devices (such as ATM 116 switches) may use different encoding techniques for encoding the top 117 one or two entries of the label stack. When the label stack has 118 additional entries, however, the encoding technique described in this 119 document MUST be used for the additional label stack entries. 121 1.1. Specification of Requirements 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [3]. 127 2. The Label Stack 129 2.1. Encoding the Label Stack 131 The label stack is represented as a sequence of "label stack 132 entries". Each label stack entry is represented by 4 octets. This 133 is shown in Figure 1. 135 0 1 2 3 136 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 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label 138 | Label | Exp |S| TTL | Stack 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry 141 Label: Label Value, 20 bits 142 Exp: Experimental Use, 3 bits 143 S: Bottom of Stack, 1 bit 144 TTL: Time to Live, 8 bits 146 Figure 1 148 The label stack entries appear AFTER the data link layer headers, but 149 BEFORE any network layer headers. The top of the label stack appears 150 earliest in the packet, and the bottom appears latest. The network 151 layer packet immediately follows the label stack entry which has the 152 S bit set. 154 Each label stack entry is broken down into the following fields: 156 1. Bottom of Stack (S) 158 This bit is set to one for the last entry in the label stack 159 (i.e., for the bottom of the stack), and zero for all other 160 label stack entries. 162 2. Time to Live (TTL) 164 This eight-bit field is used to encode a time-to-live value. 165 The processing of this field is described in section 2.4. 167 3. Experimental Use 169 This three-bit field is reserved for experimental use. 171 4. Label Value 173 This 20-bit field carries the actual value of the Label. 175 When a labeled packet is received, the label value at the top 176 of the stack is looked up. As a result of a successful lookup 177 one learns: 179 (a) the next hop to which the packet is to be forwarded; 181 (b) the operation to be performed on the label stack before 182 forwarding; this operation may be to replace the top 183 label stack entry with another, or to pop an entry off 184 the label stack, or to replace the top label stack entry 185 and then to push one or more additional entries on the 186 label stack. 188 In addition to learning the next hop and the label stack 189 operation, one may also learn the outgoing data link 190 encapsulation, and possibly other information which is needed 191 in order to properly forward the packet. 193 There are several reserved label values: 195 i. A value of 0 represents the "IPv4 Explicit NULL Label". 196 This label value is only legal when it is the sole 197 label stack entry. It indicates that the label stack 198 must be popped, and the forwarding of the packet must 199 then be based on the IPv4 header. 201 ii. A value of 1 represents the "Router Alert Label". This 202 label value is legal anywhere in the label stack except 203 at the bottom. When a received packet contains this 204 label value at the top of the label stack, it is 205 delivered to a local software module for processing. 206 The actual forwarding of the packet is determined by 207 the label beneath it in the stack. However, if the 208 packet is forwarded further, the Router Alert Label 209 should be pushed back onto the label stack before 210 forwarding. The use of this label is analogous to the 211 use of the "Router Alert Option" in IP packets [6]. 212 Since this label cannot occur at the bottom of the 213 stack, it is not associated with a particular network 214 layer protocol. 216 iii. A value of 2 represents the "IPv6 Explicit NULL Label". 217 This label value is only legal when it is the sole 218 label stack entry. It indicates that the label stack 219 must be popped, and the forwarding of the packet must 220 then be based on the IPv6 header. 222 iv. A value of 3 represents the "Implicit NULL Label". 223 This is a label that an LSR may assign and distribute, 224 but which never actually appears in the encapsulation. 225 When an LSR would otherwise replace the label at the 226 top of the stack with a new label, but the new label is 227 "Implicit NULL", the LSR will pop the stack instead of 228 doing the replacement. Although this value may never 229 appear in the encapsulation, it needs to be specified 230 in the Label Distribution Protocol, so a value is 231 reserved. 233 v. Values 4-15 are reserved. 235 2.2. Determining the Network Layer Protocol 237 When the last label is popped from a packet's label stack (resulting 238 in the stack being emptied), further processing of the packet is 239 based on the packet's network layer header. The LSR which pops the 240 last label off the stack must therefore be able to identify the 241 packet's network layer protocol. However, the label stack does not 242 contain any field which explicitly identifies the network layer 243 protocol. This means that the identity of the network layer protocol 244 must be inferable from the value of the label which is popped from 245 the bottom of the stack, possibly along with the contents of the 246 network layer header itself. 248 Therefore, when the first label is pushed onto a network layer 249 packet, either the label must be one which is used ONLY for packets 250 of a particular network layer, or the label must be one which is used 251 ONLY for a specified set of network layer protocols, where packets of 252 the specified network layers can be distinguished by inspection of 253 the network layer header. Furthermore, whenever that label is 254 replaced by another label value during a packet's transit, the new 255 value must also be one which meets the same criteria. If these 256 conditions are not met, the LSR which pops the last label off a 257 packet will not be able to identify the packet's network layer 258 protocol. 260 Adherence to these conditions does not necessarily enable 261 intermediate nodes to identify a packet's network layer protocol. 262 Under ordinary conditions, this is not necessary, but there are error 263 conditions under which it is desirable. For instance, if an 264 intermediate LSR determines that a labeled packet is undeliverable, 265 it may be desirable for that LSR to generate error messages which are 266 specific to the packet's network layer. The only means the 267 intermediate LSR has for identifying the network layer is inspection 268 of the top label and the network layer header. So if intermediate 269 nodes are to be able to generate protocol-specific error messages for 270 labeled packets, all labels in the stack must meet the criteria 271 specified above for labels which appear at the bottom of the stack. 273 If a packet cannot be forwarded for some reason (e.g., it exceeds the 274 data link MTU), and either its network layer protocol cannot be 275 identified, or there are no specified protocol-dependent rules for 276 handling the error condition, then the packet MUST be silently 277 discarded. 279 2.3. Generating ICMP Messages for Labeled IP Packets 281 Section 2.4 and section 3 discuss situations in which it is desirable 282 to generate ICMP messages for labeled IP packets. In order for a 283 particular LSR to be able to generate an ICMP packet and have that 284 packet sent to the source of the IP packet, two conditions must hold: 286 1. it must be possible for that LSR to determine that a particular 287 labeled packet is an IP packet; 289 2. it must be possible for that LSR to route to the packet's IP 290 source address. 292 Condition 1 is discussed in section 2.2. The following two 293 subsections discuss condition 2. However, there will be some cases 294 in which condition 2 does not hold at all, and in these cases it will 295 not be possible to generate the ICMP message. 297 2.3.1. Tunneling through a Transit Routing Domain 299 Suppose one is using MPLS to "tunnel" through a transit routing 300 domain, where the external routes are not leaked into the domain's 301 interior routers. For example, the interior routers may be running 302 OSPF, and may only know how to reach destinations within that OSPF 303 domain. The domain might contain several Autonomous System Border 304 Routers (ASBRs), which talk BGP to each other. However, in this 305 example the routes from BGP are not distributed into OSPF, and the 306 LSRs which are not ASBRs do not run BGP. 308 In this example, only an ASBR will know how to route to the source of 309 some arbitrary packet. If an interior router needs to send an ICMP 310 message to the source of an IP packet, it will not know how to route 311 the ICMP message. 313 One solution is to have one or more of the ASBRs inject "default" 314 into the IGP. (N.B.: this does NOT require that there be a "default" 315 carried by BGP.) This would then ensure that any unlabeled packet 316 which must leave the domain (such as an ICMP packet) gets sent to a 317 router which has full routing information. The routers with full 318 routing information will label the packets before sending them back 319 through the transit domain, so the use of default routing within the 320 transit domain does not cause any loops. 322 This solution only works for packets which have globally unique 323 addresses, and for networks in which all the ASBRs have complete 324 routing information. The next subsection describes a solution which 325 works when these conditions do not hold. 327 2.3.2. Tunneling Private Addresses through a Public Backbone 329 In some cases where MPLS is used to tunnel through a routing domain, 330 it may not be possible to route to the source address of a fragmented 331 packet at all. This would be the case, for example, if the IP 332 addresses carried in the packet were private (i.e., not globally 333 unique) addresses, and MPLS were being used to tunnel those packets 334 through a public backbone. Default routing to an ASBR will not work 335 in this environment. 337 In this environment, in order to send an ICMP message to the source 338 of a packet, one can copy the label stack from the original packet to 339 the ICMP message, and then label switch the ICMP message. This will 340 cause the message to proceed in the direction of the original 341 packet's destination, rather than its source. Unless the message is 342 label switched all the way to the destination host, it will end up, 343 unlabeled, in a router which does know how to route to the source of 344 original packet, at which point the message will be sent in the 345 proper direction. 347 This technique can be very useful if the ICMP message is a "Time 348 Exceeded" message or a "Destination Unreachable because fragmentation 349 needed and DF set" message. 351 When copying the label stack from the original packet to the ICMP 352 message, the label values must be copied exactly, but the TTL values 353 in the label stack should be set to the TTL value that is placed in 354 the IP header of the ICMP message. This TTL value should be long 355 enough to allow the circuitous route that the ICMP message will need 356 to follow. 358 Note that if a packet's TTL expiration is due to the presence of a 359 routing loop, then if this technique is used, the ICMP message may 360 loop as well. Since an ICMP message is never sent as a result of 361 receiving an ICMP message, and since many implementations throttle 362 the rate at which ICMP messages can be generated, this is not 363 expected to pose a problem. 365 2.4. Processing the Time to Live Field 367 2.4.1. Definitions 369 The "incoming TTL" of a labeled packet is defined to be the value of 370 the TTL field of the top label stack entry when the packet is 371 received. 373 The "outgoing TTL" of a labeled packet is defined to be the larger 374 of: 376 (a) one less than the incoming TTL, 377 (b) zero. 379 2.4.2. Protocol-independent rules 381 If the outgoing TTL of a labeled packet is 0, then the labeled packet 382 MUST NOT be further forwarded; nor may the label stack be stripped 383 off and the packet forwarded as an unlabeled packet. The packet's 384 lifetime in the network is considered to have expired. 386 Depending on the label value in the label stack entry, the packet MAY 387 be simply discarded, or it may be passed to the appropriate 388 "ordinary" network layer for error processing (e.g., for the 389 generation of an ICMP error message, see section 2.3). 391 When a labeled packet is forwarded, the TTL field of the label stack 392 entry at the top of the label stack MUST be set to the outgoing TTL 393 value. 395 Note that the outgoing TTL value is a function solely of the incoming 396 TTL value, and is independent of whether any labels are pushed or 397 popped before forwarding. There is no significance to the value of 398 the TTL field in any label stack entry which is not at the top of the 399 stack. 401 2.4.3. IP-dependent rules 403 We define the "IP TTL" field to be the value of the IPv4 TTL field, 404 or the value of the IPv6 Hop Limit field, whichever is applicable. 406 When an IP packet is first labeled, the TTL field of the label stack 407 entry MUST BE set to the value of the IP TTL field. (If the IP TTL 408 field needs to be decremented, as part of the IP processing, it is 409 assumed that this has already been done.) 411 When a label is popped, and the resulting label stack is empty, then 412 the value of the IP TTL field SHOULD BE replaced with the outgoing 413 TTL value, as defined above. In IPv4 this also requires modification 414 of the IP header checksum. 416 It is recognized that there may be situations where a network 417 administration prefers to decrement the IPv4 TTL by one as it 418 traverses an MPLS domain, instead of decrementing the IPv4 TTL by the 419 number of LSP hops within the domain. 421 2.4.4. Translating Between Different Encapsulations 423 Sometimes an LSR may receive a labeled packet over, e.g., a label 424 switching controlled ATM (LC-ATM) interface [10], and may need to 425 send it out over a PPP or LAN link. Then the incoming packet will 426 not be received using the encapsulation specified in this document, 427 but the outgoing packet will be sent using the encapsulation 428 specified in this document. 430 In this case, the value of the "incoming TTL" is determined by the 431 procedures used for carrying labeled packets on, e.g., LC-ATM 432 interfaces. TTL processing then proceeds as described above. 434 Sometimes an LSR may receive a labeled packet over a PPP or a LAN 435 link, and may need to send it out, say, an LC-ATM interface. Then 436 the incoming packet will be received using the encapsulation 437 specified in this document, but the outgoing packet will not be sent 438 using the encapsulation specified in this document. In this case, 439 the procedure for carrying the value of the "outgoing TTL" is 440 determined by the procedures used for carrying labeled packets on, 441 e.g., LC-ATM interfaces. 443 3. Fragmentation and Path MTU Discovery 445 Just as it is possible to receive an unlabeled IP datagram which is 446 too large to be transmitted on its output link, it is possible to 447 receive a labeled packet which is too large to be transmitted on its 448 output link. 450 It is also possible that a received packet (labeled or unlabeled) 451 which was originally small enough to be transmitted on that link 452 becomes too large by virtue of having one or more additional labels 453 pushed onto its label stack. In label switching, a packet may grow 454 in size if additional labels get pushed on. Thus if one receives a 455 labeled packet with a 1500-byte frame payload, and pushes on an 456 additional label, one needs to forward it as frame with a 1504-byte 457 payload. 459 This section specifies the rules for processing labeled packets which 460 are "too large". In particular, it provides rules which ensure that 461 hosts implementing Path MTU Discovery [5], and hosts using IPv6 462 [8,9], will be able to generate IP datagrams that do not need 463 fragmentation, even if those datagrams get labeled as they traverse 464 the network. 466 In general, IPv4 hosts which do not implement Path MTU Discovery [5] 467 send IP datagrams which contain no more than 576 bytes. Since the 468 MTUs in use on most data links today are 1500 bytes or more, the 469 probability that such datagrams will need to get fragmented, even if 470 they get labeled, is very small. 472 Some hosts that do not implement Path MTU Discovery [5] will generate 473 IP datagrams containing 1500 bytes, as long as the IP Source and 474 Destination addresses are on the same subnet. These datagrams will 475 not pass through routers, and hence will not get fragmented. 477 Unfortunately, some hosts will generate IP datagrams containing 1500 478 bytes, as long the IP Source and Destination addresses have the same 479 classful network number. This is the one case in which there is any 480 risk of fragmentation when such datagrams get labeled. (Even so, 481 fragmentation is not likely unless the packet must traverse an 482 ethernet of some sort between the time it first gets labeled and the 483 time it gets unlabeled.) 485 This document specifies procedures which allow one to configure the 486 network so that large datagrams from hosts which do not implement 487 Path MTU Discovery get fragmented just once, when they are first 488 labeled. These procedures make it possible (assuming suitable 489 configuration) to avoid any need to fragment packets which have 490 already been labeled. 492 3.1. Terminology 494 With respect to a particular data link, we can use the following 495 terms: 497 - Frame Payload: 499 The contents of a data link frame, excluding any data link layer 500 headers or trailers (e.g., MAC headers, LLC headers, 802.1Q 501 headers, PPP header, frame check sequences, etc.). 503 When a frame is carrying an unlabeled IP datagram, the Frame 504 Payload is just the IP datagram itself. When a frame is carrying 505 a labeled IP datagram, the Frame Payload consists of the label 506 stack entries and the IP datagram. 508 - Conventional Maximum Frame Payload Size: 510 The maximum Frame Payload size allowed by data link standards. 511 For example, the Conventional Maximum Frame Payload Size for 512 ethernet is 1500 bytes. 514 - True Maximum Frame Payload Size: 516 The maximum size frame payload which can be sent and received 517 properly by the interface hardware attached to the data link. 519 On ethernet and 802.3 networks, it is believed that the True 520 Maximum Frame Payload Size is 4-8 bytes larger than the 521 Conventional Maximum Frame Payload Size (as long as neither an 522 802.1Q header nor an 802.1p header is present, and as long as 523 neither can be added by a switch or bridge while a packet is in 524 transit to its next hop). For example, it is believed that most 525 ethernet equipment could correctly send and receive packets 526 carrying a payload of 1504 or perhaps even 1508 bytes, at least, 527 as long as the ethernet header does not have an 802.1Q or 802.1p 528 field. 530 On PPP links, the True Maximum Frame Payload Size may be 531 virtually unbounded. 533 - Effective Maximum Frame Payload Size for Labeled Packets: 535 This is either the Conventional Maximum Frame Payload Size or the 536 True Maximum Frame Payload Size, depending on the capabilities of 537 the equipment on the data link and the size of the data link 538 header being used. 540 - Initially Labeled IP Datagram: 542 Suppose that an unlabeled IP datagram is received at a particular 543 LSR, and that the the LSR pushes on a label before forwarding the 544 datagram. Such a datagram will be called an Initially Labeled IP 545 Datagram at that LSR. 547 - Previously Labeled IP Datagram: 549 An IP datagram which had already been labeled before it was 550 received by a particular LSR. 552 3.2. Maximum Initially Labeled IP Datagram Size 554 Every LSR which is capable of 556 (a) receiving an unlabeled IP datagram, 557 (b) adding a label stack to the datagram, and 558 (c) forwarding the resulting labeled packet, 560 SHOULD support a configuration parameter known as the "Maximum 561 Initially Labeled IP Datagram Size", which can be set to a non- 562 negative value. 564 If this configuration parameter is set to zero, it has no effect. 566 If it is set to a positive value, it is used in the following way. 567 If: 568 (a) an unlabeled IP datagram is received, and 569 (b) that datagram does not have the DF bit set in its IP header, 570 and 571 (c) that datagram needs to be labeled before being forwarded, and 572 (d) the size of the datagram (before labeling) exceeds the value 573 of the parameter, 574 then 575 (a) the datagram must be broken into fragments, each of whose size 576 is no greater than the value of the parameter, and 577 (b) each fragment must be labeled and then forwarded. 579 For example, if this configuration parameter is set to a value of 580 1488, then any unlabeled IP datagram containing more than 1488 bytes 581 will be fragmented before being labeled. Each fragment will be 582 capable of being carried on a 1500-byte data link, without further 583 fragmentation, even if as many as three labels are pushed onto its 584 label stack. 586 In other words, setting this parameter to a non-zero value allows one 587 to eliminate all fragmentation of Previously Labeled IP Datagrams, 588 but it may cause some unnecessary fragmentation of Initially Labeled 589 IP Datagrams. 591 Note that the setting of this parameter does not affect the 592 processing of IP datagrams that have the DF bit set; hence the result 593 of Path MTU discovery is unaffected by the setting of this parameter. 595 3.3. When are Labeled IP Datagrams Too Big? 597 A labeled IP datagram whose size exceeds the Conventional Maximum 598 Frame Payload Size of the data link over which it is to be forwarded 599 MAY be considered to be "too big". 601 A labeled IP datagram whose size exceeds the True Maximum Frame 602 Payload Size of the data link over which it is to be forwarded MUST 603 be considered to be "too big". 605 A labeled IP datagram which is not "too big" MUST be transmitted 606 without fragmentation. 608 3.4. Processing Labeled IPv4 Datagrams which are Too Big 610 If a labeled IPv4 datagram is "too big", and the DF bit is not set in 611 its IP header, then the LSR MAY silently discard the datagram. 613 Note that discarding such datagrams is a sensible procedure only if 614 the "Maximum Initially Labeled IP Datagram Size" is set to a non-zero 615 value in every LSR in the network which is capable of adding a label 616 stack to an unlabeled IP datagram. 618 If the LSR chooses not to discard a labeled IPv4 datagram which is 619 too big, or if the DF bit is set in that datagram, then it MUST 620 execute the following algorithm: 622 1. Strip off the label stack entries to obtain the IP datagram. 624 2. Let N be the number of bytes in the label stack (i.e, 4 times 625 the number of label stack entries). 627 3. If the IP datagram does NOT have the "Don't Fragment" bit set 628 in its IP header: 630 a. convert it into fragments, each of which MUST be at least 631 N bytes less than the Effective Maximum Frame Payload 632 Size. 634 b. Prepend each fragment with the same label header that 635 would have been on the original datagram had 636 fragmentation not been necessary. 638 c. Forward the fragments 640 4. If the IP datagram has the "Don't Fragment" bit set in its IP 641 header: 643 a. the datagram MUST NOT be forwarded 645 b. Create an ICMP Destination Unreachable Message: 647 i. set its Code field [4] to "Fragmentation Required 648 and DF Set", 650 ii. set its Next-Hop MTU field [5] to the difference 651 between the Effective Maximum Frame Payload Size 652 and the value of N 654 c. If possible, transmit the ICMP Destination Unreachable 655 Message to the source of the of the discarded datagram. 657 3.5. Processing Labeled IPv6 Datagrams which are Too Big 659 To process a labeled IPv6 datagram which is too big, an LSR MUST 660 execute the following algorithm: 662 1. Strip off the label stack entries to obtain the IP datagram. 664 2. Let N be the number of bytes in the label stack (i.e, 4 times 665 the number of label stack entries). 667 3. If the IP datagram contains more than 1280 bytes (not counting 668 the label stack entries), then: 670 a. Create an ICMP Packet Too Big Message, and set its Next- 671 Hop MTU field to the difference between the Effective 672 Maximum Frame Payload Size and the value of N 674 b. If possible, transmit the ICMP Packet Too Big Message to 675 the source of the datagram. 677 c. discard the labeled IPv6 datagram. 679 4. If the IP datagram is not larger than 1280 octets, then 681 a. Convert it into fragments, each of which MUST be at least 682 N bytes less than the Effective Maximum Frame Payload 683 Size. 685 b. Prepend each fragment with the same label header that 686 would have been on the original datagram had 687 fragmentation not been necessary. 689 c. Forward the fragments. 691 Reassembly of the fragments will be done at the destination 692 host. 694 3.6. Implications with respect to Path MTU Discovery 696 The procedures described above for handling datagrams which have the 697 DF bit set, but which are "too large", have an impact on the Path MTU 698 Discovery procedures of RFC 1191 [5]. Hosts which implement these 699 procedures will discover an MTU which is small enough to allow n 700 labels to be pushed on the datagrams, without need for fragmentation, 701 where n is the number of labels that actually get pushed on along the 702 path currently in use. 704 In other words, datagrams from hosts that use Path MTU Discovery will 705 never need to be fragmented due to the need to put on a label header, 706 or to add new labels to an existing label header. (Also, datagrams 707 from hosts that use Path MTU Discovery generally have the DF bit set, 708 and so will never get fragmented anyway.) 710 Note that Path MTU Discovery will only work properly if, at the point 711 where a labeled IP Datagram's fragmentation needs to occur, it is 712 possible to cause an ICMP Destination Unreachable message to be 713 routed to the packet's source address. See section 2.3. 715 If it is not possible to forward an ICMP message from within an MPLS 716 "tunnel" to a packet's source address, but the network configuration 717 makes it possible for the LSR at the transmitting end of the tunnel 718 to receive packets that must go through the tunnel, but are too large 719 to pass through the tunnel unfragmented, then: 721 - The LSR at the transmitting end of the tunnel MUST be able to 722 determine the MTU of the tunnel as a whole. It MAY do this by 723 sending packets through the tunnel to the tunnel's receiving 724 endpoint, and performing Path MTU Discovery with those packets. 726 - Any time the transmitting endpoint of the tunnel needs to send a 727 packet into the tunnel, and that packet has the DF bit set, and 728 it exceeds the tunnel MTU, the transmitting endpoint of the 729 tunnel MUST send the ICMP Destination Unreachable message to the 730 source, with code "Fragmentation Required and DF Set", and the 731 Next-Hop MTU Field set as described above. 733 4. Transporting Labeled Packets over PPP 735 The Point-to-Point Protocol (PPP) [7] provides a standard method for 736 transporting multi-protocol datagrams over point-to-point links. PPP 737 defines an extensible Link Control Protocol, and proposes a family of 738 Network Control Protocols for establishing and configuring different 739 network-layer protocols. 741 This section defines the Network Control Protocol for establishing 742 and configuring label Switching over PPP. 744 4.1. Introduction 746 PPP has three main components: 748 1. A method for encapsulating multi-protocol datagrams. 750 2. A Link Control Protocol (LCP) for establishing, configuring, 751 and testing the data-link connection. 753 3. A family of Network Control Protocols for establishing and 754 configuring different network-layer protocols. 756 In order to establish communications over a point-to-point link, each 757 end of the PPP link must first send LCP packets to configure and test 758 the data link. After the link has been established and optional 759 facilities have been negotiated as needed by the LCP, PPP must send 760 "MPLS Control Protocol" packets to enable the transmission of labeled 761 packets. Once the "MPLS Control Protocol" has reached the Opened 762 state, labeled packets can be sent over the link. 764 The link will remain configured for communications until explicit LCP 765 or MPLS Control Protocol packets close the link down, or until some 766 external event occurs (an inactivity timer expires or network 767 administrator intervention). 769 4.2. A PPP Network Control Protocol for MPLS 771 The MPLS Control Protocol (MPLSCP) is responsible for enabling and 772 disabling the use of label switching on a PPP link. It uses the same 773 packet exchange mechanism as the Link Control Protocol (LCP). MPLSCP 774 packets may not be exchanged until PPP has reached the Network-Layer 775 Protocol phase. MPLSCP packets received before this phase is reached 776 should be silently discarded. 778 The MPLS Control Protocol is exactly the same as the Link Control 779 Protocol [7] with the following exceptions: 781 1. Frame Modifications 783 The packet may utilize any modifications to the basic frame 784 format which have been negotiated during the Link Establishment 785 phase. 787 2. Data Link Layer Protocol Field 789 Exactly one MPLSCP packet is encapsulated in the PPP 790 Information field, where the PPP Protocol field indicates type 791 hex 8281 (MPLS). 793 3. Code field 795 Only Codes 1 through 7 (Configure-Request, Configure-Ack, 796 Configure-Nak, Configure-Reject, Terminate-Request, Terminate- 797 Ack and Code-Reject) are used. Other Codes should be treated 798 as unrecognized and should result in Code-Rejects. 800 4. Timeouts 802 MPLSCP packets may not be exchanged until PPP has reached the 803 Network-Layer Protocol phase. An implementation should be 804 prepared to wait for Authentication and Link Quality 805 Determination to finish before timing out waiting for a 806 Configure-Ack or other response. It is suggested that an 807 implementation give up only after user intervention or a 808 configurable amount of time. 810 5. Configuration Option Types 812 None. 814 4.3. Sending Labeled Packets 816 Before any labeled packets may be communicated, PPP must reach the 817 Network-Layer Protocol phase, and the MPLS Control Protocol must 818 reach the Opened state. 820 Exactly one labeled packet is encapsulated in the PPP Information 821 field, where the PPP Protocol field indicates either type hex 0281 822 (MPLS Unicast) or type hex 0283 (MPLS Multicast). The maximum length 823 of a labeled packet transmitted over a PPP link is the same as the 824 maximum length of the Information field of a PPP encapsulated packet. 826 The format of the Information field itself is as defined in section 827 2. 829 Note that two codepoints are defined for labeled packets; one for 830 multicast and one for unicast. Once the MPLSCP has reached the 831 Opened state, both label switched multicasts and label switched 832 unicasts can be sent over the PPP link. 834 4.4. Label Switching Control Protocol Configuration Options 836 There are no configuration options. 838 5. Transporting Labeled Packets over LAN Media 840 Exactly one labeled packet is carried in each frame. 842 The label stack entries immediately precede the network layer header, 843 and follow any data link layer headers, including, e.g., any 802.1Q 844 headers that may exist. 846 The ethertype value 8847 hex is used to indicate that a frame is 847 carrying an MPLS unicast packet. 849 The ethertype value 8848 hex is used to indicate that a frame is 850 carrying an MPLS multicast packet. 852 These ethertype values can be used with either the ethernet 853 encapsulation or the 802.3 LLC/SNAP encapsulation to carry labeled 854 packets. 856 6. IANA Considerations 858 Label values 0-15 inclusive have special meaning, as specified in 859 this document, or as further assigned by IANA. 861 In this document, label values 0-3 are specified in section 2.1. 863 Label values 4-15 may be assigned by IANA, based on IETF Consensus. 865 7. Security Considerations 867 The MPLS encapsulation that is specified herein does not raise any 868 security issues that are not already present in either the MPLS 869 architecture [1] or in the architecture of the network layer protocol 870 contained within the encapsulation. 872 There are two security considerations inherited from the MPLS 873 architecture which may be pointed out here: 875 - Some routers may implement security procedures which depend on 876 the network layer header being in a fixed place relative to the 877 data link layer header. These procedures will not work when the 878 MPLS encapsulation is used, because that encapsulation is of a 879 variable size. 881 - An MPLS label has its meaning by virtue of an agreement between 882 the LSR that puts the label in the label stack (the "label 883 writer") , and the LSR that interprets that label (the "label 884 reader"). However, the label stack does not provide any means of 885 determining who the label writer was for any particular label. 886 If labeled packets are accepted from untrusted sources, the 887 result may be that packets are routed in an illegitimate manner. 889 8. Intellectual Property 891 The IETF has been notified of intellectual property rights claimed in 892 regard to some or all of the specification contained in this 893 document. For more information consult the online list of claimed 894 rights. 896 9. Authors' Addresses 898 Eric C. Rosen 899 Cisco Systems, Inc. 900 250 Apollo Drive 901 Chelmsford, MA, 01824 902 E-mail: erosen@cisco.com 904 Dan Tappan 905 Cisco Systems, Inc. 906 250 Apollo Drive 907 Chelmsford, MA, 01824 908 E-mail: tappan@cisco.com 910 Dino Farinacci 911 Cisco Systems, Inc. 912 170 Tasman Drive 913 San Jose, CA, 95134 914 E-mail: dino@cisco.com 916 Yakov Rekhter 917 Cisco Systems, Inc. 918 170 Tasman Drive 919 San Jose, CA, 95134 920 E-mail: yakov@cisco.com 922 Guy Fedorkow 923 Cisco Systems, Inc. 924 250 Apollo Drive 925 Chelmsford, MA, 01824 926 E-mail: fedorkow@cisco.com 928 Tony Li 929 Juniper Networks 930 385 Ravendale Dr. 931 Mountain View, CA, 94043 932 E-mail: tli@juniper.net 934 Alex Conta 935 Lucent Technologies 936 300 Baker Avenue 937 Concord, MA, 01742 938 E-mail: aconta@lucent.com 940 10. References 942 [1] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol Label 943 Switching Architecture", Work in Progress, April 1999. 945 [2] Callon, R., Doolan, P., Feldman, N., Fredette, A., Swallow, G., 946 Viswanathan, A., "A Framework for Multiprotocol Label Switching", 947 Work in Progress, November 1997. 949 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 950 Levels", RFC 2119, BCP 14, March 1997. 952 [4] Postel, J., "Internet Control Message Protocol", RFC 792, 953 September 1981. 955 [5] Mogul, J. and Deering S., "Path MTU Discovery", RFC 1191, 956 November 1990. 958 [6] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. 960 [7] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC 961 1661, STD 51, July 1994. 963 [8] Conta, A. and Deering, S., "Internet Control Message Protocol 964 (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", 965 RFC 1885, December 1995. 967 [9] McCann, J., Deering, S. and Mogul, J., "Path MTU Discovery for IP 968 version 6", RFC 1981, August 1996. 970 [10] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E. 971 and Swallow G., "MPLS Using LDP and ATM VC Switching", Work in 972 Progress, April 1999.