One document matched: draft-penno-pppoe-ext-service-01.txt

Differences from draft-penno-pppoe-ext-service-00.txt

Network Working Group                                    Reinaldo Penno
Internet-Draft                                          Nortel Networks
Expires: October, 2001                                   David F. Skoll
                                                        Roaring Penguin  
                                                            April, 2001
                                                         

                                                            
                                                                                                                            
                                                          
                                                          


            PPPoE Extensions For Seamless Service Selection 
                 draft-penno-pppoe-ext-service-01.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 for 
   users to change ISPs or Service they need to manually disconnect and 
   reconnect their PPPoE client.

   We propose here a extension to the PPPoE protocol in which through a 
   new packet type a access concentrator can request a PPPoE client to 
   disconnect and reconnect to a new ISP or Service in a manner 
   transparent to the user



Penno, R.                                                      [Page 1]


Internet-Draft     draft-penno-pppoe-ext-service-01.txt   February,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.      AC-Address TAG_TYPE and TAG_VALUE. . . . . . . . . . . . . 3  
   4.      The PPPoE Active Service Change (PADC) packet . . . . . . .3 
   5.      Deployment Examples. . . . . . . . . . . . . . . . . . . . 4  
   6.      Compatibility with previous PPPoE Clients. . . . . . . . . 5
   7.      Security Considerations. . . . . . . . . . . . . . . . . . 5
   8.      References . . . . . . . . . . . . . . . . . . . . . . . . 5
   9.      Author's Addresses . . . . . . . . . . . . . . . . . . . . 5
           Full Copyright Statement. . . . . . . . . . . . . . . . . .6

































Penno, R.                                                      [Page 2]


Internet-Draft     draft-penno-pppoe-ext-service-01.txt   February,2001



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 for 
   users to change ISPs or Service they need to manually disconnect and 
   reconnect their PPPoE client.

   We propose here a extension to the PPPoE protocol in which through a 
   new packet type a access concentrator can request a PPPoE client to 
   disconnect and reconnect to a new ISP, Service or Device in a manner 
   transparent to the user.

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


3. AC-Address TAG_TYPE and TAG_VALUE

   We introduce a new TAG_TYPE called AC-Address. The description 
   follows.

   0x0111 AC-Address

      This TAG indicates the UTF-8 rendition of the MAC address 
      of a Access concentrator.  It is not NULL terminated.

4. The PPPoE Active Service Change (PADC) packet

   This packet may be sent anytime after a session is established 
   if the AC has reason to believe the subscriber has requested 
   a change in service. It may be sent by Access Concentrator only.  
   The DESTINATION_ADDR field is the unicast Ethernet address of the 
   Host, the CODE field is set to 0xb9 and the SESSION_ID MUST be set 
   to indicate which session is to be terminated. 



Penno, R.                                                      [Page 3]


Internet-Draft     draft-penno-pppoe-ext-service-01.txt   February,2001

   If the subscriber requested a change in service, the AC sends the 
   client a PADC frame with a suggested-service and suggested-AC tag.  
   However, the AC MUST NOT make any changes to the state of the 
   current PPPoE session. 

   Upon receipt of a PADC frame, if the PPPoE client decides that it  
   agrees with the service switch, it MUST send a PADT to the AC to
   terminate the current session. It MUST then send a PADI with the
   indicated service name to the indicated AC.  If it receives no    
   answer, it MAY fall back to sending a PADI with the indicated 
   service name to the broadcast Ethernet address.  If the client 
   decides that it does not agree with the service switch, it simply 
   ignores the PADC and the existing PPPoE session continues 
   unhindered.

   The PADC packet MUST contain at least one TAG of TAG_TYPE Service-
   Name or AC-Address, indicating the Service or the the address of a 
   different Access Concentrator to which the new session MUST be 
   established.
   
5. Deployment Scenarios

   Here we discuss deployment scenarios and how the PADC message with 
   the respective AC-Address and Service-Name TAG-TYPES could be used 
   in a network.
  
    o Service or ISP Change
       
      In this model the user request to change his service profile or 
      ISP, usually through some web page, and Access concentrator 
      then sends a PADC message with a Service-Name TAG_TYPE.

      The web server and the Access concentrator usually communicate
      with each other through some out-of-band mechanism.

    o Access Concentrator Change

      If the Access concentrator experiences a problem, is schedule
      for downtime maintenance, or the access provider wants to provide  
      some form of load balancing, it can send a PADC message to all 
      connected hosts asking them to reconnect to a different Access 
      Concentrator. In this case the PADC message would include just 
      the AC-Address TAG_TYPE.
 
    o Service and Access Concentrator Change

      If the user request a new service or ISP that is not available in 
      the Access Concentrator that it is currently connected, the 
      Access concentrator can send a PADC  message to the host 
      indicating the Address of a Access Concentrator where the
      requested service is available 

Penno, R.                                                      [Page 4]


Internet-Draft     draft-penno-pppoe-ext-service-01.txt   February,2001

6. Compatibility with previous PPPoE Clients [RFC2516]

   If the AC wants to push the client to another AC for maintenance
   or load-balancing purposes, the AC SHOULD send a PADT frame with 
   a suggested-service and suggested-AC tag. The client MUST terminate 
   its PPPoE session. It SHOULD try to establish a new session. It MAY 
   use the suggested-service and suggested-AC tags to guide it in the 
   selection of a new AC, or it MAY ignore them and perform a normal 
   discovery phase. The AC which originally send the PADT frame MUST 
   NOT respond with a PADO unless it is actually willing to establish a 
   session.

7. Security Considerations

   This is a extension to the PPPoE protocol, so the security 
   considerations mentioned therein also apply to this document. 

   This extension was made in a way that the PPPoE client is the final 
   arbiter of whether or not to change services.  It can base its 
   decision on many factors: Maybe it has a database of services it is 
   allowed to switch to.  Maybe when the user goes to the Web site to 
   switch services, the Web page communicates in some way with the 
   PPPoE client telling it to expect a change to a new service.  The 
   PPPoE client will then accept a PADC to the new service if it 
   arrives within a short time.  This makes it harder for outsiders to 
   spoof your identity -- the request for new service must come from 
   the same machine running the PPPoE client.


8. References

   [RFC2516] Mamakos, et. al., "A Method for Transmitting PPP Over 
   Ethernet (PPPoE)", RFC 2516, February 1999

9. Author's Addresses
    
   Reinaldo Penno
   Nortel Networks, Inc. 
   2305 Mission College Boulevard
   Building SC9  
   Santa Clara, CA 95134
   Email: rpenno@nortelnetworks.com 

   David F. Skoll
   Roaring Penguin Software Inc.
   986 Eiffel Avenue
   Ottawa, Ontario
   K2C 0J2 Canada
   Email: dfs@roaringpenguin.com



Penno, R.                                                      [Page 5]


Internet-Draft     draft-penno-pppoe-ext-service-01.txt   February,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.