Network Working Group Reinaldo Penno Internet-Draft Nortel Networks Expires: December, 2001 YouSong FiberHome Networks August,2001 PPPoE Extensions For QoS draft-penno-pppoe-ext-qos-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract In the year following the publication of the PPPoE protocol much operational experience and customer feedback was gathered. One problem that access providers usually mention is that in order to change QoS on a connection for a specific user, they have to provision some central database (for instance, Radius) and also have do it every time the user wants to make a change. We propose here a extension to the PPPoE protocol in which through a new TAG_TYPES a client can request from an access concentrator certain QoS guarantees Penno, R. [Page 1] Internet-Draft draft-penno-pppoe-ext-qos-00.txt August,2001 Specification of Requirements The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [1]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction to the PPPoE Protocol. . . . . . . . . . . . .3 3. New TAG_TYPEs and TAG_VALUEs . . . . . . . . . . . . . . . 3 4. Negotiation Phase. . . . . . . . . . . . . . . . . . . . . 4 5. Qos Extensions and [PPPoE Service] . . . . . . . . . . . . 5 6. Security Considerations. . . . . . . . . . . . . . . . . . 5 7. References. . . . . . . . . . . . . . . . . . . . . . . . 5 8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . 5 9. Author's Addresses . . . . . . . . . . . . . . . . . . . . 6 10. Full Copyright Statement . . . . . . . . . . . . . . . . . 5 1. Introduction In the year following the publication of the PPPoE protocol much operational experience and customer feedback was gathered. One problem that access providers usually mention is that in order to change QoS on a connection for a specific user, they have to provision some central database (for instance, Radius) and also have do it every time the user wants to make a change. We propose here a extension to the PPPoE protocol in which through a new TAG_TYPES a client can request from an access concentrator certain QoS guarantees 2. Introduction to the PPPoE Protocol The PPPoE protocol is relatively new, but its basic function is to encapsulate PPP packets into Ethernet frames that will be de- encapsulated by the tunnel termination device. The PPPoE protocol has two stages; session and discover. PPP session packets are encapsulated in the Ethernet frame with the Ethertype equal to 0x8864. The Ethertype 0x8863 is used during the discovering stage, where the user's PPPoE client tries to identify the device that will terminate the PPPoE session. To obtain further and more in depth information on the PPPoE protocol refer to [RFC2516]. Penno, R. [Page 2] Internet-Draft draft-penno-pppoe-ext-qos-00.txt August,2001 3. New TAG_TYPEs and TAG_VALUEs 0x0401 Host-UpStream-Bandwidth This tag is used by a host to indicate the bandwidth which he wants in host-to-AC direction. This tag's Tag_length must be 2, the tag_value is the UpStream bandwidth value in Kbps to this host. If tag_value is 0, it shows that any bandwidth is acceptable to this host .If a host doesn't include this tag and PADR, AC can think any bandwidth is acceptable to this host. 0x0402 Host-DownStream-Bandwidth This tag is used by a host to indicate the bandwidth which he wants in AC-to-host direction. This tag's Tag_length must be 2, the tag_value is the UpStream bandwidth value in Kbps to this host. If tag_value is 0, it shows that any bandwidth is acceptable to this host .If a host doesn't include this tag and PADR, AC can think any bandwidth is acceptable to this host. 0x0403 Acceptable-PacketLoss-ratio This tag is used by a host to indicate the acceptable packet loss ratio in AC-to-host direction for this host. This tag is meaningless to the applications based on TCP, but is meaning for applications based on UDP. AC-Upstream Diffserv Marking [TBD] AC-Downstream Diffserv Marking [TBD] 4. Negotiation Phase The client send a PADI message with the QoS parameters it wants. The PPPoE aggregators then could get those parameters and check to see if they can be honored. The aggregator then can send a PADO message with the QoS parameters it can offer or if it realizes it cannot offer the requested parameters it MAY not send a PADO message The client then receives possibly several PADO from different aggregators saying which QoS parameters they can offer. Penno, R. [Page 3] Internet-Draft draft-penno-pppoe-ext-qos-00.txt August,2001 The PPPoE client makes a choice amongst the possibly several options and based on some other restrictions like such as Service-Name sends a PADR to the appropriate aggregator. Optionally the client could send the QoS parameters requested only on the PADR message, followed by a PADS from the aggregator with the currently allocated QoS parameters. 5. QoS Extensions and [PPPoE-Service] The QoS parameters proposed here can be changed dynamically during a session using the method described in [PPPoE-Service]. 6. Security Considerations [TBD] 7. References [RFC2516] Mamakos, et. al., "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999 [PPPoE-Service] Penno, et al. "PPPoE Extensions For Seamless Service Selection", draft-penno-pppoe-ext-service-03.txt, June 2001, Work in Progress [PPPoE-Mutlicast] YouSong, et al.,"IP multicasting and broadcasting extension for PPPoE Protocol, draft-yousong-pppoe-multicast-00.txt, August 2001, Work in Progress 8. Acknowledgments [TBD] 9. Author's Addresses Reinaldo Penno Nortel Networks, Inc. 2305 Mission College Boulevard Building SC9-B1240 Santa Clara, CA 95134 Email: rpenno@nortelnetworks.com You Song, FiberHome Networks Inc. 88,YouKeyuan lu,Hongshan District,Wuhan,Hubei Prov., P.R.China 430074 Email: syou@wri.com.cn Penno, R. [Page 4] Internet-Draft draft-penno-pppoe-ext-qos-00.txt August,2001 10. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 11. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society.