PPP Extensions Working Group Internet Draft Peter Arberg Diamantis Kourkouzelis Intended status: Informational Redback Networks Expiration date: April 2006 Mike Duckett Tom Anschutz BellSouth Jerome Moisand Juniper Networks October 2005 Accommodating an MTU/MRU greater than 1492 in PPPoE Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 5 of RFC3978. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Intellectual Property Considerations By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Abstract Point-to-Point Protocol Over Ethernet (PPPoE), as described in RFC 2516 [1], mandates a maximum negotiated MRU of 1492. This document outlines a solution to relax that restriction and allow a maximum negotiated MRU greater than 1492 to minimize fragmentation in next generation broadband networks. Arberg Expires April 2006 [Page 1] Internet Draft PPPoE MRU/MTU Increase October 2005 1. Terminology 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 RFC2119 [3]. ATM - Asynchronous Transfer Mode . PPP - Point-to-Point Protocol. PPPoA - PPP over AAL5. PPPoE - PPP over Ethernet. MTU - Maximum Transmit Unit MRU - Maximum Receive Unit PC - Personal Computer. CPE - Customer Premises Equipment. RG - Residential Gateway. BRAS - Broadband Remote Access Server. DSLAM – Digital Subscriber Line Access Multiplexer PPPoE client - PC, RG or CPE which initiates a PPPoE session PPPoE server - BRAS terminating PPPoE sessions initiated by client 2. Motivation With broadband network designs changing from PC initiated PPPoE [1] sessions in a combined Ethernet/ATM setup as shown in figure 1, to more intelligent PPPoE capable Residential Gateway (RG) and Gigabit Ethernet/ATM broadband network designs as show in figure 2 and 3, the need to increase the maximum transmit and receive unit in the PPPoE protocol is becoming more important to reduce fragmentation in the network. <------------------ PPPoE session ------------------> +-----+ +-----+ +--+ +---+ | | | | |PC|--------------|CPE|-----------|DSLAM|-----------| BRAS| +--+ +---+ | | | | +-----+ +-----+ Fig. 1: Initial broadband network designs with PPPoE. In the network design shown in figure 1, fragmentation is typically not a problem since the subscriber session is PPPoE end-to-end from the PC to the BRAS, so a PPP negotiated MRU of 1492 bytes is fully acceptable as it makes the largest PPPoE frame adhere to the standard Ethernet MTU of 1500 bytes. Arberg Expires April 2006 [Page 2] Internet Draft PPPoE MRU/MTU Increase October 2005 <----- IPoE -----> <--------- PPPoE session ---------> +-----+ +-----+ +--+ +---+ | | | | |PC|--------------| RG|-----------|DSLAM|------------| BRAS| +--+ +---+ | | | | +-----+ +-----+ Fig. 2: Next generation broadband network designs with PPPoE. In the network design shown in figure 2, fragmentation becomes a major problem since the subscriber session is a combination of IPoE and PPPoE. The IPoE typically negotiates a MTU of 1500 bytes. However, when the Residential Gateway and the BRAS are the PPPoE session endpoints, and therefore negotiate a MTU/MRU of 1492 bytes resulting in a large number of fragmented packets in the network. <----- IPoE -----> <---- PPPoA ----> <- PPPoE session -> +-----+ +-----+ +--+ +---+ | | | | |PC|--------------| RG|------------|DSLAM|------------| BRAS| +--+ +---+ | | | | +-----+ +-----+ <-------------- PPPoA -------------> <- PPPoE session -> +-----+ +-----+ +--+ +---+ | | | | |PC|--------------|CPE|------------|DSLAM|------------| BRAS| +--+ +---+ | | | | +-----+ +-----+ Fig. 3: Broadband network designs with PPPoA to PPPoE conversion. In the network design shown in figure 3, which is studied by the DSL-Forum in the context of the migration to Ethernet for broadband aggregation networks, fragmentation is not the only problem when MRU differences exist in PPPoA and PPPoE sessions. The subscriber session is a PPP session running over a combination of PPPoA and PPPoE. The PPP/PPPoA host typically negotiates a 1500 bytes MRU. Widely deployed PPP/PPPoA hosts in CPE equipment do not support an 1492 bytes MRU, which creates an issue in turn for the BRAS (PPPoE server) if strict compliance to RFC2516 [1] is mandated. For PPP/PPPoA hosts capable of negotiating a 1492 bytes MRU size, then we are back to a fragmentation issue. Arberg Expires April 2006 [Page 3] Internet Draft PPPoE MRU/MTU Increase September 2005 3. Proposed solution The procedure described in this document do not strictly conform to IEEE standards for Ethernet packet size, but rely on a widely deployed behavior of supporting jumbo frames on Ethernet segments. Since next generation broadband networks are built around Ethernet systems supporting baby-giants and jumbo frames with payload sizes larger than the normal Ethernet MTU of 1500 octets, a BRAS acting as a PPPoE server MUST support PPPoE MRU negotiations larger than 1492 bytes in order to limit the amount of fragmented packets in network designs shown in section 1. By default, the Maximum-Receive-Unit (MRU) option MUST follow the rules set forward in RFC1661 [2], but MUST NOT be negotiated to a larger size than 1492 to guarantee compatibility with Ethernet network segments limited to 1500 octets frames. In such a case, the PPPoE header being 6 octets and the PPP Protocol ID being 2 octets, the PPP MRU MUST NOT be greater than 1492. An optional PPPoE tag "PPP-Max-Payload" allows a PPPoE client to override this default behavior by providing a maximum size for the PPP payload it can support in both the sending and receiving directions. When such a tag is received by the PPPoE server, the server MAY allow the negotiation of a larger MRU than 1492 and the use of a larger MTU than 1492 subject to limitations of its local configuration and according to the rules set forward in RFC1661 [2], and within the limits of the maximum payload size being indicated by the PPPoE client. 4. PPPoE Discovery Stage If a PPPoE client wants to use a higher MTU/MRU than 1492 bytes, then it MUST include an optional PPP-Max-Payload Tag in the PADI and PADR packets. If the PPPoE server can support a higher MTU/MRU than 1492 bytes, it MUST respond with an echo of the clients tag in the PADO and PADS packets when the PPP-Max-Payload tag is received from the client. Tag-name: PPP-Max-Payload Tag-value: 0x0120 Tag-length: 2 octets Tag-value: binary encoded value (max PPP payload in octets) Tag-description: This TAG indicates that the client and server are capable of supporting a given maximum PPP payload greater than 1492 bytes for both the sending and receiving directions. Note that this value represents the PPP payload, so it is directly comparable with the value used in the PPP MRU negotiation. Arberg Expires April 2006 [Page 4] Internet Draft PPPoE MRU/MTU Increase October 2005 5. LCP Considerations 5.1 MRU Negotiations Since Ethernet (without jumbo frames) has a maximum payload size of 1500 octets, the PPPoE header is 6 octets and the PPP Protocol ID is 2 octets, the Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a larger size than 1492, unless both the PPPoE client and server have indicated the ability to support a larger MRU in the PPPoE Discovery Stage. The initial MRU negotiation for the PPP/PPPoE server MUST follow a flow as shown below: If PPPoE { If (PPP-Max-Payload-Tag) Not Present Then PPP_MRU_Max = 1492 Else PPP_MRU_Max = min (PPP-Max-Payload-Tag, Interface MTU-8) } “Normal” PPP_MRU_Negotiation (PPP_MRU_Max) If the PPP-Max-Payload tag is present, it MUST be considered as the maximum value for the “normal” MRU negotiation which is the master and decision maker of what the actual MRU will be negotiated to, never higher than the PPP-Max-Payload tag, but it can be negotiated to a lower value depending on the server's interface settings and the peer's negotiated MRU value. If the PPP-Max-Payload tag isn’t present, then the existing MRU constraint of 1492 bytes would stay applicable, hence preserving backward compatibility. This in summary indicates the following behavior: 1. when a "PPP-Max-Payload" tag is received, a. the value in this tag will indicate the maximum allowed MRU to accept and suggest in a MRU negotiation, b. if MRU is not negotiated then RFC1661 [2] will set the default MRU at 1500. This will say that the "PPP-Max-Payload" tag can have a greater value than 1500, but in this case RFC1661 [2] sets the default MRU to 1500, and only if MRU is negotiated higher (up to maximum payload) will the "PPP-Max-Payload" tag value be used. 2. when a "maximum-payload" tag is not received by either end, then RFC2516 [1] sets the rule. Arberg Expires April 2006 [Page 5] Internet Draft PPPoE MRU/MTU Increase October 2005 5.2 MRU test and troubleshooting If the MRU is negotiated to a larger value than 1492 bytes, the sending Side SHOULD have the option to send one or more MRU-sized Echo-Request packets once the session is opened. This allows it to test that the receiving side and any intermediate equipment can handle such packet size. If no Echo-Replies are received, the sending side MAY choose to repeat the test with 1492 bytes Echo-Request packets. If these packets receive replies, the sending side MUST not send packets bigger than 1492 octets for this session. This capability SHOULD be disabled by default, and SHOULD only be available for debug, test purpose. 6. Security Considerations This document does not introduce new security issues. The security considerations pertaining to the original PPPoE protocol [1] remain relevant. 7. Acknowledgments The authors would like to thank Prakash Jayaraman, Amit Cohen, Jim Ellis, David Thorne, John Reid, Oliver Thorp, Wojciech Dec, Jim Wilks, Mark Townsley, Bart Salaets, Tom Mistretta, Paul Howard, Dave Bernard and Darren Nobel for their contributions and comments to this document. 8. References [1] Mamakos L., Lidl K., Evarts J., Carrel D., Simone D., Wheeler R., "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999 [2] W. Simpson "The Point-to-Point Protocol (PPP)", RFC 1661, July 1994 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9. Author Information Peter Arberg Redback Networks, Inc. 300 Holger Way San Jose, CA 95134 Email: parberg@redback.com Arberg Expires April 2006 [Page 6] Internet Draft PPPoE MRU/MTU Increase October 2005 Diamantis Kourkouzelis Redback Networks, Inc. 300 Holger Way San Jose, CA 95134 Email: diamondk@redback.com Mike Duckett BellSouth Telecommunications, Inc. 575 Morosgo Drive Atlanta, GA 30324 Email: mike.duckett@bellsouth.com Tom Anschutz BellSouth Science and Technology 725 W. Peachtree St. Atlanta, GA 30308 Email: tom.anschutz@bellsouth.com Jerome Moisand Juniper Networks, Inc. 10 Technology Park Drive Westford, MA 01886 Email: jmoisand@juniper.net 8. Full Copyright Statement Copyright (C) The Internet Society (2005). 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. Arberg Expires April 2006 [Page 7]