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

. 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

. 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


. 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]


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

. QoS Extensions and [PPPoE-Service]

   The QoS parameters proposed here can be changed dynamically during a
   session using the method described in [PPPoE-Service].

. Security Considerations

   [TBD]

. 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

. Acknowledgments

   [TBD]

. 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


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

. Acknowledgement

   Funding for the RFC editor function is currently provided by the
   Internet Society.