PPP Extensions Working Group
Internet Draft Peter Arberg
Diamantis Kourkouzelis
Intended status: Informational Redback Networks
Expiration date: September 2006
Mike Duckett
Tom Anschutz
BellSouth
Jerome Moisand
Juniper Networks
March 2006
Accommodating an MTU/MRU greater than 1492 in PPPoE
<draft-arberg-pppoe-mtu-gt1492-03.txt>
Status of 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 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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 9, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
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 September 2006 [Page 1]
Internet Draft PPPoE MRU/MTU Increase March 2006
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. Introduction
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|
+--+ <Ethernet> +---+ <ATM> | | <ATM> | |
+-----+ +-----+
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 octets is
fully acceptable as it makes the largest PPPoE frame adhere to
the standard Ethernet MTU of 1500 octets.
Arberg Expires September 2006 [Page 2]
Internet Draft PPPoE MRU/MTU Increase March 2006
<----- IPoE -----> <--------- PPPoE session --------->
+-----+ +-----+
+--+ +---+ | | | |
|PC|--------------| RG|-----------|DSLAM|------------| BRAS|
+--+ <Ethernet> +---+ <ATM> | | <GigE> | |
+-----+ +-----+
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 use a MTU of 1500 octets.
However, when the Residential Gateway and the BRAS are the PPPoE
session endpoints, and therefore negotiate a MTU/MRU of 1492 octets
resulting in 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: 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 octets MRU. Widely deployed PPP/PPPoA hosts in CPE equipment
do not support an 1492 octets 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 octets
MRU size, then we are back to a fragmentation issue.
Arberg Expires September 2006 [Page 3]
Internet Draft PPPoE MRU/MTU Increase March 2006
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 octets 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 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 MTU/MRU 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 it is directly
comparable with the value used in the PPP MRU negotiation.
Arberg Expires September 2006 [Page 4]
Internet Draft PPPoE MRU/MTU Increase March 2006
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 {
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 for the normal RFC1661 [2] MRU
negotiation which decides the actual MRU to use.
If the PPP-Max-Payload tag isnt present, or is present but below
1492, then the existing MRU constraint of 1492 octets MUST 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 September 2006 [Page 5]
Internet Draft PPPoE MRU/MTU Increase March 2006
5.2 MRU test and troubleshooting
If the MRU is negotiated to a larger value than 1492 octets, 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 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
No IANA action is required.
8. 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.
9. Normative 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.
Arberg Expires September 2006 [Page 6]
Internet Draft PPPoE MRU/MTU Increase March 2006
Authors' Addresses
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.
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
Arberg Expires September 2006 [Page 7]
Internet Draft PPPoE MRU/MTU Increase March 2006
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 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 provided by the
Internet Society.
Arberg Expires September 2006 [Page 8]
Internet Draft PPPoE MRU/MTU Increase March 2006
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 isnt present, then the existing MRU
constraint of 1492 bytes would stay applicable, hence preserving
backward compatibility.
Arberg Expires September 2006 [Page 9]
Internet Draft PPPoE MRU/MTU Increase March 2006
To:
If the PPP-Max-Payload tag isnt 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.
Arberg Expires September 2006 [Page 10]
