idnits 2.17.1 draft-arberg-pppoe-mtu-gt1492-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 358. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 335. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 342. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 348. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 4 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2006) is 6589 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PPP Extensions Working Group 2 Internet Draft Peter Arberg 3 Diamantis Kourkouzelis 4 Intended status: Informational Redback Networks 5 Expiration date: September 2006 6 Mike Duckett 7 Tom Anschutz 8 BellSouth 10 Jerome Moisand 11 Juniper Networks 12 March 2006 14 Accommodating an MTU/MRU greater than 1492 in PPPoE 15 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on September 9, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2006). 46 Abstract 48 Point-to-Point Protocol Over Ethernet (PPPoE), as described in RFC 49 2516 [1], mandates a maximum negotiated MRU of 1492. This document 50 outlines a solution to relax that restriction and allow a maximum 51 negotiated MRU greater than 1492 to minimize fragmentation in next 52 generation broadband networks. 54 1. Terminology 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in RFC2119 [3]. 60 ATM - Asynchronous Transfer Mode . 61 PPP - Point-to-Point Protocol. 62 PPPoA - PPP over AAL5. 63 PPPoE - PPP over Ethernet. 64 MTU - Maximum Transmit Unit 65 MRU - Maximum Receive Unit 66 PC - Personal Computer. 67 CPE - Customer Premises Equipment. 68 RG - Residential Gateway. 69 BRAS - Broadband Remote Access Server. 70 DSLAM � Digital Subscriber Line Access Multiplexer 71 PPPoE client - PC, RG or CPE which initiates a PPPoE session 72 PPPoE server - BRAS terminating PPPoE sessions initiated by client 74 2. Introduction 76 With broadband network designs changing from PC initiated PPPoE [1] 77 sessions in a combined Ethernet/ATM setup as shown in figure 1, to 78 more intelligent PPPoE capable Residential Gateway (RG) and 79 Gigabit Ethernet/ATM broadband network designs as show in figure 2 80 and 3, the need to increase the maximum transmit and receive unit in 81 the PPPoE protocol is becoming more important to reduce fragmentation 82 in the network. 84 <------------------ PPPoE session ------------------> 86 +-----+ +-----+ 87 +--+ +---+ | | | | 88 |PC|--------------|CPE|-----------|DSLAM|-----------| BRAS| 89 +--+ +---+ | | | | 90 +-----+ +-----+ 92 Fig. 1: Initial broadband network designs with PPPoE. 94 In the network design shown in figure 1, fragmentation is typically 95 not a problem since the subscriber session is PPPoE end-to-end from 96 the PC to the BRAS, so a PPP negotiated MRU of 1492 octets is 97 fully acceptable as it makes the largest PPPoE frame adhere to 98 the standard Ethernet MTU of 1500 octets. 100 <----- IPoE -----> <--------- PPPoE session ---------> 102 +-----+ +-----+ 103 +--+ +---+ | | | | 104 |PC|--------------| RG|-----------|DSLAM|------------| BRAS| 105 +--+ +---+ | | | | 106 +-----+ +-----+ 108 Fig. 2: Next generation broadband network designs with PPPoE. 110 In the network design shown in figure 2, fragmentation becomes a 111 major problem since the subscriber session is a combination of 112 IPoE and PPPoE. The IPoE typically use a MTU of 1500 octets. 113 However, when the Residential Gateway and the BRAS are the PPPoE 114 session endpoints, and therefore negotiate a MTU/MRU of 1492 octets 115 resulting in a large number of fragmented packets in the network. 117 <----- IPoE -----> <---- PPPoA ----> <- PPPoE session -> 119 +-----+ +-----+ 120 +--+ +---+ | | | | 121 |PC|--------------| RG|------------|DSLAM|------------| BRAS| 122 +--+ +---+ | | | | 123 +-----+ +-----+ 125 <-------------- PPPoA -------------> <- PPPoE session -> 127 +-----+ +-----+ 128 +--+ +---+ | | | | 129 |PC|--------------|CPE|------------|DSLAM|------------| BRAS| 130 +--+ +---+ | | | | 131 +-----+ +-----+ 133 Fig. 3: Broadband network designs with PPPoA to PPPoE conversion. 135 In the network design shown in figure 3, which is studied by the 136 DSL-Forum in the context of the migration to Ethernet for broadband 137 aggregation networks, fragmentation is not the only problem when 138 MRU differences exist in PPPoA and PPPoE sessions. 140 The subscriber session is a PPP session running over a combination 141 of PPPoA and PPPoE. The PPP/PPPoA host typically negotiates a 142 1500 octets MRU. Widely deployed PPP/PPPoA hosts in CPE equipment 143 do not support an 1492 octets MRU, which creates an issue in turn 144 for the BRAS (PPPoE server) if strict compliance to RFC2516 [1] is 145 mandated. For PPP/PPPoA hosts capable of negotiating a 1492 octets 146 MRU size, then we are back to a fragmentation issue. 148 3. Proposed solution 150 The procedure described in this document do not strictly conform 151 to IEEE standards for Ethernet packet size, but rely on a widely 152 deployed behavior of supporting jumbo frames on Ethernet segments. 154 Since next generation broadband networks are built around Ethernet 155 systems supporting baby-giants and jumbo frames with payload sizes 156 larger than the normal Ethernet MTU of 1500 octets, a BRAS acting 157 as a PPPoE server MUST support PPPoE MRU negotiations larger than 158 1492 octets in order to limit the amount of fragmented packets in 159 network designs shown in section 1. 161 By default, the Maximum-Receive-Unit (MRU) option MUST follow the 162 rules set forward in RFC1661 [2], but MUST NOT be negotiated to a 163 larger size than 1492 to guarantee compatibility with Ethernet 164 network segments limited to 1500 octets frames. In such a case, 165 the PPPoE header being 6 octets and the PPP Protocol ID being 166 2 octets, the PPP MRU MUST NOT be greater than 1492. 168 An optional PPPoE tag "PPP-Max-Payload" allows a PPPoE client to 169 override this default behavior by providing a maximum size for the 170 PPP payload it can support in both the sending and receiving 171 directions. When such a tag is received by the PPPoE server, the 172 server MAY allow the negotiation of a larger MRU than 1492 and the 173 use of a larger MTU than 1492 subject to limitations of its local 174 configuration and according to the rules set forward in RFC1661 [2], 175 and within the limits of the maximum payload size being indicated by 176 the PPPoE client. 178 4. PPPoE Discovery Stage 180 If a PPPoE client wants to use a higher MTU/MRU than 1492 octets, 181 then it MUST include an optional PPP-Max-Payload Tag in the PADI 182 and PADR packets. 183 If the PPPoE server can support a higher MTU/MRU than 1492 octets, it 184 MUST respond with an echo of the clients tag in the PADO and PADS 185 packets when the PPP-Max-Payload tag is received from the client. 187 Tag-name: PPP-Max-Payload 188 Tag-value: 0x0120 189 Tag-length: 2 octets 190 Tag-value: binary encoded value (max PPP payload in octets) 192 Tag-description: 193 This TAG indicates that the client and server are capable of 194 supporting a given maximum PPP payload greater than 1492 octets for 195 both the sending and receiving directions. 196 Note that this value represents the PPP payload, so it is directly 197 comparable with the value used in the PPP MRU negotiation. 199 5. LCP Considerations 201 5.1 MRU Negotiations 203 Since Ethernet (without jumbo frames) has a maximum payload size of 204 1500 octets, the PPPoE header is 6 octets and the PPP Protocol ID is 205 2 octets, the Maximum-Receive-Unit (MRU) option MUST NOT be 206 negotiated to a larger size than 1492, unless both the PPPoE client 207 and server have indicated the ability to support a larger MRU in the 208 PPPoE Discovery Stage. 210 The initial MRU negotiation for the PPP/PPPoE server MUST follow a 211 flow as shown below: 213 If PPPoE { 214 PPP_MRU_Max = 1492 215 If (PPP-Max-Payload-Tag) AND (PPP-Max-Payload-Tag > 1492) 216 Then PPP_MRU_Max = min (PPP-Max-Payload-Tag, Interface MTU-8) 217 } 218 "Normal" PPP_MRU_Negotiation (PPP_MRU_Max) 220 If the PPP-Max-Payload tag is present and greater than 1492, it MUST 221 be considered along with the server's interface MTU settings when 222 selecting the maximum value for the normal RFC1661 [2] MRU 223 negotiation which decides the actual MRU to use. 225 If the PPP-Max-Payload tag isn�t present, or is present but below 226 1492, then the existing MRU constraint of 1492 octets MUST stay 227 applicable, hence preserving backward compatibility. 229 This in summary indicates the following behavior: 230 1. when a "PPP-Max-Payload" tag is received, 231 a. the value in this tag will indicate the maximum allowed 232 MRU to accept and suggest in a MRU negotiation, 233 b. if MRU is not negotiated then RFC1661 [2] will set the default 234 MRU at 1500. This will say that the "PPP-Max-Payload" tag can 235 have a greater value than 1500, but in this case RFC1661 [2] 236 sets the default MRU to 1500, and only if MRU is negotiated 237 higher (up to maximum payload) will the "PPP-Max-Payload" tag 238 value be used. 240 2. when a "maximum-payload" tag is not received by either end, 241 then RFC2516 [1] sets the rule. 243 5.2 MRU test and troubleshooting 245 If the MRU is negotiated to a larger value than 1492 octets, the 246 sending side SHOULD have the option to send one or more MRU-sized 247 Echo-Request packets once the session is opened. This allows it to 248 test that the receiving side and any intermediate equipment can 249 handle such packet size. 250 If no Echo-Replies are received, the sending side MAY choose to 251 repeat the test with 1492 octets Echo-Request packets. If these 252 packets receive replies, the sending side MUST not send packets 253 bigger than 1492 octets for this session. 255 This capability SHOULD be enabled by default. It SHOULD be 256 configurable and MAY be disabled on networks where there is some 257 prior knowledge indicating that the test is not necessary. 259 6. Security Considerations 261 This document does not introduce new security issues. The security 262 considerations pertaining to the original PPPoE protocol [1] remain 263 relevant. 265 7. IANA Considerations 267 No IANA action is required. 269 8. Acknowledgments 271 The authors would like to thank Prakash Jayaraman, Amit Cohen, 272 Jim Ellis, David Thorne, John Reid, Oliver Thorp, Wojciech Dec, 273 Jim Wilks, Mark Townsley, Bart Salaets, Tom Mistretta, Paul Howard, 274 Dave Bernard and Darren Nobel for their contributions and comments 275 to this document. 277 9. Normative References 279 [1] Mamakos L., Lidl K., Evarts J., Carrel D., Simone D., Wheeler R., 280 "A Method for Transmitting PPP Over Ethernet (PPPoE)", 281 RFC 2516, February 1999 283 [2] W. Simpson "The Point-to-Point Protocol (PPP)", RFC 1661, 284 July 1994 286 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 287 Levels", BCP 14, RFC 2119, March 1997. 289 Authors' Addresses 291 Peter Arberg 292 Redback Networks, Inc. 293 300 Holger Way 294 San Jose, CA 95134 296 Email: parberg@redback.com 298 Diamantis Kourkouzelis 299 Redback Networks, Inc. 300 300 Holger Way 301 San Jose, CA 95134 303 Email: diamondk@redback.com 305 Mike Duckett 306 BellSouth Telecommunications, Inc. 307 575 Morosgo Drive 308 Atlanta, GA 30324 310 Email: mike.duckett@bellsouth.com 312 Tom Anschutz 313 BellSouth Science and Technology 314 725 W. Peachtree St. 315 Atlanta, GA 30308 317 Email: tom.anschutz@bellsouth.com 319 Jerome Moisand 320 Juniper Networks, Inc. 321 10 Technology Park Drive 322 Westford, MA 01886 324 Email: jmoisand@juniper.net 326 Intellectual Property Statement 328 The IETF takes no position regarding the validity or scope of any 329 Intellectual Property Rights or other rights that might be claimed to 330 pertain to the implementation or use of the technology described in 331 this document or the extent to which any license under such rights 332 might or might not be available; nor does it represent that it has 333 made any independent effort to identify any such rights. Information 334 on the procedures with respect to rights in RFC documents can be 335 found in BCP 78 and BCP 79. 337 Copies of IPR disclosures made to the IETF Secretariat and any 338 assurances of licenses to be made available, or the result of an 339 attempt made to obtain a general license or permission for the use of 340 such proprietary rights by implementers or users of this 341 specification can be obtained from the IETF on-line IPR repository at 342 http://www.ietf.org/ipr. 344 The IETF invites any interested party to bring to its attention any 345 copyrights, patents or patent applications, or other proprietary 346 rights that may cover technology that may be required to implement 347 this standard. Please address the information to the IETF at 348 ietf-ipr@ietf.org. 350 Disclaimer of Validity 352 This document and the information contained herein are provided on an 353 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 354 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 355 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 356 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 357 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 358 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 360 Copyright Statement 362 Copyright (C) The Internet Society (2006). This document is subject 363 to the rights, licenses and restrictions contained in BCP 78, and 364 except as set forth therein, the authors retain all their rights. 366 Acknowledgment 368 Funding for the RFC Editor function is currently provided by the 369 Internet Society. 371 Changes from internet-draft version 2. 373 Section "Status of this Memo": changed to include the IPR statement 375 Added a "Copyright Notice" 377 Renamed section 2 from "Motivation" to "Introduction" 379 Section 2: 380 Changed: The IPoE typically negotiate a MTU of 1500 bytes. 381 To: The IPoE typically use a MTU of 1500 octets. 383 Section 5.1: 384 Changed: The pseudo code example. 385 If PPPoE { 386 If (PPP-Max-Payload-Tag) Not Present 387 Then PPP_MRU_Max = 1492 388 Else PPP_MRU_Max = min (PPP-Max-Payload-Tag, Interface MTU-8) 389 } 390 "Normal" PPP_MRU_Negotiation (PPP_MRU_Max) 392 To: If PPPoE { 393 PPP_MRU_Max = 1492 394 If (PPP-Max-Payload-Tag) AND (PPP-Max-Payload-Tag > 1492) 395 Then PPP_MRU_Max = min (PPP-Max-Payload-Tag, Interface MTU-8) 396 } 397 "Normal" PPP_MRU_Negotiation (PPP_MRU_Max) 399 Changed: 400 If the PPP-Max-Payload tag is present, it MUST be considered as the 401 maximum value for the "normal" MRU negotiation which is the master 402 and decision maker of what the actual MRU will be negotiated to, 403 never higher than the PPP-Max-Payload tag, but it can be negotiated 404 to a lower value depending on the server's interface settings and 405 the peer's negotiated MRU value. 407 To: 408 If the PPP-Max-Payload tag is present and greater than 1492, it MUST 409 be considered along with the server's interface MTU settings when 410 selecting the maximum value for the normal RFC1661 [2] MRU 411 negotiation which decides the actual MRU to use. 413 Changed: 414 If the PPP-Max-Payload tag isn�t present, then the existing MRU 415 constraint of 1492 bytes would stay applicable, hence preserving 416 backward compatibility. 418 To: 419 If the PPP-Max-Payload tag isn�t present, or is present but below 420 1492, then the existing MRU constraint of 1492 octets MUST stay 421 applicable, hence preserving backward compatibility. 423 Section 5.2: 424 Changed: This capability SHOULD be disabled by default, and SHOULD 425 only be available for debug, test purpose. 427 To: This capability SHOULD be enabled by default. It SHOULD be 428 configurable and MAY be disabled on networks where there is 429 some prior knowledge indicating that the test is not 430 necessary. 432 Added section "7. IANA Considerations" 433 Added section "Intellectual Property Statement" 434 Added section "Disclaimer of Validity" 435 Added section "Copyright Statement" 436 Added section "Acknowledgment" 438 Changed the word bytes to octets in the document. 439 Editorial Changes to remove the "nits" found in v2.