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
<draft-arberg-pppoe-mtu-gt1492-00.txt>
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|
+--+ <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 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|
+--+ <Ethernet> +---+ <ATM> | | <GigE> | |
+-----+ +-----+
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|
+--+ <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 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]
