PPP ExtensionsNetwork Working GroupInternet Draft PeterP. ArbergDiamantisRequest for Comments: 4638 D. KourkouzelisIntended status:Category: Informational Redback NetworksExpiration date: September 2006 MikeM. DuckettTomT. Anschutz BellSouthJeromeJ. Moisand Juniper NetworksMarchSeptember 2006 Accommodatingan MTU/MRU greater thana Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 inPPPoE <draft-arberg-pppoe-mtu-gt1492-03.txt>the Point-to-Point Protocol over Ethernet (PPPoE) Status ofthisThis MemoBy 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. Internet-Drafts are working documents ofThis memo provides information for the InternetEngineering 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.community. Itis inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The listdoes not specify an Internet standard ofcurrent Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The listany kind. Distribution ofInternet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 9, 2006.this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). IESG Note As of this writing, no current IEEE standard supports the use of "jumbo frames" (MTU greater than 1500). Although this document contains recommended mechanisms to detect problems in the path, interoperability and reliability of non-standard extensions cannot be assured. Both implementors and users of the protocol described here should exercise caution in its use. Abstract The Point-to-Point ProtocolOverover Ethernet (PPPoE), as described in RFC2516 [1],2516, mandates a maximum negotiatedMRUMaximum Receive Unit (MRU) of 1492. This document outlines a solutionto relaxthat relaxes this restriction andallowallows a maximum negotiated MRU greater than 1492 to minimize fragmentation innext generationnext-generation broadband networks. Table of Contents 1. Introduction ....................................................2 2. TerminologyThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",.....................................................4 3. Proposed Solution ...............................................4 4. PPPoE Discovery Stage ...........................................5 5. LCP Considerations ..............................................5 5.1. MRU Negotiations ...........................................5 5.2. MRU Test and"OPTIONAL" in this documentTroubleshooting ...............................6 6. Security Considerations .........................................7 7. IANA Considerations .............................................7 8. Acknowledgements ................................................7 9. Normative References ............................................7 10. Informative References .........................................8 1. Introduction As broadband network designs areto be interpreted as describedchanging from PC-initiated PPPoE [1] sessions inRFC2119 [3]. ATM - Asynchronousa combined Ethernet/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. Introduction With broadband network designs changing from PC initiated PPPoE [1] sessions in a combined Ethernet/ATM setup(ATM) setup, as shown infigureFigure 1, to more intelligentPPPoE capablePPPoE-capable Residential Gateway (RG) and Gigabit Ethernet/ATM broadband networkdesignsdesigns, asshowshown infigureFigures 2 and 3, the need to increase the maximum transmit and receive unit in the PPPoE protocol is becoming more important in order to reduce fragmentation in the network. <------------------ PPPoE session ------------------> +-----+ +-----+ +--+ +---+ | | | | |PC|--------------|CPE|-----------|DSLAM|-----------| BRAS| +--+ <Ethernet> +---+ <ATM> | | <ATM> | | +-----+ +-----+Fig. 1:Figure 1. Initial broadband network designs withPPPoE.PPPoE In the network design shown infigureFigure 1, fragmentation is typically not aproblemproblem, since the subscriber session is PPPoEend-to-endend to end from the PC to theBRAS, soBRAS. Therefore, aPPP negotiatedPPP-negotiated MRU of 1492 octets is fullyacceptableacceptable, as it makes the largest PPPoE frame adhere to the standard Ethernet MTU of 1500 octets. <----- IPoE -----> <--------- PPPoE session ---------> +-----+ +-----+ +--+ +---+ | | | | |PC|--------------| RG|-----------|DSLAM|------------| BRAS| +--+ <Ethernet> +---+ <ATM> | | <GigE> | | +-----+ +-----+Fig. 2: Next generationFigure 2. Next-generation broadband network designs withPPPoE.PPPoE In the network design shown infigureFigure 2, fragmentation becomes a majorproblemproblem, since the subscriber session is a combination of IPoE and PPPoE. The IPoE typicallyuseuses aMTUMaximum Transit Unit (MTU) of 1500 octets. However, when the Residential Gateway and theBRASBroadband Remote Access Server (BRAS) are the PPPoE sessionendpoints,endpoints and therefore negotiateaan MTU/MRU of 1492octets resulting inoctets, the result is a large number of fragmented packets in the network. <----- IPoE -----> <---- PPPoA ----> <- PPPoE session -> +-----+ +-----+ +--+ +---+ | | | | |PC|--------------| RG|------------|DSLAM|------------| BRAS| +--+ <Ethernet> +---+ <ATM> | | <GigE> | | +-----+ +-----+ <-------------- PPPoA -------------> <- PPPoE session -> +-----+ +-----+ +--+ +---+ | | | | |PC|--------------|CPE|------------|DSLAM|------------| BRAS| +--+ <ATM> +---+ <ATM> | | <GigE> | | +-----+ +-----+Fig. 3:Figure 3. Broadband network designs withPPPoA to PPPoE conversion.PPPoA-to-PPPoE conversion In the network design shown infigureFigure 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 inPPPoAPoint-to-Point Protocol over AAL5 (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 a1500 octets1500- octet MRU. Widely deployed PPP/PPPoA hosts inCPE equipmentCustomer Premises Equipment (CPE) do not supportan 1492 octetsa 1492-octet MRU, which creates an issue in turn for the BRAS (PPPoE server) if strict compliance toRFC2516RFC 2516 [1] is mandated. For PPP/PPPoA hosts capable of negotiating a1492 octets1492-octet MRU size, then we are back to a fragmentation issue. 2. 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 RFC 2119 [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 that initiates a PPPoE session PPPoE - server BRAS terminating PPPoE sessions initiated by client PADI - PPPoE Active Discovery Initiation PADO - PPPoE Active Discovery Offer PADR - PPPoE Active Discovery Request PADS - PPPoE Active Discovery Session-confirmation 3. ProposedsolutionSolution The procedure described in this documentdodoes not strictly conform to IEEE standards for Ethernet packetsize,size butrelyrelies on a widely deployed behavior of supportingjumboframesonwith Ethernetsegments.packet format, but exceeding the maximum packet lengths defined by [4]. Sincenext generationnext-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 octets in order to limit the amount of fragmented packets innetwork designs shownnetworks similar to those described insectionSection 1. By default, the Maximum-Receive-Unit (MRU) option MUST follow the rules set forward inRFC1661 [2],RFC 1661 [2] but MUST NOT be negotiated to alargersize larger than 1492 to guarantee compatibility with Ethernet network segments limited to1500 octets1500-octet frames. In such a case, as the PPPoE headerbeingis 6 octets and the PPP Protocol IDbeingis 2 octets, the PPP MRU MUST NOT be greater than 1492. An optional PPPoEtag "PPP-Max-Payload"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 ofa largeran MRU larger than 1492 and the use ofa largeran MTU larger than14921492, subject to limitations of its local configuration and according to the rules set forward inRFC1661RFC 1661 [2],andwithin the limits of the maximum payload sizebeingindicated by the PPPoE client. 4. PPPoE Discovery Stage If a PPPoE client wants to usea higheran MTU/MRU higher than 1492 octets, then it MUST include an optional PPP-Max-Payload Tag in the PADI and PADR packets. If the PPPoE server can supporta higheran MTU/MRU higher than 1492 octets, 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 octets for both the sending and receiving directions. Note that this value represents the PPPpayload, sopayload; therefore it is directly comparable with the value used in the PPP MRU negotiation. 5. LCP Considerations5.15.1. MRU Negotiations Since Ethernet (without jumbo frames) has a maximum payload size of 1500 octets, the PPPoE header is 6octetsoctets, and the PPP Protocol ID is 2 octets, the Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to alargersize larger 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 { PPP_MRU_Max = 1492 If (PPP-Max-Payload-Tag) AND (PPP-Max-Payload-Tag > 1492) Then 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 and greater than 1492, it MUST be considered along with the server's interface MTU settings whenselectingthe maximum value is selected for the normalRFC1661RFC 1661 [2] MRU negotiation which decides the actual MRU to use. If the PPP-Max-Payload tagisn’t present,isn't present or is present but below 1492, then the existing MRU constraint of 1492 octets MUST stay applicable,hencethus preserving backward compatibility.ThisThis, insummarysummary, indicates the following behavior: 1.whenWhen a "PPP-Max-Payload" tag is received, a. the value in this tag will indicate the maximumallowedMRU allowed toaccept and suggestbe accepted or suggested inaan MRUnegotiation,negotiation; and b. if MRU is notnegotiatednegotiated, thenRFC1661RFC 1661 [2] will set the default MRU at 1500. This will say that the "PPP-Max-Payload" tag can have agreatervalue greater than 1500, but in this caseRFC1661RFC 1661 [2] sets the default MRU to 1500, and only if MRU is negotiated higher (up to maximum payload) will the"PPP-Max-Payload""PPP-Max- Payload" tag value be used. 2.whenWhen a"maximum-payload""PPP-Max-Payload" tag is not received by either end, thenRFC2516RFC 2516 [1] sets the rule.5.25.2. MRUtestTest andtroubleshootingTroubleshooting If the MRU is negotiated to alargervalue larger than 1492 octets, the sending side SHOULD have the optionto sendof sending 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 Ethernet segments and equipment can handle such a packet size. If no Echo-Replies are received, the sending side MAY choose to repeat the test with 1492 octets 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 enabled by default. It SHOULD be configurable and MAY be disabled on networks where there is some prior knowledge indicating that the test is not necessary. 6. Security Considerations This document does not introduce new security issues. The security considerations pertaining to the original PPPoE protocol [1] remain relevant. 7. IANA Considerations This document defines a new value in a space that currently has no IANA registry. There is work in progress to define a registry [5] and that document already contains the value assigned here. No IANA action isrequired.required for this document. 8.AcknowledgmentsAcknowledgements 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, DaveBernardBernard, and Darren Nobel for their contributions and comments to this document. 9. Normative References [1]MamakosMamakos, L.,LidlLidl, K.,EvartsEvarts, J.,CarrelCarrel, D.,SimoneSimone, D.,Wheeler R.,and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February19991999. [2]W. SimpsonSimpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July19941994. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Institute of Electrical and Electronic Engineers, IEEE Std 802.3-2005, "IEEE Standard for Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications - Draft amendment to - Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications - Media Access Control Parameters, Physical Layers and Management Parameters", December 2005. 10. Informative References [5] Arberg, P. and V. Mammoliti, "IANA Considerations for PPP over Ethernet (PPPoE), Work in Progress, June 2006. Authors' Addresses Peter Arberg Redback Networks, Inc. 300 Holger Way San Jose, CA 95134Email:EMail: parberg@redback.com Diamantis Kourkouzelis Redback Networks, Inc. 300 Holger Way San Jose, CA 95134Email:EMail: diamondk@redback.com Mike Duckett BellSouth Telecommunications, Inc. 575 Morosgo Drive Atlanta, GA 30324Email:EMail: mike.duckett@bellsouth.com Tom Anschutz BellSouth Science and Technology 725 W. Peachtree St. Atlanta, GA 30308Email:EMail: tom.anschutz@bellsouth.com Jerome Moisand Juniper Networks, Inc. 10 Technology Park Drive Westford, MA 01886Email:EMail: jmoisand@juniper.net Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual PropertyStatementThe IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.Disclaimer of Validity This document andAcknowledgement Funding for theinformation 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. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currentlyRFC Editor function is provided by theInternet Society. Changes from internet-draft version 2. Section "Status of this Memo": changed to include the IPR statement Added a "Copyright Notice" Renamed section 2 from "Motivation" to "Introduction" Section 2: Changed: The IPoE typically negotiate a MTU of 1500 bytes. To: The IPoE typically use a MTU of 1500 octets. Section 5.1: Changed: The pseudo code example. 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) To: If PPPoE { PPP_MRU_Max = 1492 If (PPP-Max-Payload-Tag) AND (PPP-Max-Payload-Tag > 1492) Then PPP_MRU_Max = min (PPP-Max-Payload-Tag, Interface MTU-8) } "Normal" PPP_MRU_Negotiation (PPP_MRU_Max) Changed: 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. To: If the PPP-Max-Payload tag is present and greater than 1492, it MUST be considered along with the server's interface MTU settings when selecting the maximum value for the normal RFC1661 [2] MRU negotiation which decides the actual MRU to use. Changed: If the PPP-Max-Payload tag isn’t present, then the existing MRU constraint of 1492 bytes would stay applicable, hence preserving backward compatibility. To: If the PPP-Max-Payload tag isn’t present, or is present but below 1492, then the existing MRU constraint of 1492 octets MUST stay applicable, hence preserving backward compatibility. Section 5.2: Changed: This capability SHOULD be disabled by default, and SHOULD only be available for debug, test purpose. To: This capability SHOULD be enabled by default. It SHOULD be configurable and MAY be disabled on networks where there is some prior knowledge indicating that the test is not necessary. Added section "7. IANA Considerations" Added section "Intellectual Property Statement" Added section "Disclaimer of Validity" Added section "Copyright Statement" Added section "Acknowledgment" Changed the word bytes to octets in the document. Editorial Changes to remove the "nits" found in v2.IETF Administrative Support Activity (IASA).