PPP Extensions
Network Working Group
Internet Draft                                              Peter                                          P. Arberg
                                                  Diamantis
Request for Comments: 4638                               D. Kourkouzelis
Intended status:
Category: Informational                                 Redback Networks
Expiration date: September 2006
                                                            Mike
                                                              M. Duckett
                                                            Tom
                                                             T. Anschutz
                                                               BellSouth

                                                          Jerome
                                                              J. Moisand
                                                        Juniper Networks
                                                              March
                                                          September 2006

  Accommodating an MTU/MRU greater than a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU)
                       Greater Than 1492 in PPPoE
                <draft-arberg-pppoe-mtu-gt1492-03.txt> the
             Point-to-Point Protocol over Ethernet (PPPoE)

Status of this This Memo

   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.

   Internet-Drafts are working documents of

   This memo provides information for 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. community.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list does
   not specify an Internet standard of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list any kind.  Distribution of Internet-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 Protocol Over over Ethernet (PPPoE), as described in
   RFC
   2516 [1], 2516, mandates a maximum negotiated MRU Maximum Receive Unit (MRU) of
   1492.  This document outlines a solution to relax that relaxes this
   restriction and allow allows a maximum negotiated MRU greater than 1492 to
   minimize fragmentation in next
   generation next-generation broadband networks.

Table of Contents

   1. Introduction ....................................................2
   2. Terminology

   The 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
   document Troubleshooting ...............................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 are to be interpreted as described changing from PC-initiated PPPoE [1]
   sessions in RFC2119 [3].

      ATM          - Asynchronous a 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 in figure Figure 1, to more intelligent PPPoE capable PPPoE-capable
   Residential Gateway (RG) and Gigabit Ethernet/ATM broadband network designs
   designs, as show shown in figure Figures 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 with PPPoE. PPPoE

   In the network design shown in figure Figure 1, fragmentation is typically
   not a problem problem, since the subscriber session is PPPoE end-to-end end to end from
   the PC to the BRAS, so BRAS.  Therefore, a PPP negotiated PPP-negotiated MRU of 1492 octets
   is fully acceptable acceptable, 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 generation

     Figure 2.  Next-generation broadband network designs with PPPoE. PPPoE

   In the network design shown in figure Figure 2, fragmentation becomes a
   major problem problem, since the subscriber session is a combination of IPoE
   and PPPoE.  The IPoE typically use uses a MTU Maximum Transit Unit (MTU) of
   1500 octets.  However, when the Residential Gateway and the BRAS Broadband
   Remote Access Server (BRAS) are the PPPoE session endpoints, endpoints and
   therefore negotiate a an MTU/MRU of 1492 octets
    resulting in octets, 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 with PPPoA to PPPoE conversion. PPPoA-to-PPPoE conversion

   In the network design shown in figure 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 Point-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 a
    1500 octets 1500-
   octet MRU.  Widely deployed PPP/PPPoA hosts in CPE equipment Customer Premises
   Equipment (CPE) do not support an 1492 octets a 1492-octet MRU, which creates an
   issue in turn for the BRAS (PPPoE server) if strict compliance to RFC2516 RFC
   2516 [1] is mandated.  For PPP/PPPoA hosts capable of negotiating a 1492 octets
   1492-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.  Proposed solution Solution

   The procedure described in this document do does not strictly conform to
   IEEE standards for Ethernet packet size, size but rely relies on a widely
   deployed behavior of supporting jumbo frames on with Ethernet segments. packet format,
   but exceeding the maximum packet lengths defined by [4].

   Since next generation 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
   octets in order to limit the amount of fragmented packets in
   network designs shown networks
   similar to those described in section Section 1.

   By default, the Maximum-Receive-Unit (MRU) option MUST follow the
   rules set forward in RFC1661 [2], RFC 1661 [2] but MUST NOT be negotiated to a
   larger
   size larger than 1492 to guarantee compatibility with Ethernet
   network segments limited to 1500 octets 1500-octet frames.  In such a case, as
   the PPPoE header being is 6 octets and the PPP Protocol ID being is 2 octets, the
   PPP MRU MUST NOT be greater than 1492.

   An optional PPPoE tag "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 of a larger an MRU larger than 1492 and the
   use of a larger an MTU larger than 1492 1492, subject to limitations of its local
   configuration and according to the rules set forward in RFC1661 RFC 1661 [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 an 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 support a higher an 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 PPP payload, so payload; therefore it is directly comparable with
   the value used in the PPP MRU negotiation.

5.  LCP Considerations

5.1

5.1.  MRU Negotiations

   Since Ethernet (without jumbo frames) has a maximum payload size of
   1500 octets, the PPPoE header is 6 octets octets, and the PPP Protocol ID is
   2 octets, the Maximum-Receive-Unit (MRU) option MUST NOT be
   negotiated to a larger size 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 when
   selecting the
   maximum value is selected for the normal RFC1661 RFC 1661 [2] MRU negotiation
   which decides the actual MRU to use.

   If the PPP-Max-Payload tag isn’t present, isn't present or is present but below
   1492, then the existing MRU constraint of 1492 octets MUST stay
   applicable, hence thus preserving backward compatibility.

   This

   This, in summary summary, indicates the following behavior:

   1. when  When a "PPP-Max-Payload" tag is received,

      a. the value in this tag will indicate the maximum allowed MRU allowed to accept and suggest
         be accepted or suggested in a an MRU negotiation, negotiation; and

      b. if MRU is not negotiated negotiated, then RFC1661 RFC 1661 [2] will set the
         default MRU at 1500.  This will say that the "PPP-Max-Payload"
         tag can have a greater value greater than 1500, but in this case RFC1661 RFC
         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. when  When a "maximum-payload" "PPP-Max-Payload" tag is not received by either end, then RFC2516
       RFC 2516 [1] sets the rule.

5.2

5.2.  MRU test Test and troubleshooting Troubleshooting

   If the MRU is negotiated to a larger value larger than 1492 octets, the
   sending side SHOULD have the option to send of 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 is required. required for this document.

8. Acknowledgments  Acknowledgements

   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
   Bernard, and Darren Nobel for their contributions and comments to
   this document.

9.  Normative References

   [1] Mamakos  Mamakos, L., Lidl Lidl, K., Evarts Evarts, J., Carrel Carrel, D., Simone Simone, D., Wheeler R., and
        R. Wheeler, "A Method for Transmitting PPP Over Ethernet
        (PPPoE)", RFC 2516, February 1999 1999.

   [2] W. Simpson  Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
        1661, July 1994 1994.

   [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 95134

   Email:

   EMail: parberg@redback.com

   Diamantis Kourkouzelis
   Redback Networks, Inc.
   300 Holger Way
   San Jose, CA 95134

   Email:

   EMail: diamondk@redback.com

   Mike Duckett
   BellSouth Telecommunications, Inc.
   575 Morosgo Drive
   Atlanta, GA 30324

   Email:

   EMail: mike.duckett@bellsouth.com

   Tom Anschutz
   BellSouth Science and Technology
   725 W. Peachtree St.
   Atlanta, GA 30308

   Email:

   EMail: tom.anschutz@bellsouth.com

   Jerome Moisand
   Juniper Networks, Inc.
   10 Technology Park Drive
   Westford, MA 01886

   Email:

   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 Property Statement

   The 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 and

Acknowledgement

   Funding for 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.

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 currently RFC Editor function is provided by the
   Internet 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).