< draft-ietf-pwe3-fragmentation-09.txt   draft-ietf-pwe3-fragmentation-10.txt >
Internet Draft Andrew G. Malis Internet Draft Andrew G. Malis
Document: draft-ietf-pwe3-fragmentation-09.txt Tellabs Document: draft-ietf-pwe3-fragmentation-10.txt Tellabs
Expires: March 2006 W. Mark Townsley Expires: May 2006 W. Mark Townsley
Cisco Systems Cisco Systems
September 2005 November 2005
PWE3 Fragmentation and Reassembly PWE3 Fragmentation and Reassembly
IPR Statement IPR Statement
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Table of Contents Table of Contents
1. Intellectual Property Statement...............................2 1. Intellectual Property Statement...............................2
2. Overview......................................................3 2. Overview......................................................3
3. Alternatives to PWE3 Fragmentation/Reassembly.................5 3. Alternatives to PWE3 Fragmentation/Reassembly.................5
4. PWE3 Fragmentation With MPLS..................................5 4. PWE3 Fragmentation With MPLS..................................5
4.1 Fragment Bit Locations For MPLS...........................6 4.1 Fragment Bit Locations For MPLS...........................6
4.2 Other Considerations......................................6 4.2 Other Considerations......................................6
5. PWE3 Fragmentation With L2TP..................................6 5. PWE3 Fragmentation With L2TP..................................6
5.1 PW-specific Fragmentation vs. IP fragmentation............7 5.1 PW-specific Fragmentation vs. IP fragmentation............7
PWE3 Fragmentation and Reassembly September 2005 PWE3 Fragmentation and Reassembly November 2005
5.2 Advertising Reassembly Support in L2TP....................7 5.2 Advertising Reassembly Support in L2TP....................7
5.3 L2TP Maximum Receive Unit (MRU) AVP.......................8 5.3 L2TP Maximum Receive Unit (MRU) AVP.......................8
5.4 L2TP Maximum Reassembled Receive Unit (MRRU) AVP..........8 5.4 L2TP Maximum Reassembled Receive Unit (MRRU) AVP..........8
5.5 Fragment Bit Locations For L2TPv3 Encapsulation...........9 5.5 Fragment Bit Locations For L2TPv3 Encapsulation...........9
5.6 Fragment Bit Locations for L2TPv2 Encapsulation...........9 5.6 Fragment Bit Locations for L2TPv2 Encapsulation...........9
6. Security Considerations.......................................9 6. Security Considerations.......................................9
7. IANA Considerations..........................................10 7. IANA Considerations..........................................10
7.1 Control Message Attribute Value Pairs (AVPs).............10 7.1 Control Message Attribute Value Pairs (AVPs).............10
7.2 Default L2-Specific Sublayer bits........................11 7.2 Default L2-Specific Sublayer bits........................11
7.3 Leading Bits of the L2TPv2 Message Header................11 7.3 Leading Bits of the L2TPv2 Message Header................11
8. Acknowledgements.............................................11 8. Acknowledgements.............................................11
9. Normative References.........................................11 9. Normative References.........................................11
10. Informative References......................................12 10. Informative References......................................12
11. Full Copyright Statement....................................12 11. Full Copyright Statement....................................13
12. Authors' Addresses..........................................13 12. Authors' Addresses..........................................13
13. Appendix A: Relationship Between This Document and RFC 1990.13 13. Appendix A: Relationship Between This Document and RFC 1990.13
1. Intellectual Property Statement 1. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79. documents can be found in BCP 78 and BCP 79.
skipping to change at page 3, line 5 skipping to change at page 3, line 5
of such proprietary rights by implementers or users of this of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
PWE3 Fragmentation and Reassembly September 2005 PWE3 Fragmentation and Reassembly November 2005
2. Overview 2. Overview
The Pseudo Wire Emulation Edge to Edge Architecture Document The Pseudo Wire Emulation Edge to Edge Architecture Document
[Architecture] defines a network reference model for PWE3: [Architecture] defines a network reference model for PWE3:
|<-------------- Emulated Service ---------------->| |<-------------- Emulated Service ---------------->|
| | | |
| |<------- Pseudo Wire ------>| | | |<------- Pseudo Wire ------>| |
| | | | | | | |
| | |<-- PSN Tunnel -->| | | | | |<-- PSN Tunnel -->| | |
| PW End V V V V PW End | | PW End V V V V PW End |
skipping to change at page 4, line 5 skipping to change at page 4, line 5
of a given network, fragmentation and reassembly will allow the of a given network, fragmentation and reassembly will allow the
packet to traverse the network and reach its intended destination. packet to traverse the network and reach its intended destination.
The purpose of this document is to define a generalized method of The purpose of this document is to define a generalized method of
performing fragmentation for use with all PWE3 protocols and performing fragmentation for use with all PWE3 protocols and
services. This method should be utilized only in cases where MTU- services. This method should be utilized only in cases where MTU-
management methods fail. Due to the increased processing overhead, management methods fail. Due to the increased processing overhead,
fragmentation and reassembly in core network devices should always fragmentation and reassembly in core network devices should always
be considered something to avoid whenever possible. be considered something to avoid whenever possible.
PWE3 Fragmentation and Reassembly September 2005 PWE3 Fragmentation and Reassembly November 2005
The PWE3 fragmentation and reassembly domain is shown in Figure 2: The PWE3 fragmentation and reassembly domain is shown in Figure 2:
|<-------------- Emulated Service ---------------->| |<-------------- Emulated Service ---------------->|
| |<---Fragmentation Domain--->| | | |<---Fragmentation Domain--->| |
| ||<------- Pseudo Wire ---->|| | | ||<------- Pseudo Wire ---->|| |
| || || | | || || |
| || |<-- PSN Tunnel -->| || | | || |<-- PSN Tunnel -->| || |
| PW End VV V V VV PW End | | PW End VV V V VV PW End |
V Service +----+ +----+ Service V V Service +----+ +----+ Service V
skipping to change at page 5, line 5 skipping to change at page 5, line 5
fragmentation is performed, and then the resulting fragments are fragmentation is performed, and then the resulting fragments are
assigned sequential sequence numbers. assigned sequential sequence numbers.
Depending on the specific PWE3 encapsulation in use, the value 0 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 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 use for fragmentation must follow this same rule - as the sequence
number is incremented, it skips zero and wraps from 65535 to 1. 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 Conversely, if the value 0 is part of the sequence space, then the
same sequence space is also used for fragmentation and reassembly. same sequence space is also used for fragmentation and reassembly.
PWE3 Fragmentation and Reassembly September 2005 PWE3 Fragmentation and Reassembly November 2005
3. Alternatives to PWE3 Fragmentation/Reassembly 3. Alternatives to PWE3 Fragmentation/Reassembly
Fragmentation and reassembly in network equipment generally Fragmentation and reassembly in network equipment generally
requires significantly greater resources than sending a packet as a requires significantly greater resources than sending a packet as a
single unit. As such, fragmentation and reassembly should be single unit. As such, fragmentation and reassembly should be
avoided whenever possible. Ideal solutions for avoiding avoided whenever possible. Ideal solutions for avoiding
fragmentation include proper configuration and management of MTU fragmentation include proper configuration and management of MTU
sizes between the Customer Edge (CE) router, Provider Edge (PE) sizes between the Customer Edge (CE) router, Provider Edge (PE)
router, and across the PSN, as well as adaptive measures which router, and across the PSN, as well as adaptive measures which
operate with the originating host [e.g. [PATHMTU], [PATHMTUv6]] to operate with the originating host [e.g. [PATHMTU], [PATHMTUv6]] to
reduce the packet sizes at the source. reduce the packet sizes at the source.
skipping to change at page 5, line 32 skipping to change at page 5, line 32
which is greater than the PSN MTU, the PE NSP may perform IP which is greater than the PSN MTU, the PE NSP may perform IP
fragmentation on the packet, also replicating the L2 header for the fragmentation on the packet, also replicating the L2 header for the
IP fragments. This effectively creates two (or more) packets, each IP fragments. This effectively creates two (or more) packets, each
carrying an IP fragment preceded by an L2 header, for transport carrying an IP fragment preceded by an L2 header, for transport
individually across the PW. The receiving PE is unaware that the individually across the PW. The receiving PE is unaware that the
originating host did not perform the IP fragmentation, and as such originating host did not perform the IP fragmentation, and as such
does not treat the PW packets in any special way. This ultimately does not treat the PW packets in any special way. This ultimately
has the affect of placing the burden of fragmentation on the PE has the affect of placing the burden of fragmentation on the PE
NSP, and reassembly on the IP destination host. NSP, and reassembly on the IP destination host.
4. PWE3 Fragmentation With MPLS 4. PWE3 Fragmentation With MPLS
When using the signaling procedures in [MPLS-Control], there is a When using the signaling procedures in [MPLS-Control], there is a
Pseudowire Interface Parameter Sub-TLV type used to signal the use Pseudowire Interface Parameter Sub-TLV type used to signal the use
of fragmentation when advertising a VC label[IANA]: of fragmentation when advertising a VC label[IANA]:
Parameter Length Description Parameter Length Description
0x09 2 Fragmentation indicator 0x09 2 Fragmentation indicator
The presence of this parameter in the VC FEC element indicates that The presence of this parameter in the VC FEC element indicates that
the receiver is able to reassemble fragments when the control word the receiver is able to reassemble fragments when the control word
is in use for the VC label being advertised. It does not obligate 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 to use fragmentation; it is simply an indication that
the sender MAY use fragmentation. The sender MUST NOT use the sender MAY use fragmentation. The sender MUST NOT use
fragmentation if this parameter is not present in the VC FEC fragmentation if this parameter is not present in the VC FEC
element. element.
If [MPLS-Control] signaling is not in use, then whether or not to If [MPLS-Control] signaling is not in use, then whether or not to
use fragmentation MUST be configured in the sender. use fragmentation MUST be configured in the sender.
PWE3 Fragmentation and Reassembly September 2005 PWE3 Fragmentation and Reassembly November 2005
4.1 Fragment Bit Locations For MPLS 4.1 Fragment Bit Locations For MPLS
MPLS-based PWE3 uses the following control word format [Control- MPLS-based PWE3 uses the following control word format [Control-
Word], with the B and E fragmentation bits identified in position 8 Word], with the B and E fragmentation bits identified in position 8
and 9: and 9:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd | Flags |B|E| Length | Sequence Number | |0 0 0 0| Flags |B|E| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: MPLS PWE3 Control Word Figure 3: Preferred PW MPLS Control Word
The B and E bits are defined as follows: The B and E bits are defined as follows:
BE BE
-- --
00 indicates that the entire (un-fragmented) payload is carried 00 indicates that the entire (un-fragmented) payload is carried
in a single packet in a single packet
01 indicates the packet carrying the first fragment 01 indicates the packet carrying the first fragment
10 indicates the packet carrying the last fragment 10 indicates the packet carrying the last fragment
11 indicates a packet carrying an intermediate fragment 11 indicates a packet carrying an intermediate fragment
See Appendix A for a discussion of the derivation of these values See Appendix A for a discussion of the derivation of these values
for the B and E bits. for the B and E bits.
See section 2 for the description of the use of the Sequence Number See section 2 for the description of the use of the Sequence Number
field. field.
4.2 Other Considerations 4.2 Other Considerations
Path MTU [PATHMTU] [PATHMTUv6] may be used to dynamically determine Path MTU [PATHMTU] [PATHMTUv6] may be used to dynamically determine
the maximum size for fragments. The application of path MTU to MPLS the maximum size for fragments. The application of path MTU to MPLS
is discussed in [LABELSTACK]. The maximum size of the fragments may is discussed in [LABELSTACK]. The maximum size of the fragments may
also be configured. The signaled Interface MTU parameter in [MPLS- also be configured. The signaled Interface MTU parameter in [MPLS-
Control] SHOULD be used to set the maximum size of the reassembly Control] SHOULD be used to set the maximum size of the reassembly
buffer for received packets to make optimal use of reassembly buffer for received packets to make optimal use of reassembly
buffer resources. buffer resources.
5. PWE3 Fragmentation With L2TP 5. PWE3 Fragmentation With L2TP
This section defines the location of the B and E bits for L2TPv3 This section defines the location of the B and E bits for L2TPv3
[L2TPv3] and L2TPv2 [L2TPv2] headers, as well as the signaling [L2TPv3] and L2TPv2 [L2TPv2] headers, as well as the signaling
mechanism for advertising MRU (Maximum Receive Unit) values and mechanism for advertising MRU (Maximum Receive Unit) values and
support for fragmentation on a given PW. As IP is the most common support for fragmentation on a given PW. As IP is the most common
PWE3 Fragmentation and Reassembly September 2005 PWE3 Fragmentation and Reassembly November 2005
PSN used with L2TP, IP PSN fragmentation and reassembly is PSN used with L2TP, IP PSN fragmentation and reassembly is
discussed as well. discussed as well.
5.1 PW-specific Fragmentation vs. IP fragmentation 5.1 PW-specific Fragmentation vs. IP fragmentation
When proper MTU management across a network fails, IP PSN When proper MTU management across a network fails, IP PSN
fragmentation and reassembly may be used to accommodate MTU fragmentation and reassembly may be used to accommodate MTU
mismatches between tunnel endpoints. If the overall traffic mismatches between tunnel endpoints. If the overall traffic
requiring fragmentation and reassembly is very light, or there are requiring fragmentation and reassembly is very light, or there are
sufficient optimized mechanisms for IP PSN fragmentation and sufficient optimized mechanisms for IP PSN fragmentation and
reassembly available, IP PSN fragmentation and reassembly may be reassembly available, IP PSN fragmentation and reassembly may be
sufficient. sufficient.
When facing a large number of PW packets requiring fragmentation When facing a large number of PW packets requiring fragmentation
skipping to change at page 7, line 44 skipping to change at page 7, line 44
three different places (the IP PSN, the PW, and the encapsulated three different places (the IP PSN, the PW, and the encapsulated
payload). Care must be taken to ensure that the MTU/MRU values are payload). Care must be taken to ensure that the MTU/MRU values are
set and advertised properly at each tunnel endpoint to avoid this. set and advertised properly at each tunnel endpoint to avoid this.
When fragmentation is enabled within a given PW, the DF bit MUST be When fragmentation is enabled within a given PW, the DF bit MUST be
set on all L2TP over IP packets for that PW. set on all L2TP over IP packets for that PW.
L2TPv3 nodes SHOULD participate in Path MTU [PATHMTU], [PATHMTUv6] L2TPv3 nodes SHOULD participate in Path MTU [PATHMTU], [PATHMTUv6]
for automatic adjustment of the PSN MTU. When the payload is IP, for automatic adjustment of the PSN MTU. When the payload is IP,
Path MTU should be used at they payload level as well. Path MTU should be used at they payload level as well.
5.2 Advertising Reassembly Support in L2TP 5.2 Advertising Reassembly Support in L2TP
The constructs defined in this section for advertising The constructs defined in this section for advertising
fragmentation support in L2TP are applicable to [L2TPv3] and fragmentation support in L2TP are applicable to [L2TPv3] and
[L2TPv2]. [L2TPv2].
This document defines two new AVPs to advertise maximum receive This document defines two new AVPs to advertise maximum receive
unit values and reassembly support. These AVPs MAY be present in unit values and reassembly support. These AVPs MAY be present in
the ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, or SLI messages. The most the ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, or SLI messages. The most
recent value received always takes precedence over a previous recent value received always takes precedence over a previous
value, and MUST be dynamic over the life of the session if received value, and MUST be dynamic over the life of the session if received
PWE3 Fragmentation and Reassembly September 2005 PWE3 Fragmentation and Reassembly November 2005
via the SLI message. One of the two new AVPs (MRRU) is used to 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 advertise that PWE3 reassembly is supported by the sender of the
AVP. Reassembly support MAY be unidirectional. AVP. Reassembly support MAY be unidirectional.
5.3 L2TP Maximum Receive Unit (MRU) AVP 5.3 L2TP Maximum Receive Unit (MRU) AVP
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRU | | MRU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MRU (Maximum Receive Unit), attribute number TBD1, is the maximum MRU (Maximum Receive Unit), attribute number TBD1, is the maximum
size in octets of a fragmented or complete PW frame, including L2TP size in octets of a fragmented or complete PW frame, including L2TP
encapsulation, receivable by the side of the PW advertising this encapsulation, receivable by the side of the PW advertising this
value. The advertised MRU does NOT include the PSN header (i.e. the 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 IP and/or UDP header). This AVP does not imply that PWE3
fragmentation or reassembly is supported. If reassembly is not fragmentation or reassembly is supported. If reassembly is not
enabled or unavailable, this AVP may be used alone to advertise the enabled or unavailable, this AVP may be used alone to advertise the
MRU for a complete frame. MRU for a complete frame.
This AVP MAY be hidden (the H bit MAY be 0 or 1). The mandatory (M) 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 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. 8. The Vendor ID is the IETF Vendor ID of 0.
5.4 L2TP Maximum Reassembled Receive Unit (MRRU) AVP 5.4 L2TP Maximum Reassembled Receive Unit (MRRU) AVP
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRRU | | MRRU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MRRU (Maximum Reassembled Receive Unit AVP), attribute number TBD2, MRRU (Maximum Reassembled Receive Unit AVP), attribute number TBD2,
is the maximum size in octets of a reassembled frame, including any is the maximum size in octets of a reassembled frame, including any
PW framing, but not including the L2TP encapsulation or L2-specific PW framing, but not including the L2TP encapsulation or L2-specific
skipping to change at page 9, line 5 skipping to change at page 9, line 5
MRRU is present in a message, the MRU AVP MUST be present as well. MRRU is present in a message, the MRU AVP MUST be present as well.
The MRRU SHOULD be used to set the maximum size of the reassembly The MRRU SHOULD be used to set the maximum size of the reassembly
buffer for received packets to make optimal use of reassembly buffer for received packets to make optimal use of reassembly
buffer resources. buffer resources.
This AVP MAY be hidden (the H bit MAY be 0 or 1). The mandatory (M) 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 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. 8. The Vendor ID is the IETF Vendor ID of 0.
PWE3 Fragmentation and Reassembly September 2005 PWE3 Fragmentation and Reassembly November 2005
5.5 Fragment Bit Locations For L2TPv3 Encapsulation 5.5 Fragment Bit Locations For L2TPv3 Encapsulation
The usage of the B and E bits is described in Section 4.1. For 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 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 in the leading bits of the Default L2-Specific Sublayer (see
Section 7). Section 7).
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|B|E|x|x|x|x| Sequence Number | |x|S|B|E|x|x|x|x| Sequence Number |
skipping to change at page 9, line 35 skipping to change at page 9, line 35
When fragmentation is used, an L2-Specific Sublayer with B and E When fragmentation is used, an L2-Specific Sublayer with B and E
bits defined MUST be present in all data packets for a given bits defined MUST be present in all data packets for a given
session. The presence and format of the L2-Specific Sublayer is session. The presence and format of the L2-Specific Sublayer is
advertised via the L2-Specific Sublayer AVP, Attribute Type 69, advertised via the L2-Specific Sublayer AVP, Attribute Type 69,
defined in section 5.4.4 of [L2TPv3]. defined in section 5.4.4 of [L2TPv3].
See section 2 for the description of the use of the Sequence Number See section 2 for the description of the use of the Sequence Number
field. field.
5.6 Fragment Bit Locations for L2TPv2 Encapsulation 5.6 Fragment Bit Locations for L2TPv2 Encapsulation
The usage of the B and E bits is described in Section 4.1. For 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 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 in the leading bits of the L2TPv2 header as depicted below (see
Section 7). Section 7).
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|O|P|B|E|x|x| Ver | Length (opt) | |T|L|x|x|S|x|O|P|B|E|x|x| Ver | Length (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: B and E bits location in the L2TPv2 Message Header Figure 5: B and E bits location in the L2TPv2 Message Header
6. Security Considerations 6. Security Considerations
As with any additional protocol construct, each level of complexity As with any additional protocol construct, each level of complexity
adds the potential to exploit protocol and implementation errors. adds the potential to exploit protocol and implementation errors.
PWE3 Fragmentation and Reassembly September 2005 PWE3 Fragmentation and Reassembly November 2005
Implementers should be especially careful of not tying up an Implementers should be especially careful of not tying up an
abundance of resources, even for the most pathological combination abundance of resources, even for the most pathological combination
of packet fragments that could be received. Beyond these issues of of packet fragments that could be received. Beyond these issues of
general implementation quality, there are no known notable security general implementation quality, there are no known notable security
issues with using the mechanism defined in this document. It issues with using the mechanism defined in this document. It
should be pointed out that RFC 1990, on which this document is should be pointed out that RFC 1990, on which this document is
based, and its derivatives have been widely implemented and based, and its derivatives have been widely implemented and
extensively used in the Internet and elsewhere. extensively used in the Internet and elsewhere.
skipping to change at page 10, line 32 skipping to change at page 10, line 32
have been performed. The latter is not an issue with the PW- have been performed. The latter is not an issue with the PW-
specific fragmentation method described in this document as there specific fragmentation method described in this document as there
is no offset field; However, implementations MUST be sure to not is no offset field; However, implementations MUST be sure to not
allow more than one whole fragment to overwrite another in a allow more than one whole fragment to overwrite another in a
reconstructed frame. The former may be a concern if packet reconstructed frame. The former may be a concern if packet
filtering and access controls are being placed on tunneled frames filtering and access controls are being placed on tunneled frames
within the PW encapsulation. To circumvent any possible attacks in within the PW encapsulation. To circumvent any possible attacks in
either case, all filtering and access controls should be applied to either case, all filtering and access controls should be applied to
the resulting reconstructed frame rather than any PW fragments. the resulting reconstructed frame rather than any PW fragments.
7. IANA Considerations 7. IANA Considerations
This document does not define any new registries for IANA to This document does not define any new registries for IANA to
maintain. maintain.
Note that [IANA] has already allocated the Fragmentation Indicator Note that [IANA] has already allocated the Fragmentation Indicator
interface parameter, so no further IANA action is required. interface parameter, so no further IANA action is required.
This document requires IANA to assign new values for registries This document requires IANA to assign new values for registries
already managed by IANA (see Sections 7.1 and 7.2), and two already managed by IANA (see Sections 7.1 and 7.2), and two
reserved bits in an existing header (see Section 7.3). reserved bits in an existing header (see Section 7.3).
7.1 Control Message Attribute Value Pairs (AVPs)
7.1 Control Message Attribute Value Pairs (AVPs)
Two additional AVP Attributes are specified in Section 5.3 and Two additional AVP Attributes are specified in Section 5.3 and
Section 5.4. They are required to be defined by IANA as described Section 5.4. They are required to be defined by IANA as described
in Section 2.2 of [BCP0068]. in Section 2.2 of [BCP0068].
Control Message Attribute Value Pairs Control Message Attribute Value Pairs
------------------------------------- -------------------------------------
TBD1 - Maximum Receive Unit (MRU) AVP TBD1 - Maximum Receive Unit (MRU) AVP
TBD2 - Maximum Reassembled Receive Unit (MRRU) AVP TBD2 - Maximum Reassembled Receive Unit (MRRU) AVP
PWE3 Fragmentation and Reassembly September 2005 PWE3 Fragmentation and Reassembly November 2005
7.2 Default L2-Specific Sublayer bits 7.2 Default L2-Specific Sublayer bits
This registry was created as part of the publication of [L2TPv3]. This registry was created as part of the publication of [L2TPv3].
This document defines two reserved bits in the Default L2-Specific This document defines two reserved bits in the Default L2-Specific
Sublayer in Section 5.5, which may be assigned by IETF Consensus Sublayer in Section 5.5, which may be assigned by IETF Consensus
[RFC2434]. They are required to be assigned by IANA. [RFC2434]. They are required to be assigned by IANA.
Default L2-Specific Sublayer bits - per [L2TPv3] Default L2-Specific Sublayer bits - per [L2TPv3]
--------------------------------- ---------------------------------
Bit 2 - B (Fragmentation) bit Bit 2 - B (Fragmentation) bit
Bit 3 - E (Fragmentation) bit Bit 3 - E (Fragmentation) bit
7.3 Leading Bits of the L2TPv2 Message Header 7.3 Leading Bits of the L2TPv2 Message Header
This document requires definition of two reserved bits in the This document requires definition of two reserved bits in the
L2TPv2 [L2TPv2] header. Locations are noted by the "B" and "E" bits L2TPv2 [L2TPv2] header. Locations are noted by the "B" and "E" bits
in section 5.6. in section 5.6.
Leading Bits of the L2TPv2 Message Header Leading Bits of the L2TPv2 Message Header
----------------------------------------- -----------------------------------------
Bit 8 - B (Fragmentation) bit Bit 8 - B (Fragmentation) bit
Bit 9 - E (Fragmentation) bit Bit 9 - E (Fragmentation) bit
8. Acknowledgements 8. Acknowledgements
The authors wish to thank Eric Rosen and Carlos Pignataro, both of The authors wish to thank Eric Rosen and Carlos Pignataro, both of
Cisco Systems, for their review of this document. Cisco Systems, for their review of this document.
9. Normative References 9. Normative References
[Control-Word] Bryant, S. et al, "PWE3 Control Word for use over an [Control-Word] Bryant, S. et al, "PWE3 Control Word for use over an
MPLS PSN", draft-ietf-pwe3-cw-05.txt, July 2005, work in MPLS PSN", draft-ietf-pwe3-cw-06.txt, October 2005, work in
progress progress
[IANA] Martini, L. et al, "IANA Allocations for pseudo Wire Edge [IANA] Martini, L. et al, "IANA Allocations for pseudo Wire Edge
to Edge Emulation (PWE3)", draft-ietf-pwe3-iana-allocation- to Edge Emulation (PWE3)", draft-ietf-pwe3-iana-allocation-
11.txt, June 2005, work in progress 15.txt, November 2005, work in progress
[LABELSTACK] Rosen, E. et al, "MPLS Label Stack Encoding", RFC [LABELSTACK] Rosen, E. et al, "MPLS Label Stack Encoding", RFC
3032, January 2001 3032, January 2001
[L2TPv2] Townsley, Valencia, Rubens, Pall, Zorn, Palter, "Layer Two [L2TPv2] Townsley, Valencia, Rubens, Pall, Zorn, Palter, "Layer Two
Tunneling Protocol 'L2TP'", RFC 2661, June 1999 Tunneling Protocol 'L2TP'", RFC 2661, June 1999
PWE3 Fragmentation and Reassembly September 2005 PWE3 Fragmentation and Reassembly November 2005
[L2TPv3] Lau, J. et al, "Layer Two Tunneling Protocol - Version [L2TPv3] Lau, J. et al, "Layer Two Tunneling Protocol - Version
3 (L2TPv3)", RFC 3931, March 2005. 3 (L2TPv3)", RFC 3931, March 2005.
[MLPPP] Sklower, K. et al, "The PPP Multilink Protocol (MP)", RFC [MLPPP] Sklower, K. et al, "The PPP Multilink Protocol (MP)", RFC
1990, August 1996 1990, August 1996
[MPLS-Control] Martini, L. et al, "Pseudowire Setup and Maintenance [MPLS-Control] Martini, L. et al, "Pseudowire Setup and Maintenance
using the Label Distribution Protocol", draft-ietf-pwe3- using the Label Distribution Protocol", draft-ietf-pwe3-
control-protocol-17.txt, June 2005, work in progress control-protocol-17.txt, June 2005, work in progress
[PATHMTU] Mogul, J. C. et al, "Path MTU Discovery", RFC 1191, [PATHMTU] Mogul, J. C. et al, "Path MTU Discovery", RFC 1191,
November 1990 November 1990
[PATHMTUv6] McCann, J. et al, "Path MTU Discovery for IP version [PATHMTUv6] McCann, J. et al, "Path MTU Discovery for IP version
6", RFC 1981, August 1996 6", RFC 1981, August 1996
10. Informative References 10. Informative References
[Architecture] Bryant, S. et al, "Pseudo Wire Emulation Edge-to- [Architecture] Bryant, S. et al, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005 Edge (PWE3) Architecture", RFC 3985, March 2005
[FAST] ATM Forum, "Frame Based ATM over SONET/SDH Transport [FAST] ATM Forum, "Frame Based ATM over SONET/SDH Transport
(FAST)", af-fbatm-0151.000, July 2000 (FAST)", af-fbatm-0151.000, July 2000
[FRF.12] Frame Relay Forum, "Frame Relay Fragmentation [FRF.12] Frame Relay Forum, "Frame Relay Fragmentation
Implementation Agreement", FRF.12, December 1997 Implementation Agreement", FRF.12, December 1997
[IPFRAG-SEC] Ziemba, G., Reed, D., Traina, P., "Security [IPFRAG-SEC] Ziemba, G., Reed, D., Traina, P., "Security
Considerations for IP Fragment Filtering", RFC 1858, October Considerations for IP Fragment Filtering", RFC 1858, October
1995 1995
[TINYFRAG] Miller, I., "Protection Against a Variant of the Tiny [TINYFRAG] Miller, I., "Protection Against a Variant of the Tiny
Fragment Attack", RFC 3128, June 2001 Fragment Attack", RFC 3128, June 2001
PWE3 Fragmentation and Reassembly November 2005
11. Full Copyright Statement 11. Full Copyright Statement
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
PWE3 Fragmentation and Reassembly September 2005
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. PARTICULAR PURPOSE.
12. Authors' Addresses 12. Authors' Addresses
Andrew G. Malis Andrew G. Malis
Tellabs Tellabs
90 Rio Robles Drive 90 Rio Robles Drive
San Jose, CA 95134 San Jose, CA 95134
Email: Andy.Malis@tellabs.com Email: Andy.Malis@tellabs.com
W. Mark Townsley W. Mark Townsley
Cisco Systems Cisco Systems
7025 Kit Creek Road 7025 Kit Creek Road
PO Box 14987 PO Box 14987
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
Email: mark@townsley.net Email: mark@townsley.net
13. Appendix A: Relationship Between This Document and RFC 1990 13. Appendix A: Relationship Between This Document and RFC 1990
The fragmentation of large packets into smaller units for The fragmentation of large packets into smaller units for
transmission is not new. One fragmentation and reassembly method transmission is not new. One fragmentation and reassembly method
was defined in RFC 1990, Multi-Link PPP [MLPPP]. This method was was defined in RFC 1990, Multi-Link PPP [MLPPP]. This method was
also adopted for both Frame Relay [FRF.12] and ATM [FAST] network also adopted for both Frame Relay [FRF.12] and ATM [FAST] network
technology. This document adopts the RFC 1990 fragmentation and technology. This document adopts the RFC 1990 fragmentation and
reassembly procedures as well, with some distinct modifications reassembly procedures as well, with some distinct modifications
described in this appendix. Familiarity with RFC 1990 is assumed. described in this appendix. Familiarity with RFC 1990 is assumed.
RFC 1990 was designed for use in environments where packet RFC 1990 was designed for use in environments where packet
fragments may arrive out of order due to their transmission on fragments may arrive out of order due to their transmission on
multiple parallel links, specifying that buffering be used to place multiple parallel links, specifying that buffering be used to place
the fragments in correct order. For PWE3, the ability to reorder the fragments in correct order. For PWE3, the ability to reorder
fragments prior to reassembly is OPTIONAL; receivers MAY choose to fragments prior to reassembly is OPTIONAL; receivers MAY choose to
PWE3 Fragmentation and Reassembly November 2005
drop frames when a lost fragment is detected. Thus, when the drop frames when a lost fragment is detected. Thus, when the
sequence number on received fragments shows that a fragment has sequence number on received fragments shows that a fragment has
been skipped, the partially reassembled packet MAY be dropped, or been skipped, the partially reassembled packet MAY be dropped, or
the receiver MAY wish to wait for the fragment to arrive out of 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 order. In the latter case, a reassembly timer MUST be used to
avoid locking up buffer resources for too long a period. avoid locking up buffer resources for too long a period.
Dropping out-of-order fragments on a given PW can provide a Dropping out-of-order fragments on a given PW can provide a
considerable scalability advantage for network equipment performing considerable scalability advantage for network equipment performing
reassembly. If out-of-order fragments are a relatively rare event reassembly. If out-of-order fragments are a relatively rare event
on a given PW, throughput should not be adversely affected by this. on a given PW, throughput should not be adversely affected by this.
Note, however, if there are cases where fragments of a given frame 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 are received out-or-order in a consistent manner (e.g. a short
PWE3 Fragmentation and Reassembly September 2005
fragment is always switched ahead of a larger fragment) then fragment is always switched ahead of a larger fragment) then
dropping out-of-order fragments will cause the fragmented frame to dropping out-of-order fragments will cause the fragmented frame to
never be received. This condition may result in an effective denial never be received. This condition may result in an effective denial
of service to a higher-lever application. As such, implementations of service to a higher-lever application. As such, implementations
fragmenting a PW frame MUST at the very least ensure that all fragmenting a PW frame MUST at the very least ensure that all
fragments are sent in order from their own egress point. fragments are sent in order from their own egress point.
An implementation may also choose to allow reassembly of a limited 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 number of fragmented frames on a given PW, or across a set of PWs
with reassembly enabled. This allows for a more even distribution with reassembly enabled. This allows for a more even distribution
skipping to change at page 14, line 42 skipping to change at page 15, line 5
+-+-+-+-+-------+---------------+ +-+-+-+-+-------+---------------+
+-+-+-+-+-+-+-+-+---------------+ +-+-+-+-+-+-+-+-+---------------+
|B|E|0|0|0|0|0|0|sequence number| |B|E|0|0|0|0|0|0|sequence number|
+-+-+-+-+-+-+-+-+---------------+ +-+-+-+-+-+-+-+-+---------------+
| sequence number (L) | | sequence number (L) |
+---------------+---------------+ +---------------+---------------+
Figure 6: RFC 1990 Header Formats Figure 6: RFC 1990 Header Formats
PWE3 Fragmentation and Reassembly November 2005
PWE3 fragmentation takes advantage of existing PW sequence numbers PWE3 fragmentation takes advantage of existing PW sequence numbers
and control bit fields wherever possible, rather than defining a and control bit fields wherever possible, rather than defining a
separate header exclusively for the use of fragmentation. Thus, it separate header exclusively for the use of fragmentation. Thus, it
uses neither of the RFC 1990 sequence number formats described uses neither of the RFC 1990 sequence number formats described
above, relying instead on the sequence number that already exists above, relying instead on the sequence number that already exists
in the PWE3 header. in the PWE3 header.
RFC 1990 defines a two one-bit fields, a (B)eginning fragment bit RFC 1990 defines a 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 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 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 fragments from the same PPP packet. The E bit is set to 1 on the
PWE3 Fragmentation and Reassembly September 2005
last fragment and set to 0 for all other fragments. A complete last fragment and set to 0 for all other fragments. A complete
unfragmented frame has both the B and E bits set to 1. unfragmented frame has both the B and E bits set to 1.
PWE3 fragmentation inverts the value of the B and E bits, while PWE3 fragmentation inverts the value of the B and E bits, while
retaining the operational concept of marking the beginning and 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 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 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 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 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 complete unfragmented frame has both the B and E bits set to 0. The
 End of changes. 48 change blocks. 
49 lines changed or deleted 49 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/