diff options
Diffstat (limited to 'doc/rfc/rfc4623.txt')
| -rw-r--r-- | doc/rfc/rfc4623.txt | 955 |
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc4623.txt b/doc/rfc/rfc4623.txt new file mode 100644 index 0000000..c561370 --- /dev/null +++ b/doc/rfc/rfc4623.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group A. Malis +Request for Comments: 4623 Tellabs +Category: Standards Track M. Townsley + Cisco Systems + August 2006 + + + Pseudowire Emulation Edge-to-Edge (PWE3) + Fragmentation and Reassembly + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document defines a generalized method of performing + fragmentation for use by Pseudowire Emulation Edge-to-Edge (PWE3) + protocols and services. + + + + + + + + + + + + + + + + + + + + + + + + +Malis & Townsley Standards Track [Page 1] + +RFC 4623 PWE3 Fragmentation and Reassembly August 2006 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Conventions Used in This Document ...............................4 + 3. Alternatives to PWE3 Fragmentation/Reassembly ...................5 + 4. PWE3 Fragmentation with MPLS ....................................5 + 4.1. Fragment Bit Locations for MPLS ............................6 + 4.2. Other Considerations .......................................6 + 5. PWE3 Fragmentation with L2TP ....................................6 + 5.1. PW-Specific Fragmentation vs. IP fragmentation .............7 + 5.2. Advertising Reassembly Support in L2TP .....................7 + 5.3. L2TP Maximum Receive Unit (MRU) AVP ........................8 + 5.4. L2TP Maximum Reassembled Receive Unit (MRRU) AVP ...........8 + 5.5. Fragment Bit Locations for L2TPv3 Encapsulation ............9 + 5.6. Fragment Bit Locations for L2TPv2 Encapsulation ............9 + 6. Security Considerations ........................................10 + 7. IANA Considerations ............................................10 + 7.1. Control Message Attribute Value Pairs (AVPs) ..............11 + 7.2. Default L2-Specific Sublayer Bits .........................11 + 7.3. Leading Bits of the L2TPv2 Message Header .................11 + 8. Acknowledgements ...............................................11 + 9. Normative References ...........................................12 + 10. Informative References ........................................12 + Appendix A. Relationship Between This Document and RFC 1990 .......14 + + + + + + + + + + + + + + + + + + + + + + + + + + + +Malis & Townsley Standards Track [Page 2] + +RFC 4623 PWE3 Fragmentation and Reassembly August 2006 + + +1. Introduction + + The Pseudowire Emulation Edge-to-Edge Architecture Document + [Architecture] defines a network reference model for PWE3: + + |<-------------- Emulated Service ---------------->| + | | + | |<------- Pseudowire ------->| | + | | | | + | | |<-- PSN Tunnel -->| | | + | PW End V V V V PW End | + V Service +----+ +----+ Service V + +-----+ | | PE1|==================| PE2| | +-----+ + | |----------|............PW1.............|----------| | + | CE1 | | | | | | | | CE2 | + | |----------|............PW2.............|----------| | + +-----+ ^ | | |==================| | | ^ +-----+ + ^ | +----+ +----+ | | ^ + | | Provider Edge 1 Provider Edge 2 | | + | | | | + Customer | | Customer + Edge 1 | | Edge 2 + | | + | | + native service native service + + Figure 1: PWE3 Network Reference Model + + A Pseudowire (PW) payload is normally relayed across the PW as a + single IP or MPLS Packet Switched Network (PSN) Protocol Data Unit + (PDU). However, there are cases where the combined size of the + payload and its associated PWE3 and PSN headers may exceed the PSN + path Maximum Transmission Unit (MTU). When a packet exceeds the MTU + of a given network, fragmentation and reassembly will allow the + packet to traverse the network and reach its intended destination. + + The purpose of this document is to define a generalized method of + performing fragmentation for use with all PWE3 protocols and + services. This method should be utilized only in cases where MTU- + management methods fail. Due to the increased processing overhead, + fragmentation and reassembly in core network devices should always be + considered something to avoid whenever possible. + + The PWE3 fragmentation and reassembly domain is shown in Figure 2: + + + + + + + +Malis & Townsley Standards Track [Page 3] + +RFC 4623 PWE3 Fragmentation and Reassembly August 2006 + + + |<-------------- Emulated Service ---------------->| + | |<---Fragmentation Domain--->| | + | ||<------- Pseudowire ----->|| | + | || || | + | || |<-- PSN Tunnel -->| || | + | PW End VV V V VV PW End | + V Service +----+ +----+ Service V + +-----+ | | PE1|==================| PE2| | +-----+ + | |----------|............PW1.............|----------| | + | CE1 | | | | | | | | CE2 | + | |----------|............PW2.............|----------| | + +-----+ ^ | | |==================| | | ^ +-----+ + ^ | +----+ +----+ | | ^ + | | Provider Edge 1 Provider Edge 2 | | + | | | | + Customer | | Customer + Edge 1 | | Edge 2 + | | + | | + native service native service + + Figure 2: PWE3 Fragmentation/Reassembly Domain + + Fragmentation takes place in the transmitting PE immediately prior to + PW encapsulation, and reassembly takes place in the receiving PE + immediately after PW decapsulation. + + Since a sequence number is necessary for the fragmentation and + reassembly procedures, using the Sequence Number field on fragmented + packets is REQUIRED (see Sections 4.1 and 5.5 for the location of the + Sequence Number fields for MPLS and L2TPv3 encapsulations, + respectively). The order of operation is that first fragmentation is + performed, and then the resulting fragments are assigned sequential + sequence numbers. + + Depending on the specific PWE3 encapsulation in use, the value 0 may + not be a part of the sequence number space, in which case its use for + fragmentation must follow this same rule: as the sequence number is + incremented, it skips zero and wraps from 65535 to 1. Conversely, if + the value 0 is part of the sequence space, then the same sequence + space is also used for fragmentation and reassembly. + +2. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [KEYWORDS]. + + + + +Malis & Townsley Standards Track [Page 4] + +RFC 4623 PWE3 Fragmentation and Reassembly August 2006 + + +3. Alternatives to PWE3 Fragmentation/Reassembly + + Fragmentation and reassembly in network equipment generally requires + significantly greater resources than sending a packet as a single + unit. As such, fragmentation and reassembly should be avoided + whenever possible. Ideal solutions for avoiding fragmentation + include proper configuration and management of MTU sizes between the + Customer Edge (CE) router and Provider Edge (PE) router and across + the PSN, as well as adaptive measures that operate with the + originating host (e.g., [PATHMTU], [PATHMTUv6]) to reduce the packet + sizes at the source. + + In some cases, a PE may be able to fragment an IP version 4 (IPv4) + [RFC791] packet before it enters a PW. For example, if the PE can + fragment and forward IPv4 packets with the DF bit clear in a manner + that is identical to an IPv4 router, it may fragment packets arriving + from a CE, forwarding the IPv4 fragments with associated framing for + that attachment circuit (AC) over the PW. Architecturally, the IPv4 + fragmentation happens before reaching the PW, presenting multiple + frames to the PW to forward in the normal manner for that PWType. + Thus, this method is entirely transparent to the PW encapsulation and + to the remote end of the PW itself. Packet fragments are ultimately + reassembled on the destination IPv4 host in the normal way. IPv6 + packets are not to be fragmented in this manner. + +4. PWE3 Fragmentation with MPLS + + When using the signaling procedures in [MPLS-Control], there is a + Pseudowire Interface Parameter Sub-TLV type used to signal the use of + fragmentation when advertising a VC label [IANA]: + + Parameter Length Description + 0x09 4 Fragmentation indicator + + The presence of this parameter in the VC FEC element indicates that + the receiver is able to reassemble fragments when the control word is + in use for the VC label being advertised. It does not obligate the + sender to use fragmentation; it is simply an indication that the + sender MAY use fragmentation. The sender MUST NOT use fragmentation + if this parameter is not present in the VC FEC element. + + If [MPLS-Control] signaling is not in use, then whether or not to use + fragmentation MUST be configured in the sender. + + + + + + + + +Malis & Townsley Standards Track [Page 5] + +RFC 4623 PWE3 Fragmentation and Reassembly August 2006 + + +4.1. Fragment Bit Locations for MPLS + + MPLS-based PWE3 uses the following control word format + [Control-Word], with the B and E fragmentation bits identified in + position 8 and 9: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0| Flags |B|E| Length | Sequence Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: Preferred PW MPLS Control Word + + The B and E bits are defined as follows: + + BE + -- + 00 indicates that the entire (un-fragmented) payload is carried + in a single packet + 01 indicates the packet carrying the first fragment + 10 indicates the packet carrying the last fragment + 11 indicates a packet carrying an intermediate fragment + + See Appendix A for a discussion of the derivation of these values for + the B and E bits. + + See Section 1 for the description of the use of the Sequence Number + field. + +4.2. Other Considerations + + Path MTU [PATHMTU] [PATHMTUv6] may be used to dynamically determine + the maximum size for fragments. The application of path MTU to MPLS + is discussed in [LABELSTACK]. The maximum size of the fragments may + also be configured. The signaled Interface MTU parameter in + [MPLS-Control] SHOULD be used to set the maximum size of the + reassembly buffer for received packets to make optimal use of + reassembly buffer resources. + +5. PWE3 Fragmentation with L2TP + + This section defines the location of the B and E bits for L2TPv3 + [L2TPv3] and L2TPv2 [L2TPv2] headers, as well as the signaling + mechanism for advertising MRU (Maximum Receive Unit) values and + support for fragmentation on a given PW. As IP is the most common + PSN used with L2TP, IP PSN fragmentation and reassembly is discussed + as well. + + + +Malis & Townsley Standards Track [Page 6] + +RFC 4623 PWE3 Fragmentation and Reassembly August 2006 + + +5.1. PW-Specific Fragmentation vs. IP fragmentation + + When proper MTU management across a network fails, IP PSN + fragmentation and reassembly may be used to accommodate MTU + mismatches between tunnel endpoints. If the overall traffic + requiring fragmentation and reassembly is very light, or there are + sufficient optimized mechanisms for IP PSN fragmentation and + reassembly available, IP PSN fragmentation and reassembly may be + sufficient. + + When facing a large number of PW packets requiring fragmentation and + reassembly, a PW-specific method has properties that potentially + allow for more resource-friendly implementations. Specifically, the + ability to assign buffer usage on a per-PW basis and PW sequencing + may be utilized to gain advantage over a general mechanism applying + to all IP packets across all PWs. Further, PW fragmentation may be + more easily enabled in a selective manner for some or all PWs, rather + than enabling reassembly for all IP traffic arriving at a given node. + + Deployments SHOULD avoid a situation that uses a combination of IP + PSN and PW fragmentation and reassembly on the same node. Such + operation clearly defeats the purpose behind the mechanism defined in + this document. This is especially important for L2TPv3 pseudowires, + since potentially fragmentation can take place in three different + places (the IP PSN, the PW, and the encapsulated payload). Care must + be taken to ensure that the MTU/MRU values are set and advertised + properly at each tunnel endpoint to avoid this. When fragmentation + is enabled within a given PW, the DF bit MUST be set on all L2TP over + IP packets for that PW. + + L2TPv3 nodes SHOULD participate in Path MTU ([PATHMTU], [PATHMTUv6]) + for automatic adjustment of the PSN MTU. When the payload is IP, + Path MTU should be used at they payload level as well. + +5.2. Advertising Reassembly Support in L2TP + + The constructs defined in this section for advertising fragmentation + support in L2TP are applicable to [L2TPv3] and [L2TPv2]. + + This document defines two new AVPs to advertise maximum receive unit + values and reassembly support. These AVPs MAY be present in the + Incoming-Call-Request (ICRQ), Incoming-Call-Reply (ICRP), Incoming- + Call-Connected (ICCN), Outgoing-Call-Request (OCRQ), Outgoing-Call- + Reply (OCRP), Outgoing-Call-Connected (OCCN), or Set-Link-Info (SLI) + messages. The most recent value received always takes precedence + over a previous value and MUST be dynamic over the life of the + + + + + +Malis & Townsley Standards Track [Page 7] + +RFC 4623 PWE3 Fragmentation and Reassembly August 2006 + + + session if received via the SLI message. One of the two new AVPs + (MRRU) is used to advertise that PWE3 reassembly is supported by the + sender of the AVP. Reassembly support MAY be unidirectional. + +5.3. L2TP Maximum Receive Unit (MRU) AVP + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |M|H|0|0|0|0| Length | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MRU | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4: L2TP Maximum Receive Unit (MRU) AVP + + MRU (Maximum Receive Unit), attribute number 94, is the maximum size, + in octets, of a fragmented or complete PW frame, including L2TP + encapsulation, receivable by the side of the PW advertising this + value. The advertised MRU does NOT include the PSN header (i.e., the + IP and/or UDP header). This AVP does not imply that PWE3 + fragmentation or reassembly is supported. If reassembly is not + enabled or unavailable, this AVP may be used alone to advertise the + MRU for a complete frame. + + This AVP MAY be hidden (the H bit MAY be 0 or 1). The mandatory (M) + bit for this AVP SHOULD be set to 0. The Length (before hiding) is + 8. The Vendor ID is the IETF Vendor ID of 0. + +5.4. L2TP Maximum Reassembled Receive Unit (MRRU) AVP + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |M|H|0|0|0|0| Length | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MRRU | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: L2TP Maximum Reassembled Receive Unit (MRRU) AVP + + MRRU (Maximum Reassembled Receive Unit AVP), attribute number 95, is + the maximum size, in octets, of a reassembled frame, including any PW + framing, but not including the L2TP encapsulation or L2-specific + sublayer. Presence of this AVP signifies the ability to receive PW + fragments and reassemble them. Packet fragments MUST NOT be sent by + a peer that has not received this AVP in a control message. If the + MRRU is present in a message, the MRU AVP MUST be present as well. + + + +Malis & Townsley Standards Track [Page 8] + +RFC 4623 PWE3 Fragmentation and Reassembly August 2006 + + + The MRRU SHOULD be used to set the maximum size of the reassembly + buffer for received packets to make optimal use of reassembly buffer + resources. + + This AVP MAY be hidden (the H bit MAY be 0 or 1). The mandatory (M) + bit for this AVP SHOULD be set to 0. The Length (before hiding) is + 8. The Vendor ID is the IETF Vendor ID of 0. + +5.5. Fragment Bit Locations for L2TPv3 Encapsulation + + The usage of the B and E bits is described in Section 4.1. For + L2TPv3 encapsulation, the B and E bits are defined as bits 2 and 3 in + the leading bits of the Default L2-Specific Sublayer (see Section 7). + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |M|H|0|0|0|0| Length | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|S|B|E|x|x|x|x| Sequence Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 6: B and E Bits Location in the Default L2-Specific Sublayer + + The S (Sequence) bit is as defined in [L2TPv3]. Location of the B + and E bits for PW-Types that use a variant L2 specific sublayer are + outside the scope of this document. + + When fragmentation is used, an L2-Specific Sublayer with B and E bits + defined MUST be present in all data packets for a given session. The + presence and format of the L2-Specific Sublayer is advertised via the + L2-Specific Sublayer AVP, Attribute Type 69, defined in Section 5.4.4 + of [L2TPv3]. + + See Section 1 for the description of the use of the Sequence Number + field. + +5.6. Fragment Bit Locations for L2TPv2 Encapsulation + + The usage of the B and E bits is described in Section 4.1. For + L2TPv2 encapsulation, the B and E bits are defined as bits 8 and 9 in + the leading bits of the L2TPv2 header as depicted below (see Section + 7). + + + + + + + + +Malis & Townsley Standards Track [Page 9] + +RFC 4623 PWE3 Fragmentation and Reassembly August 2006 + + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |M|H|0|0|0|0| Length | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |T|L|x|x|S|x|O|P|B|E|x|x| Ver | Length (opt) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 7: B and E bits location in the L2TPv2 Message Header + +6. Security Considerations + + As with any additional protocol construct, each level of complexity + adds the potential to exploit protocol and implementation errors. + Implementers should be especially careful of not tying up an + abundance of resources, even for the most pathological combination of + packet fragments that could be received. Beyond these issues of + general implementation quality, there are no known notable security + issues with using the mechanism defined in this document. It should + be pointed out that RFC 1990, on which this document is based, and + its derivatives have been widely implemented and extensively used in + the Internet and elsewhere. + + [IPFRAG-SEC] and [TINYFRAG] describe potential network attacks + associated with IP fragmentation and reassembly. The issues + described in these documents attempt to bypass IP access controls by + sending various carefully formed "tiny fragments", or by exploiting + the IP offset field to cause fragments to overlap and rewrite + interesting portions of an IP packet after access checks have been + performed. The latter is not an issue with the PW-specific + fragmentation method described in this document, as there is no + offset field. However, implementations MUST be sure not to allow + more than one whole fragment to overwrite another in a reconstructed + frame. The former may be a concern if packet filtering and access + controls are being placed on tunneled frames within the PW + encapsulation. To circumvent any possible attacks in either case, + all filtering and access controls should be applied to the resulting + reconstructed frame rather than any PW fragments. + +7. IANA Considerations + + This document does not define any new registries for IANA to + maintain. + + Note that [IANA] has already allocated the Fragmentation Indicator + interface parameter, so no further IANA action is required. + + + + + +Malis & Townsley Standards Track [Page 10] + +RFC 4623 PWE3 Fragmentation and Reassembly August 2006 + + + This document requires IANA to assign new values for registries + already managed by IANA (see Sections 7.1 and 7.2) and two reserved + bits in an existing header (see Section 7.3). + +7.1. Control Message Attribute Value Pairs (AVPs) + + Two additional AVP Attributes are specified in Sections 5.3 and 5.4. + They are required to be defined by IANA as described in Section 2.2 + of [BCP0068]. + + Control Message Attribute Value Pairs + ------------------------------------- + + 94 - Maximum Receive Unit (MRU) AVP + 95 - Maximum Reassembled Receive Unit (MRRU) AVP + +7.2. Default L2-Specific Sublayer Bits + + This registry was created as part of the publication of [L2TPv3]. + This document defines two reserved bits in the Default L2-Specific + Sublayer in Section 5.5, which may be assigned by IETF Consensus + [RFC2434]. They are required to be assigned by IANA. + + Default L2-Specific Sublayer bits - per [L2TPv3] + --------------------------------- + + Bit 2 - B (Fragmentation) bit + Bit 3 - E (Fragmentation) bit + +7.3. Leading Bits of the L2TPv2 Message Header + + This document requires definition of two reserved bits in the L2TPv2 + [L2TPv2] header. Locations are noted by the "B" and "E" bits in + Section 5.6. + + Leading Bits of the L2TPv2 Message Header - per [L2TPv2, L2TPv3] + ----------------------------------------- + + Bit 8 - B (Fragmentation) bit + Bit 9 - E (Fragmentation) bit + +8. Acknowledgements + + The authors wish to thank Eric Rosen and Carlos Pignataro, both of + Cisco Systems, for their review of this document. + + + + + + +Malis & Townsley Standards Track [Page 11] + +RFC 4623 PWE3 Fragmentation and Reassembly August 2006 + + +9. Normative References + + [Control-Word] Bryant, S., Swallow, G., Martini, L., and D. + McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) + Control Word for Use over an MPLS PSN", RFC 4385, + February 2006. + + [IANA] Martini, L., "IANA Allocations for Pseudowire Edge to + Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [LABELSTACK] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., + Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack + Encoding", RFC 3032, January 2001. + + [L2TPv2] Townsley, W., Valencia, A., Rubens, A., Pall, G., + Zorn, G., and B. Palter, "Layer Two Tunneling Protocol + "L2TP"", RFC 2661, August 1999. + + [L2TPv3] Lau, J., Townsley, M., and I. Goyret, "Layer Two + Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, + March 2005. + + [MLPPP] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. + Coradetti, "The PPP Multilink Protocol (MP)", RFC + 1990, August 1996. + + [MPLS-Control] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and + G. Heron, "Pseudowire Setup and Maintenance Using the + Label Distribution Protocol (LDP)", RFC 4447, April + 2006. + + [PATHMTU] Mogul, J. and S. Deering, "Path MTU discovery", RFC + 1191, November 1990. + + [PATHMTUv6] McCann, J., Deering, S., and J. Mogul, "Path MTU + Discovery for IP version 6", RFC 1981, August 1996. + +10. Informative References + + [Architecture] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge- + to-Edge (PWE3) Architecture", RFC 3985, March 2005. + + + + + + + +Malis & Townsley Standards Track [Page 12] + +RFC 4623 PWE3 Fragmentation and Reassembly August 2006 + + + [BCP0068] Townsley, W., "Layer Two Tunneling Protocol (L2TP) + Internet Assigned Numbers Authority (IANA) + Considerations Update", BCP 68, RFC 3438, December + 2002. + + [FAST] ATM Forum, "Frame Based ATM over SONET/SDH Transport + (FAST)", af-fbatm-0151.000, July 2000. + + [FRF.12] Frame Relay Forum, "Frame Relay Fragmentation + Implementation Agreement", FRF.12, December 1997. + + [IPFRAG-SEC] Ziemba, G., Reed, D., and P. Traina, "Security + Considerations for IP Fragment Filtering", RFC 1858, + October 1995. + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing + an IANA Considerations Section in RFCs", BCP 26, RFC + 2434, October 1998. + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [TINYFRAG] Miller, I., "Protection Against a Variant of the Tiny + Fragment Attack (RFC 1858)", RFC 3128, June 2001. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Malis & Townsley Standards Track [Page 13] + +RFC 4623 PWE3 Fragmentation and Reassembly August 2006 + + +Appendix A. Relationship between This Document and RFC 1990 + + The fragmentation of large packets into smaller units for + transmission is not new. One fragmentation and reassembly method was + defined in RFC 1990, Multi-Link PPP [MLPPP]. This method was also + adopted for both Frame Relay [FRF.12] and ATM [FAST] network + technology. This document adopts the RFC 1990 fragmentation and + reassembly procedures as well, with some distinct modifications + described in this appendix. Familiarity with RFC 1990 is assumed. + + RFC 1990 was designed for use in environments where packet fragments + may arrive out of order due to their transmission on multiple + parallel links, specifying that buffering be used to place the + fragments in correct order. For PWE3, the ability to reorder + fragments prior to reassembly is OPTIONAL; receivers MAY choose to + drop frames when a lost fragment is detected. Thus, when the sequence + number on received fragments shows that a fragment has been skipped, + the partially reassembled packet MAY be dropped, or the receiver MAY + wish to wait for the fragment to arrive out of order. In the latter + case, a reassembly timer MUST be used to avoid locking up buffer + resources for too long a period. + + Dropping out-of-order fragments on a given PW can provide a + considerable scalability advantage for network equipment performing + reassembly. If out-of-order fragments are a relatively rare event on + a given PW, throughput should not be adversely affected by this. + Note, however, if there are cases where fragments of a given frame + are received out-or-order in a consistent manner (e.g., a short + fragment is always switched ahead of a larger fragment), then + dropping out-of-order fragments will cause the fragmented frame never + to be received. This condition may result in an effective denial of + service to a higher-lever application. As such, implementations + fragmenting a PW frame MUST at the very least ensure that all + fragments are sent in order from their own egress point. + + An implementation may also choose to allow reassembly of a limited + number of fragmented frames on a given PW, or across a set of PWs + with reassembly enabled. This allows for a more even distribution of + reassembly resources, reducing the chance that a single or small set + of PWs will exhaust all reassembly resources for a node. As with + dropping out-of-order fragments, there are perceivable cases where + this may also provide an effective denial of service. For example, + if fragments of multiple frames are consistently received before each + frame can be reconstructed in a set of limited PW reassembly buffers, + then a set of these fragmented frames will never be delivered. + + + + + + +Malis & Townsley Standards Track [Page 14] + +RFC 4623 PWE3 Fragmentation and Reassembly August 2006 + + + RFC 1990 headers use two bits that indicate the first and last + fragments in a frame, and a sequence number. The sequence number may + be either 12 or 24 bits in length (from [MLPPP]): + + 0 7 8 15 + +-+-+-+-+-------+---------------+ + |B|E|0|0| sequence number | + +-+-+-+-+-------+---------------+ + + +-+-+-+-+-+-+-+-+---------------+ + |B|E|0|0|0|0|0|0|sequence number| + +-+-+-+-+-+-+-+-+---------------+ + | sequence number (L) | + +---------------+---------------+ + + Figure 6: RFC 1990 Header Formats + + PWE3 fragmentation takes advantage of existing PW sequence numbers + and control bit fields wherever possible, rather than defining a + separate header exclusively for the use of fragmentation. Thus, it + uses neither of the RFC 1990 sequence number formats described above, + relying instead on the sequence number that already exists in the + PWE3 header. + + RFC 1990 defines two one-bit fields: a (B)eginning fragment bit and + an (E)nding fragment bit. The B bit is set to 1 on the first + fragment derived from a PPP packet and set to 0 for all other + fragments from the same PPP packet. The E bit is set to 1 on the + last fragment and set to 0 for all other fragments. A complete + unfragmented frame has both the B and E bits set to 1. + + PWE3 fragmentation inverts the value of the B and E bits, while + retaining the operational concept of marking the beginning and ending + of a fragmented frame. Thus, for PW the B bit is set to 0 on the + first fragment derived from a PW frame and set to 1 for all other + fragments derived from the same frame. The E bit is set to 0 on the + last fragment and set to 1 for all other fragments. A complete + unfragmented frame has both the B and E bits set to 0. The + motivation behind this value inversion for the B and E bits is to + allow complete frames (and particularly, implementations that only + support complete frames) simply to leave the B and E bits in the + header set to 0. + + In order to support fragmentation, the B and E bits MUST be defined + or identified for all PWE3 tunneling protocols. Sections 4 and 5 + define these locations for PWE3 MPLS [Control-Word], L2TPv2 [L2TPv2], + and L2TPv3 [L2TPv3] tunneling protocols. + + + + +Malis & Townsley Standards Track [Page 15] + +RFC 4623 PWE3 Fragmentation and Reassembly August 2006 + + +Authors' Addresses + + Andrew G. Malis + Tellabs + 1415 West Diehl Road + Naperville, IL 60563 + + EMail: Andy.Malis@tellabs.com + + + W. Mark Townsley + Cisco Systems + 7025 Kit Creek Road + PO Box 14987 + Research Triangle Park, NC 27709 + + EMail: mark@townsley.net + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Malis & Townsley Standards Track [Page 16] + +RFC 4623 PWE3 Fragmentation and Reassembly August 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Malis & Townsley Standards Track [Page 17] + |