PPP Extensions Working Group Internet Draft Peter Arberg Diamantis Kourkouzelis Intended status: Informational Redback Networks Expiration date: October 2005 Mike Duckett Tom Anschutz BellSouth April 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, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3979. Abstract Point-to-Point Protocol Over Ethernet, (PPPoE), as described in RFC 2516 [1], mandates a maximum negotiated MRU of 1492. This document proposes relaxing that restriction to allow a maximum negotiated MRU greater than 1492 to minimize fragmentation in next generation broadband networks. Arberg Expires October 2005 [Page 1] Internet Draft PPPoE MRU/MTU Increase April 2003 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]. PPPoA - PPP over AAL5. PPPoE - PPP over Ethernet. CPE - Customer Premises Equipment. RG - Residential Gateway. BRAS - Broadband Remote Access Server. 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. <----- IPoE -----> <--------- PPPoE session ---------> +-----+ +-----+ +--+ +---+ | | | | |PC|--------------| RG|-----------|DSLAM|------------| BRAS| +--+ +---+ | | | | +-----+ +-----+ Fig. 2: Next generation broadband network designs with PPPoE. Arberg Expires October 2005 [Page 2] Internet Draft PPPoE MRU/MTU Increase April 2003 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 Edge Aggregation Router 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 client typically negotiates a 1500 bytes MRU. Widely deployed PPP/PPPoA clients in DSL Routers do not support an 1492 bytes MRU, which creates an issue in turn for the PPPoE server if strict compliance to RFC 2516 is mandated. For PPP/PPPoA clients capable of negotiating a 1492 bytes MRU size, then we are back to a fragmentation issue. Arberg Expires October 2005 [Page 3] Internet Draft PPPoE MRU/MTU Increase April 2003 3. Proposed solution It is suggested to replace Section 7, Paragraph 2 of RFC 2516, that reads as follows: "The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a larger size than 1492. Since Ethernet has a maximum payload size of 1500 octets, the PPPoE header is 6 octets and the PPP Protocol ID is 2 octets, the PPP MTU MUST NOT be greater than 1492." with the following: "The Maximum-Receive-Unit (MRU) option MUST follow the rules set forward in RFC 1661. When MRU is not present in the LCP negotiation, it MUST be assumed to equal 1492.ö 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, it is RECOMMENDED to support PPPoE MRU negotiations larger than 1492 bytes in order to limit the amount of fragmented packets in network designs shown in section 1. Attention is given to backwards compatibility with older PPPoE clients that do not support a MRU larger than 1492 bytes, while at the same time allowing for better utilization of network resources in new PPPoE designs. As such, if a MRU option is not sent by one end of the PPPoE negotiation, a default MRU size of 1492 bytes MUST be assumed and used. If the sending, side through negotiation, is assigning a MRU greater than 1492 to the receiving side it is RECOMMENDED that the sending side has the capability to send one or more MRU-sized Echo-Request packets once the session is opened, to test that the receiving side and any intermediate equipment can handle the MRU. If no Echo-Replies are received, the sending side MAY choose to repeat the test with Echo-Request packets of size 1492. If these packets receive replies, the sending side MUST treat the receiver as if it had explicitly specified a MRU of 1492. This capability SHOULD be disabled by default, and SHOULD only available for debug, test purpose. 4. Security Considerations This document does not introduce new security issues. The security considerations pertaining to the original PPPoE protocol [1] remain relevant. Arberg Expires October 2005 [Page 4] Internet Draft PPPoE MRU/MTU Increase April 2003 5. Acknowledgments The authors would like to thank Jerome Moisand, Prakash Jayaraman and Amit Cohen for their contributions and comments to this document. 6. 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. 7. Author Information Peter Arberg Redback Networks, Inc. 300 Holger Way San Jose, CA 95134 Email: parberg@redback.com Diamantis Kourkouzelis Redback Networks, Inc. 300 Holger Way San Jose, CA 95134 Email: diamondk@redback.com Mike Duckett BellSouth Telecommunications, Inc. 675 West Peachtree Street, N.E. Atlanta, Georgia 30375 Email: mike.duckett@bellsouth.com Tom Anschutz BellSouth Telecommunications, Inc. 675 West Peachtree Street, N.E. Atlanta, Georgia 30375 Email: tom.anschutz@bellsouth.com Arberg Expires October 2005 [Page 5] Internet Draft PPPoE MRU/MTU Increase April 2003 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 October 2005 [Page 6]