< draft-ietf-pwe3-fragmentation-04.txt   draft-ietf-pwe3-fragmentation-05.txt >
Internet Draft Andrew G. Malis Internet Draft Andrew G. Malis
Document: draft-ietf-pwe3-fragmentation-04.txt Tellabs Document: draft-ietf-pwe3-fragmentation-05.txt Tellabs
Expires: June 2004 W. Mark Townsley Expires: August 2004 W. Mark Townsley
Cisco Systems Cisco Systems
December 2003 February 2004
PWE3 Fragmentation and Reassembly PWE3 Fragmentation and Reassembly
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 45 skipping to change at page 1, line 45
fragmentation for use by PWE3 protocols and services. fragmentation for use by PWE3 protocols and services.
Table of Contents Table of Contents
1. Overview......................................................2 1. Overview......................................................2
2. Alternatives to PWE3 Fragmentation/Reassembly.................3 2. Alternatives to PWE3 Fragmentation/Reassembly.................3
3. PWE3 Fragmentation With MPLS..................................4 3. PWE3 Fragmentation With MPLS..................................4
3.1 Fragment Bit Locations For MPLS...........................4 3.1 Fragment Bit Locations For MPLS...........................4
3.2 Other Considerations......................................5 3.2 Other Considerations......................................5
4. PWE3 Fragmentation With L2TP..................................5 4. PWE3 Fragmentation With L2TP..................................5
4.1 PW-specific Fragmentation vs. IP fragmentation............5 4.1 PW-specific Fragmentation vs. IP fragmentation............6
4.2 Advertising Reassembly Support in L2TP....................6 4.2 Advertising Reassembly Support in L2TP....................6
4.3 L2TP Maximum Receive Unit (MRU) AVP.......................7 4.3 L2TP Maximum Receive Unit (MRU) AVP.......................7
4.4 L2TP Maximum Reassembled Receive Unit (MRRU) AVP..........7 4.4 L2TP Maximum Reassembled Receive Unit (MRRU) AVP..........7
4.5 Fragment Bit Locations For L2TPv3 Encapsulation...........7 4.5 Fragment Bit Locations For L2TPv3 Encapsulation...........8
4.6 Fragment Bit Locations for L2TPv2 Encapsulation...........8 4.6 Fragment Bit Locations for L2TPv2 Encapsulation...........8
5. Security Considerations.......................................8 5. Security Considerations.......................................9
6. IANA Considerations...........................................9 6. IANA Considerations...........................................9
PWE3 Fragmentation and Reassembly December 2003 PWE3 Fragmentation and Reassembly February 2004
7. Acknowledgements..............................................9 7. Acknowledgements..............................................9
8. References....................................................9 8. References...................................................10
9. Authors' Addresses...........................................11 9. Authors' Addresses...........................................11
10. Appendix A: Relationship Between This Document and RFC 1990.11 10. Appendix A: Relationship Between This Document and RFC 1990.11
1. Overview 1. Overview
The PWE3 Architecture Document [Architecture] defines a network The PWE3 Architecture Document [Architecture] defines a network
reference model for PWE3: reference model for PWE3:
|<-------------- Emulated Service ---------------->| |<-------------- Emulated Service ---------------->|
| | | |
skipping to change at page 2, line 47 skipping to change at page 2, line 47
Figure 1: PWE3 Network Reference Model Figure 1: PWE3 Network Reference Model
A Pseudo Wire (PW) payload is normally relayed across the PW as a A Pseudo Wire (PW) payload is normally relayed across the PW as a
single PSN (IP or MPLS) PDU. However, there are cases where the single PSN (IP or MPLS) PDU. However, there are cases where the
combined size of the payload and its associated PWE3 and PSN combined size of the payload and its associated PWE3 and PSN
headers may exceed the PSN path Maximum Transmission Unit (MTU). headers may exceed the PSN path Maximum Transmission Unit (MTU).
When a packet exceeds the MTU of a given network, fragmentation and When a packet exceeds the MTU of a given network, fragmentation and
reassembly will allow the packet to traverse the network and reach reassembly will allow the packet to traverse the network and reach
its intended destination. its intended destination.
Fragmentation is also useful for real-time applications when the
payload to be transmitted in a PW, such as a low-speed TDM
multiframe structure, takes too much time to be encapsulated even
PWE3 Fragmentation and Reassembly February 2004
though it may fit within the PW MTU. In this case, the payload may
be fragmented for lower-latency transmission.
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,
PWE3 Fragmentation and Reassembly December 2003
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.
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 -->| || |
skipping to change at page 3, line 42 skipping to change at page 4, line 4
Figure 2: PWE3 Fragmentation/Reassembly Domain Figure 2: PWE3 Fragmentation/Reassembly Domain
Fragmentation takes place in the transmitting PE immediately prior Fragmentation takes place in the transmitting PE immediately prior
to PW insertion, and reassembly takes place in the receiving PE to PW insertion, and reassembly takes place in the receiving PE
immediately after PW extraction. immediately after PW extraction.
2. Alternatives to PWE3 Fragmentation/Reassembly 2. 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
PWE3 Fragmentation and Reassembly February 2004
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 CE, PE and across the PSN, as well as adaptive sizes between the CE, PE and across the PSN, as well as adaptive
measures which operate with the originating host [e.g. [PATHMTU], measures which operate with the originating host [e.g. [PATHMTU],
[PATHMTUv6]] to reduce the packet sizes at the source. [PATHMTUv6]] to reduce the packet sizes at the source.
PWE3 Fragmentation and Reassembly December 2003
A PE MAY choose to fragment a packet before allowing it to enter a A PE MAY choose to fragment a packet before allowing it to enter a
PW. For example, if an IP packet arrives from a CE with an MTU PW. For example, if an IP packet arrives from a CE with an MTU
which will yield a PW packet which is greater than the PW MTU, the which will yield a PW packet which is greater than the PW MTU, the
PE may perform IP fragmentation on the packet. This effectively PE may perform IP fragmentation on the packet. This effectively
creates two (or more) packets, each carrying an IP fragment, for creates two (or more) packets, each carrying an IP fragment, for
transport individually across the PW. The receiving PE is unaware transport individually across the PW. The receiving PE is unaware
that the originating host did not perform the IP fragmentation, and that the originating host did not perform the IP fragmentation, and
as such does not treat the PW packets in any special way. This as such does not treat the PW packets in any special way. This
ultimately has the affect of placing the burden of fragmentation on ultimately has the affect of placing the burden of fragmentation on
the PE, and reassembly on the IP destination host. the PE, and reassembly on the IP destination host.
skipping to change at page 4, line 44 skipping to change at page 5, line 5
If [MPLS-TRANS] signaling is not in use, then whether or not to use If [MPLS-TRANS] signaling is not in use, then whether or not to use
fragmentation MUST be provisioned in the sender. fragmentation MUST be provisioned in the sender.
3.1 Fragment Bit Locations For MPLS 3.1 Fragment Bit Locations For MPLS
MPLS-based PWE3 [MPLS-ATM], [MPLS-Ethernet], [MPLS-FR], [MPLS- MPLS-based PWE3 [MPLS-ATM], [MPLS-Ethernet], [MPLS-FR], [MPLS-
SATOP] uses the following control word format, with the B and E SATOP] uses the following control word format, with the B and E
fragmentation bits identified in position 8 and 9: fragmentation bits identified in position 8 and 9:
PWE3 Fragmentation and Reassembly February 2004
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 | | Rsvd | Flags |B|E| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: MPLS PWE3 Control Word Figure 3: MPLS PWE3 Control Word
PWE3 Fragmentation and Reassembly December 2003
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
skipping to change at page 5, line 46 skipping to change at page 6, line 4
is discussed in [LABELSTACK]. The maximum size of the fragments may is discussed in [LABELSTACK]. The maximum size of the fragments may
also be provisioned. The signaled Interface MTU parameter in [MPLS- also be provisioned. The signaled Interface MTU parameter in [MPLS-
TRANS] SHOULD be used to set the maximum size of the reassembly TRANS] 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.
4. PWE3 Fragmentation With L2TP 4. 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
PWE3 Fragmentation and Reassembly February 2004
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
PSN used with L2TP, IP fragmentation and reassembly is discussed as PSN used with L2TP, IP fragmentation and reassembly is discussed as
well. well.
4.1 PW-specific Fragmentation vs. IP fragmentation 4.1 PW-specific Fragmentation vs. IP fragmentation
L2TPv3 recognizes that when it is used over IP networks, it may be L2TPv3 recognizes that when it is used over IP networks, it may be
subject to IP fragmentation. The following is quoted from subject to IP fragmentation. The following is quoted from
[L2TPv3]: [L2TPv3]:
PWE3 Fragmentation and Reassembly December 2003
IP fragmentation may occur as the L2TP packet travels over the IP fragmentation may occur as the L2TP packet travels over the
IP substrate. L2TP makes no special efforts defined in this IP substrate. L2TP makes no special efforts defined in this
document to optimize this. document to optimize this.
When proper MTU management across a network fails, IP fragmentation When proper MTU management across a network fails, IP fragmentation
and reassembly may be used to accommodate MTU mismatches between and reassembly may be used to accommodate MTU mismatches between
tunnel endpoints. If the overall traffic requiring fragmentation tunnel endpoints. If the overall traffic requiring fragmentation
and reassembly is very light, or there are sufficient optimized and reassembly is very light, or there are sufficient optimized
mechanisms for IP fragmentation and reassembly available, IP mechanisms for IP fragmentation and reassembly available, IP
fragmentation and reassembly may be sufficient and is allowed, fragmentation and reassembly may be sufficient and is allowed,
skipping to change at page 6, line 44 skipping to change at page 7, line 5
avoid this. When fragmentation is enabled within a given PW, the DF 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 bit MUST be set on all L2TP over IP packets for that PW. L2TPv3
nodes SHOULD participate in Path MTU [PATHMTU], [PATHMTUv6] for nodes SHOULD participate in Path MTU [PATHMTU], [PATHMTUv6] for
automatic adjustment of the PW MTU. automatic adjustment of the PW MTU.
4.2 Advertising Reassembly Support in L2TP 4.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 L2TPv2. fragmentation support in L2TP are applicable to L2TPv3 and L2TPv2.
PWE3 Fragmentation and Reassembly February 2004
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
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.
PWE3 Fragmentation and Reassembly December 2003
4.3 L2TP Maximum Receive Unit (MRU) AVP 4.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
skipping to change at page 7, line 46 skipping to change at page 8, line 5
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
sublayer. Presence of this AVP signifies the ability to receive PW sublayer. Presence of this AVP signifies the ability to receive PW
fragments and reassemble them. Packet fragments MUST NOT be sent to fragments and reassemble them. Packet fragments MUST NOT be sent to
an implementation which has not received this value from its peer an implementation which has not received this value from its peer
in a control message. If the MRRU is present in a message, the MRU in a control message. If the MRRU is present in a message, the MRU
AVP MUST be present as well. AVP MUST be present as well.
PWE3 Fragmentation and Reassembly February 2004
All L2TP AVPs have an M (Mandatory) bit, H (Hidden) bit, Length, All L2TP AVPs have an M (Mandatory) bit, H (Hidden) bit, Length,
and Vendor ID. This AVP may be hidden (the H bit may be 0 or 1). and Vendor ID. This AVP may be hidden (the H bit may be 0 or 1).
The M bit for this AVP SHOULD be set to 0. The Length (before The 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. hiding) is 8. The Vendor ID is the IETF Vendor ID of 0.
4.5 Fragment Bit Locations For L2TPv3 Encapsulation 4.5 Fragment Bit Locations For L2TPv3 Encapsulation
The B and E bits are defined as bits 2 and 3 in the L2TPv3 default The B and E bits are defined as bits 2 and 3 in the L2TPv3 default
L2-specific sublayer as depicted below, using the values defined in L2-specific sublayer as depicted below, using the values defined in
section 3.1: section 3.1:
PWE3 Fragmentation and Reassembly December 2003
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P|S|B|E|x|x|x|x| Sequence Number | |P|S|B|E|x|x|x|x| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: L2TPv3 over IP Header Figure 4: L2TPv3 over IP Header
Location of the B and E bits for PW-Types which use a variant L2- Location of the B and E bits for PW-Types which use a variant L2-
specific sublayer are outside the scope of this document. specific sublayer are outside the scope of this document.
skipping to change at page 8, line 43 skipping to change at page 8, line 54
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel ID | Session ID | | Tunnel ID | Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ns (opt) | Nr (opt) | | Ns (opt) | Nr (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset Size (opt) | Offset pad... (opt) | Offset Size (opt) | Offset pad... (opt)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: L2TPv2 over UDP Header Figure 5: L2TPv2 over UDP Header
PWE3 Fragmentation and Reassembly February 2004
5. Security Considerations 5. 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.
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
PWE3 Fragmentation and Reassembly December 2003
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.
[IPFRAG-SEC] and [TINYFRAG] describe potential network attacks [IPFRAG-SEC] and [TINYFRAG] describe potential network attacks
associated with IP fragmentation and reassembly. The issues associated with IP fragmentation and reassembly. The issues
described in these documents attempt to bypass IP access controls described in these documents attempt to bypass IP access controls
by sending various carefully formed "tiny fragments", or by by sending various carefully formed "tiny fragments", or by
skipping to change at page 9, line 33 skipping to change at page 9, line 41
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.
6. IANA Considerations 6. IANA Considerations
This document does not define any new values for IANA to maintain. This document does not define any new values for IANA to maintain.
This document requires definition of two reserved bits in the This document requires definition of two reserved bits in the
L2TPv2 [L2TPv2] header. Recommended locations are noted by the ôBö L2TPv2 [L2TPv2] header. Recommended locations are noted by the "B"
and ôEö bits in section 5.6. and "E" bits in section 5.6.
This document requires IANA to assign two new L2TP "Control Message This document requires IANA to assign two new L2TP "Control Message
Attribute Value Pairs" (TBD1 and TBD2 in this document). Attribute Value Pairs" (TBD1 and TBD2 in this document).
7. Acknowledgements 7. Acknowledgements
Thanks to Eric Rosen for his review of this document. Thanks to Eric Rosen for his review of this document.
PWE3 Fragmentation and Reassembly February 2004
8. References 8. References
[Architecture] Bryant, S. et al, "PWE3 Architecture", draft-ietf- [Architecture] Bryant, S. et al, "PWE3 Architecture", draft-ietf-
pwe3-arch-06.txt, October 2003, work in progress pwe3-arch-06.txt, October 2003, work in progress
[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
PWE3 Fragmentation and Reassembly December 2003
[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
[L2TPv3] Lau, J. et al, "Layer Two Tunneling Protocol (Version 3) [L2TPv3] Lau, J. et al, "Layer Two Tunneling Protocol (Version 3)
'L2TPv3'", draft-ietf-l2tpext-l2tp-base-11.txt, October 2003, 'L2TPv3'", draft-ietf-l2tpext-l2tp-base-11.txt, October 2003,
work in progress work in progress
[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-ATM] Martini, L. et al, "Encapsulation Methods for Transport [MPLS-ATM] Martini, L. et al, "Encapsulation Methods for Transport
of ATM Cells/Frame Over IP and MPLS Networks", draft-ietf-pwe3- of ATM Cells/Frame Over IP and MPLS Networks", draft-ietf-pwe3-
atm-encap-03.txt, October 2003, work in progress atm-encap-04.txt, December 2003, work in progress
[MPLS-Ethernet] Martini, L. et al, "Encapsulation Methods for [MPLS-Ethernet] Martini, L. et al, "Encapsulation Methods for
Transport of Ethernet Frames Over IP and MPLS Networks", draft- Transport of Ethernet Frames Over IP and MPLS Networks", draft-
ietf-pwe3-ethernet-encap-04.txt, October 2003, work in progress ietf-pwe3-ethernet-encap-05.txt, December 2003, work in
progress
[MPLS-FR] Martini, L. et al, "Frame Relay Encapsulation over [MPLS-FR] Martini, L. et al, "Frame Relay Encapsulation over
Pseudo-Wires", draft-ietf-pwe3-frame-relay-01.txt, July 2003, Pseudo-Wires", draft-ietf-pwe3-frame-relay-02.txt, February
work in progress 2004, work in progress
[MPLS-SATOP] Vainshtein, A. et al, "Structure-Agnostic TDM over [MPLS-SATOP] Vainshtein, A. et al, "Structure-Agnostic TDM over
Packet (SAToP)", draft-ietf-pwe3-satop-00.txt, September 2003, Packet (SAToP)", draft-ietf-pwe3-satop-01.txt, December 2003,
work in progress work in progress
[MPLS-TRANS] Martini, L. et al, "Transport of Layer 2 Frames Over [MPLS-TRANS] Martini, L. et al, "Transport of Layer 2 Frames Over
MPLS", draft-ietf-pwe3-control-protocol-04.txt, October 2003, MPLS", draft-ietf-pwe3-control-protocol-05.txt, December 2003,
work in progress 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
PWE3 Fragmentation and Reassembly February 2004
[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
[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 December 2003
9. Authors' Addresses 9. 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
skipping to change at page 11, line 43 skipping to change at page 12, line 5
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
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.
PWE3 Fragmentation and Reassembly February 2004
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
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
PWE3 Fragmentation and Reassembly December 2003
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
of reassembly resources, reducing the chance of a single or small of reassembly resources, reducing the chance of a single or small
set of PWs exhausting all reassembly resources for a node. As with set of PWs exhausting all reassembly resources for a node. As with
dropping out-of-order fragments, there are perceivable cases where dropping out-of-order fragments, there are perceivable cases where
this may also provide an effective denial of service. For example, this may also provide an effective denial of service. For example,
skipping to change at page 12, line 45 skipping to change at page 13, line 5
Figure 6: RFC 1990 Header Formats Figure 6: RFC 1990 Header Formats
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.
PWE3 Fragmentation and Reassembly February 2004
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
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
PWE3 Fragmentation and Reassembly December 2003
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
motivation behind this value inversion for the B and E bits is to motivation behind this value inversion for the B and E bits is to
allow complete frames (and particularly, implementations that only allow complete frames (and particularly, implementations that only
support complete frames) to simply leave the B and E bits in the support complete frames) to simply leave the B and E bits in the
header set 0. header set 0.
 End of changes. 35 change blocks. 
37 lines changed or deleted 45 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/