idnits 2.17.00 (12 Aug 2021) /tmp/idnits50365/draft-ietf-pwe3-fragmentation-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 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. ** 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 152: '... A PE MAY choose to fragment a pack...' RFC 2119 keyword, line 176: '... that the sender MAY use fragmentation...' RFC 2119 keyword, line 181: '... fragmentation MUST be provisioned i...' RFC 2119 keyword, line 222: '...eld on fragmented packets is REQUIRED....' RFC 2119 keyword, line 230: '... TRANS] SHOULD be used to set the m...' (18 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 2004) is 6669 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) == Outdated reference: draft-ietf-pwe3-arch has been published as RFC 3985 ** Downref: Normative reference to an Informational draft: draft-ietf-pwe3-arch (ref. 'Architecture') -- Possible downref: Non-RFC (?) normative reference: ref. 'FAST' == Outdated reference: draft-ietf-l2tpext-l2tp-base has been published as RFC 3931 == Outdated reference: draft-ietf-pwe3-atm-encap has been published as RFC 4717 == Outdated reference: draft-ietf-pwe3-ethernet-encap has been published as RFC 4448 == Outdated reference: draft-ietf-pwe3-frame-relay has been published as RFC 4619 == Outdated reference: draft-ietf-pwe3-satop has been published as RFC 4553 == Outdated reference: draft-ietf-pwe3-control-protocol has been published as RFC 4447 ** Obsolete normative reference: RFC 1981 (ref. 'PATHMTUv6') (Obsoleted by RFC 8201) ** Downref: Normative reference to an Informational RFC: RFC 1858 (ref. 'IPFRAG-SEC') ** Downref: Normative reference to an Informational RFC: RFC 3128 (ref. 'TINYFRAG') Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Andrew G. Malis 3 Document: draft-ietf-pwe3-fragmentation-05.txt Tellabs 4 Expires: August 2004 W. Mark Townsley 5 Cisco Systems 6 February 2004 8 PWE3 Fragmentation and Reassembly 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document defines a generalized method of performing 34 fragmentation for use by PWE3 protocols and services. 36 Table of Contents 38 1. Overview......................................................2 39 2. Alternatives to PWE3 Fragmentation/Reassembly.................3 40 3. PWE3 Fragmentation With MPLS..................................4 41 3.1 Fragment Bit Locations For MPLS...........................4 42 3.2 Other Considerations......................................5 43 4. PWE3 Fragmentation With L2TP..................................5 44 4.1 PW-specific Fragmentation vs. IP fragmentation............6 45 4.2 Advertising Reassembly Support in L2TP....................6 46 4.3 L2TP Maximum Receive Unit (MRU) AVP.......................7 47 4.4 L2TP Maximum Reassembled Receive Unit (MRRU) AVP..........7 48 4.5 Fragment Bit Locations For L2TPv3 Encapsulation...........8 49 4.6 Fragment Bit Locations for L2TPv2 Encapsulation...........8 50 5. Security Considerations.......................................9 51 6. IANA Considerations...........................................9 52 PWE3 Fragmentation and Reassembly February 2004 54 7. Acknowledgements..............................................9 55 8. References...................................................10 56 9. Authors' Addresses...........................................11 57 10. Appendix A: Relationship Between This Document and RFC 1990.11 59 1. Overview 61 The PWE3 Architecture Document [Architecture] defines a network 62 reference model for PWE3: 64 |<-------------- Emulated Service ---------------->| 65 | | 66 | |<------- Pseudo Wire ------>| | 67 | | | | 68 | | |<-- PSN Tunnel -->| | | 69 | PW End V V V V PW End | 70 V Service +----+ +----+ Service V 71 +-----+ | | PE1|==================| PE2| | +-----+ 72 | |----------|............PW1.............|----------| | 73 | CE1 | | | | | | | | CE2 | 74 | |----------|............PW2.............|----------| | 75 +-----+ ^ | | |==================| | | ^ +-----+ 76 ^ | +----+ +----+ | | ^ 77 | | Provider Edge 1 Provider Edge 2 | | 78 | | | | 79 Customer | | Customer 80 Edge 1 | | Edge 2 81 | | 82 | | 83 native service native service 85 Figure 1: PWE3 Network Reference Model 87 A Pseudo Wire (PW) payload is normally relayed across the PW as a 88 single PSN (IP or MPLS) PDU. However, there are cases where the 89 combined size of the payload and its associated PWE3 and PSN 90 headers may exceed the PSN path Maximum Transmission Unit (MTU). 91 When a packet exceeds the MTU of a given network, fragmentation and 92 reassembly will allow the packet to traverse the network and reach 93 its intended destination. 95 Fragmentation is also useful for real-time applications when the 96 payload to be transmitted in a PW, such as a low-speed TDM 97 multiframe structure, takes too much time to be encapsulated even 98 PWE3 Fragmentation and Reassembly February 2004 100 though it may fit within the PW MTU. In this case, the payload may 101 be fragmented for lower-latency transmission. 103 The purpose of this document is to define a generalized method of 104 performing fragmentation for use with all PWE3 protocols and 105 services. This method should be utilized only in cases where MTU- 106 management methods fail. Due to the increased processing overhead, 107 fragmentation and reassembly in core network devices should always 108 be considered something to avoid whenever possible. 110 The PWE3 fragmentation and reassembly domain is shown in Figure 2: 112 |<-------------- Emulated Service ---------------->| 113 | |<---Fragmentation Domain--->| | 114 | ||<------- Pseudo Wire ---->|| | 115 | || || | 116 | || |<-- PSN Tunnel -->| || | 117 | PW End VV V V VV PW End | 118 V Service +----+ +----+ Service V 119 +-----+ | | PE1|==================| PE2| | +-----+ 120 | |----------|............PW1.............|----------| | 121 | CE1 | | | | | | | | CE2 | 122 | |----------|............PW2.............|----------| | 123 +-----+ ^ | | |==================| | | ^ +-----+ 124 ^ | +----+ +----+ | | ^ 125 | | Provider Edge 1 Provider Edge 2 | | 126 | | | | 127 Customer | | Customer 128 Edge 1 | | Edge 2 129 | | 130 | | 131 native service native service 133 Figure 2: PWE3 Fragmentation/Reassembly Domain 135 Fragmentation takes place in the transmitting PE immediately prior 136 to PW insertion, and reassembly takes place in the receiving PE 137 immediately after PW extraction. 139 2. Alternatives to PWE3 Fragmentation/Reassembly 141 Fragmentation and reassembly in network equipment generally 142 requires significantly greater resources than sending a packet as a 143 PWE3 Fragmentation and Reassembly February 2004 145 single unit. As such, fragmentation and reassembly should be 146 avoided whenever possible. Ideal solutions for avoiding 147 fragmentation include proper configuration and management of MTU 148 sizes between the CE, PE and across the PSN, as well as adaptive 149 measures which operate with the originating host [e.g. [PATHMTU], 150 [PATHMTUv6]] to reduce the packet sizes at the source. 152 A PE MAY choose to fragment a packet before allowing it to enter a 153 PW. For example, if an IP packet arrives from a CE with an MTU 154 which will yield a PW packet which is greater than the PW MTU, the 155 PE may perform IP fragmentation on the packet. This effectively 156 creates two (or more) packets, each carrying an IP fragment, for 157 transport individually across the PW. The receiving PE is unaware 158 that the originating host did not perform the IP fragmentation, and 159 as such does not treat the PW packets in any special way. This 160 ultimately has the affect of placing the burden of fragmentation on 161 the PE, and reassembly on the IP destination host. 163 3. PWE3 Fragmentation With MPLS 165 When using the signaling procedures in [MPLS-TRANS], there is a 166 Virtual Circuit FEC element parameter ID used to signal the use of 167 fragmentation when advertising a VC label: 169 Parameter ID Length Description 170 0x09 2 Fragmentation indicator 172 The presence of this parameter ID in the VC FEC element indicates 173 that the receiver is able to reassemble fragments when the control 174 word is in use for the VC label being advertised. It does not 175 obligate the sender to use fragmentation; it is simply an 176 indication that the sender MAY use fragmentation. The sender MUST 177 NOT use fragmentation if this parameter ID is not present in the VC 178 FEC element. 180 If [MPLS-TRANS] signaling is not in use, then whether or not to use 181 fragmentation MUST be provisioned in the sender. 183 3.1 Fragment Bit Locations For MPLS 185 MPLS-based PWE3 [MPLS-ATM], [MPLS-Ethernet], [MPLS-FR], [MPLS- 186 SATOP] uses the following control word format, with the B and E 187 fragmentation bits identified in position 8 and 9: 189 PWE3 Fragmentation and Reassembly February 2004 191 0 1 2 3 192 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 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Rsvd | Flags |B|E| Length | Sequence Number | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 Figure 3: MPLS PWE3 Control Word 199 The B and E bits are defined as follows: 201 BE 202 -- 203 00 indicates that the entire (un-fragmented) payload is carried 204 in a single packet 205 01 indicates the packet carrying the first fragment 206 10 indicates the packet carrying the last fragment 207 11 indicates a packet carrying an intermediate fragment 209 See Appendix A for a discussion of the derivation of these values 210 for the B and E bits. 212 The Sequence Number field is used as already specified in the above 213 encapsulation specifications. Specifically, depending on the 214 specific encapsulation in use, the value 0 may indicate that the 215 sequence number is not in use, in which case its use for 216 fragmentation must follow this same rule - as the sequence number 217 is incremented, it skips zero and wraps from 65535 to 1. 218 Conversely, if the value 0 is part of the sequence space (as in 219 [MPLS-SATOP]), then the same sequence space is also used for 220 fragmentation and reassembly. Since a sequence number is necessary 221 for the fragmentation and reassembly procedures, using the Sequence 222 Number field on fragmented packets is REQUIRED. 224 3.2 Other Considerations 226 Path MTU [PATHMTU] [PATHMTUv6] may be used to dynamically determine 227 the maximum size for fragments. The application of path MTU to MPLS 228 is discussed in [LABELSTACK]. The maximum size of the fragments may 229 also be provisioned. The signaled Interface MTU parameter in [MPLS- 230 TRANS] SHOULD be used to set the maximum size of the reassembly 231 buffer for received packets to make optimal use of reassembly 232 buffer resources. 234 4. PWE3 Fragmentation With L2TP 236 This section defines the location of the B and E bits for L2TPv3 237 [L2TPv3] and L2TPv2 [L2TPv2] headers, as well as the signaling 238 PWE3 Fragmentation and Reassembly February 2004 240 mechanism for advertising MRU (Maximum Receive Unit) values and 241 support for fragmentation on a given PW. As IP is the most common 242 PSN used with L2TP, IP fragmentation and reassembly is discussed as 243 well. 245 4.1 PW-specific Fragmentation vs. IP fragmentation 247 L2TPv3 recognizes that when it is used over IP networks, it may be 248 subject to IP fragmentation. The following is quoted from 249 [L2TPv3]: 251 IP fragmentation may occur as the L2TP packet travels over the 252 IP substrate. L2TP makes no special efforts defined in this 253 document to optimize this. 255 When proper MTU management across a network fails, IP fragmentation 256 and reassembly may be used to accommodate MTU mismatches between 257 tunnel endpoints. If the overall traffic requiring fragmentation 258 and reassembly is very light, or there are sufficient optimized 259 mechanisms for IP fragmentation and reassembly available, IP 260 fragmentation and reassembly may be sufficient and is allowed, 261 particularly if PW-specific fragmentation is unavailable. 263 When facing a large number of PW packets requiring fragmentation 264 and reassembly, a PW-specific method has properties that allow for 265 more resource-friendly implementations. Specifically, the ability 266 to assign buffer usage on a per-PW basis and per-PW sequencing may 267 be utilized to significant advantage over a general mechanism 268 applying to all IP packets equally. Further, PW fragmentation may 269 be easily enabled in a selective manner for some or all PWs, rather 270 than enabling reassembly for all IP traffic arriving at a given 271 node. 273 Deployments MUST avoid a situation which relies upon a combination 274 of IP and PW fragmentation and reassembly on the same node. Such 275 operation clearly defeats the purpose behind the mechanism defined 276 in this document. Care must be taken to ensure that the MTU/MRU 277 values are set and advertised properly at each tunnel endpoint to 278 avoid this. When fragmentation is enabled within a given PW, the DF 279 bit MUST be set on all L2TP over IP packets for that PW. L2TPv3 280 nodes SHOULD participate in Path MTU [PATHMTU], [PATHMTUv6] for 281 automatic adjustment of the PW MTU. 283 4.2 Advertising Reassembly Support in L2TP 285 The constructs defined in this section for advertising 286 fragmentation support in L2TP are applicable to L2TPv3 and L2TPv2. 288 PWE3 Fragmentation and Reassembly February 2004 290 This document defines two new AVPs to advertise maximum receive 291 unit values and reassembly support. These AVPs MAY be present in 292 the ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, or SLI messages. The most 293 recent value received always takes precedence over a previous 294 value, and MUST be dynamic over the life of the session if received 295 via the SLI message. One of the two new AVPs (MRRU) is used to 296 advertise that PWE3 reassembly is supported by the sender of the 297 AVP. Reassembly support MAY be unidirectional. 299 4.3 L2TP Maximum Receive Unit (MRU) AVP 301 0 1 302 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | MRU | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 MRU (Maximum Receive Unit), attribute number TBD1, is the maximum 308 size in octets of a fragmented or complete PW frame, including L2TP 309 encapsulation, receivable by the side of the PW advertising this 310 value. The advertised MRU does NOT include the PSN header (i.e. the 311 IP and/or UDP header). This AVP does not imply that PWE3 312 fragmentation or reassembly is supported. If reassembly is not 313 enabled or unavailable, this AVP may be used alone to advertise the 314 MRU for a complete frame. 316 All L2TP AVPs have an M (Mandatory) bit, H (Hidden) bit, Length, 317 and Vendor ID. This AVP may be hidden (the H bit may be 0 or 1). 318 The M bit for this AVP SHOULD be set to 0. The Length (before 319 hiding) is 8. The Vendor ID is the IETF Vendor ID of 0. 321 4.4 L2TP Maximum Reassembled Receive Unit (MRRU) AVP 323 0 1 324 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | MRRU | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 MRRU (Maximum Reassembled Receive Unit AVP), attribute number TBD2, 330 is the maximum size in octets of a reassembled frame, including any 331 PW framing, but not including the L2TP encapsulation or L2-specific 332 sublayer. Presence of this AVP signifies the ability to receive PW 333 fragments and reassemble them. Packet fragments MUST NOT be sent to 334 an implementation which has not received this value from its peer 335 in a control message. If the MRRU is present in a message, the MRU 336 AVP MUST be present as well. 338 PWE3 Fragmentation and Reassembly February 2004 340 All L2TP AVPs have an M (Mandatory) bit, H (Hidden) bit, Length, 341 and Vendor ID. This AVP may be hidden (the H bit may be 0 or 1). 342 The M bit for this AVP SHOULD be set to 0. The Length (before 343 hiding) is 8. The Vendor ID is the IETF Vendor ID of 0. 345 4.5 Fragment Bit Locations For L2TPv3 Encapsulation 347 The B and E bits are defined as bits 2 and 3 in the L2TPv3 default 348 L2-specific sublayer as depicted below, using the values defined in 349 section 3.1: 351 0 1 2 3 352 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 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 |P|S|B|E|x|x|x|x| Sequence Number | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 Figure 4: L2TPv3 over IP Header 359 Location of the B and E bits for PW-Types which use a variant L2- 360 specific sublayer are outside the scope of this document. 362 Inclusion of the MRRU AVP in a control message suggests the need 363 for a control sublayer which includes sequence numbers and the B 364 and E bit fields. Thus, if reassembly support has been advertised, 365 and packet fragments are to be sent, then presence of this sublayer 366 and associated sequencing for all packet fragments MUST be enabled 367 as defined for the given PW-type. 369 4.6 Fragment Bit Locations for L2TPv2 Encapsulation 371 The B and E bits are defined as bits 8 and 9 for the L2TPv2 header 372 as depicted below (subject to IANA action), using the values 373 defined in section 3.1: 375 0 1 2 3 376 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 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 |T|L|x|x|S|x|O|P|B|E|x|x| Ver | Length (opt) | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Tunnel ID | Session ID | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Ns (opt) | Nr (opt) | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Offset Size (opt) | Offset pad... (opt) 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 Figure 5: L2TPv2 over UDP Header 389 PWE3 Fragmentation and Reassembly February 2004 391 5. Security Considerations 393 As with any additional protocol construct, each level of complexity 394 adds the potential to exploit protocol and implementation errors. 395 Implementers should be especially careful of not tying up an 396 abundance of resources, even for the most pathological combination 397 of packet fragments that could be received. Beyond these issues of 398 general implementation quality, there are no known notable security 399 issues with using the mechanism defined in this document. It 400 should be pointed out that RFC 1990, on which this document is 401 based, and its derivatives have been widely implemented and 402 extensively used in the Internet and elsewhere. 404 [IPFRAG-SEC] and [TINYFRAG] describe potential network attacks 405 associated with IP fragmentation and reassembly. The issues 406 described in these documents attempt to bypass IP access controls 407 by sending various carefully formed "tiny fragments", or by 408 exploiting the IP offset field to cause fragments to overlap and 409 rewrite interesting portions of an IP packet after access checks 410 have been performed. The latter is not an issue with the PW- 411 specific fragmentation method described in this document as there 412 is no offset field; However, implementations MUST be sure to not 413 allow more than one whole fragment to overwrite another in a 414 reconstructed frame. The former may be a concern if packet 415 filtering and access controls are being placed on tunneled frames 416 within the PW encapsulation. To circumvent any possible attacks in 417 either case, all filtering and access controls should be applied to 418 the resulting reconstructed frame rather than any PW fragments. 420 6. IANA Considerations 422 This document does not define any new values for IANA to maintain. 424 This document requires definition of two reserved bits in the 425 L2TPv2 [L2TPv2] header. Recommended locations are noted by the "B" 426 and "E" bits in section 5.6. 428 This document requires IANA to assign two new L2TP "Control Message 429 Attribute Value Pairs" (TBD1 and TBD2 in this document). 431 7. Acknowledgements 433 Thanks to Eric Rosen for his review of this document. 435 PWE3 Fragmentation and Reassembly February 2004 437 8. References 439 [Architecture] Bryant, S. et al, "PWE3 Architecture", draft-ietf- 440 pwe3-arch-06.txt, October 2003, work in progress 442 [FAST] ATM Forum, "Frame Based ATM over SONET/SDH Transport 443 (FAST)", af-fbatm-0151.000, July 2000 445 [FRF.12] Frame Relay Forum, "Frame Relay Fragmentation 446 Implementation Agreement", FRF.12, December 1997 448 [LABELSTACK] Rosen, E. et al, "MPLS Label Stack Encoding", RFC 449 3032, January 2001 451 [L2TPv2] Townsley, Valencia, Rubens, Pall, Zorn, Palter, "Layer Two 452 Tunneling Protocol 'L2TP'", RFC 2661, June 1999 454 [L2TPv3] Lau, J. et al, "Layer Two Tunneling Protocol (Version 3) 455 'L2TPv3'", draft-ietf-l2tpext-l2tp-base-11.txt, October 2003, 456 work in progress 458 [MLPPP] Sklower, K. et al, "The PPP Multilink Protocol (MP)", RFC 459 1990, August 1996 461 [MPLS-ATM] Martini, L. et al, "Encapsulation Methods for Transport 462 of ATM Cells/Frame Over IP and MPLS Networks", draft-ietf-pwe3- 463 atm-encap-04.txt, December 2003, work in progress 465 [MPLS-Ethernet] Martini, L. et al, "Encapsulation Methods for 466 Transport of Ethernet Frames Over IP and MPLS Networks", draft- 467 ietf-pwe3-ethernet-encap-05.txt, December 2003, work in 468 progress 470 [MPLS-FR] Martini, L. et al, "Frame Relay Encapsulation over 471 Pseudo-Wires", draft-ietf-pwe3-frame-relay-02.txt, February 472 2004, work in progress 474 [MPLS-SATOP] Vainshtein, A. et al, "Structure-Agnostic TDM over 475 Packet (SAToP)", draft-ietf-pwe3-satop-01.txt, December 2003, 476 work in progress 478 [MPLS-TRANS] Martini, L. et al, "Transport of Layer 2 Frames Over 479 MPLS", draft-ietf-pwe3-control-protocol-05.txt, December 2003, 480 work in progress 482 [PATHMTU] Mogul, J. C. et al, "Path MTU Discovery", RFC 1191, 483 November 1990 484 PWE3 Fragmentation and Reassembly February 2004 486 [PATHMTUv6] McCann, J. et al, "Path MTU Discovery for IP version 487 6", RFC 1981, August 1996 489 [IPFRAG-SEC] Ziemba, G., Reed, D., Traina, P., "Security 490 Considerations for IP Fragment Filtering", RFC 1858, October 491 1995 493 [TINYFRAG] Miller, I., "Protection Against a Variant of the Tiny 494 Fragment Attack", RFC 3128, June 2001 496 9. Authors' Addresses 498 Andrew G. Malis 499 Tellabs 500 90 Rio Robles Drive 501 San Jose, CA 95134 502 Email: Andy.Malis@tellabs.com 504 W. Mark Townsley 505 Cisco Systems 506 7025 Kit Creek Road 507 PO Box 14987 508 Research Triangle Park, NC 27709 509 Email: mark@townsley.net 511 10. Appendix A: Relationship Between This Document and RFC 1990 513 The fragmentation of large packets into smaller units for 514 transmission is not new. One fragmentation and reassembly method 515 was defined in RFC 1990, Multi-Link PPP [MLPPP]. This method was 516 also adopted for both Frame Relay [FRF.12] and ATM [FAST] network 517 technology. This document adopts the RFC 1990 fragmentation and 518 reassembly procedures as well, with some distinct modifications 519 described in this appendix. Familiarity with RFC 1990 is assumed. 521 RFC 1990 was designed for use in environments where packet 522 fragments may arrive out of order due to their transmission on 523 multiple parallel links, specifying that buffering be used to place 524 the fragments in correct order. For PWE3, the ability to reorder 525 fragments prior to reassembly is OPTIONAL; receivers MAY choose to 526 drop frames when a lost fragment is detected. Thus, when the 527 sequence number on received fragments shows that a fragment has 528 been skipped, the partially reassembled packet MAY be dropped, or 529 the receiver MAY wish to wait for the fragment to arrive out of 530 order. In the latter case, a reassembly timer MUST be used to 531 avoid locking up buffer resources for too long a period. 533 PWE3 Fragmentation and Reassembly February 2004 535 Dropping out-of-order fragments on a given PW can provide a 536 considerable scalability advantage for network equipment performing 537 reassembly. If out-of-order fragments are a relatively rare event 538 on a given PW, throughput should not be adversely affected by this. 539 Note, however, if there are cases where fragments of a given frame 540 are received out-or-order in a consistent manner (e.g. a short 541 fragment is always switched ahead of a larger fragment) then 542 dropping out-of-order fragments will cause the fragmented frame to 543 never be received. This condition may result in an effective denial 544 of service to a higher-lever application. As such, implementations 545 fragmenting a PW frame MUST at the very least ensure that all 546 fragments are sent in order from their own egress point. 548 An implementation may also choose to allow reassembly of a limited 549 number of fragmented frames on a given PW, or across a set of PWs 550 with reassembly enabled. This allows for a more even distribution 551 of reassembly resources, reducing the chance of a single or small 552 set of PWs exhausting all reassembly resources for a node. As with 553 dropping out-of-order fragments, there are perceivable cases where 554 this may also provide an effective denial of service. For example, 555 if fragments of multiple frames are consistently received before 556 each frame can be reconstructed in a set of limited PW reassembly 557 buffers, then a set of these fragmented frames will never be 558 delivered. 560 RFC 1990 headers use two bits which indicate the first and last 561 fragments in a frame, and a sequence number. The sequence number 562 may be either 12 or 24 bits in length (from [MLPPP]): 564 0 7 8 15 565 +-+-+-+-+-------+---------------+ 566 |B|E|0|0| sequence number | 567 +-+-+-+-+-------+---------------+ 569 +-+-+-+-+-+-+-+-+---------------+ 570 |B|E|0|0|0|0|0|0|sequence number| 571 +-+-+-+-+-+-+-+-+---------------+ 572 | sequence number (L) | 573 +---------------+---------------+ 575 Figure 6: RFC 1990 Header Formats 577 PWE3 fragmentation takes advantage of existing PW sequence numbers 578 and control bit fields wherever possible, rather than defining a 579 separate header exclusively for the use of fragmentation. Thus, it 580 uses neither of the RFC 1990 sequence number formats described 581 above, relying instead on the sequence number that already exists 582 in the PWE3 header. 584 PWE3 Fragmentation and Reassembly February 2004 586 RFC 1990 defines a two one-bit fields, a (B)eginning fragment bit 587 and an (E)nding fragment bit. The B bit is set to 1 on the first 588 fragment derived from a PPP packet and set to 0 for all other 589 fragments from the same PPP packet. The E bit is set to 1 on the 590 last fragment and set to 0 for all other fragments. A complete 591 unfragmented frame has both the B and E bits set to 1. 593 PWE3 fragmentation inverts the value of the B and E bits, while 594 retaining the operational concept of marking the beginning and 595 ending of a fragmented frame. Thus, for PW the B bit is set to 0 on 596 the first fragment derived from a PW frame and set to 1 for all 597 other fragments derived from the same frame. The E bit is set to 0 598 on the last fragment and set to 1 for all other fragments. A 599 complete unfragmented frame has both the B and E bits set to 0. The 600 motivation behind this value inversion for the B and E bits is to 601 allow complete frames (and particularly, implementations that only 602 support complete frames) to simply leave the B and E bits in the 603 header set 0. 605 In order to support fragmentation, the B and E bits MUST be defined 606 or identified for all PWE3 tunneling protocols. Sections 3 and 4 607 define these locations for PWE3 MPLS [MPLS-TRANS], L2TPv2 [L2TPv2], 608 and L2TPv3 [L2TPv3] tunneling protocols.