Network Working Group Reinaldo Penno
Internet-Draft Nortel Networks
Expires: December, 2001 David F. Skoll
Roaring Penguin
June, 2001
PPPoE Extensions For Seamless Service Selection
draft-penno-pppoe-ext-service-03.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
Another related problem is that to add a new PPPoE session to some
other ISP or for a different service, users also need to manually
connect
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 or to connect to a new ISP or Service in a
manner transparent to the user
Penno, R. [Page 1]
Internet-Draft draft-penno-pppoe-ext-service-02.txt June,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. The PPPoE Active Service Change (PADC) packet . . . . . . .3
4.1 Multiple PPPoE Sessions from the same client. . . . . . . .4
5. Deployment Examples. . . . . . . . . . . . . . . . . . . . 5
6. Compatibility with previous PPPoE Clients. . . . . . . . . 5
7. Security Considerations. . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . 5
9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . 6
10. Author's Addresses . . . . . . . . . . . . . . . . . . . . 5
Full Copyright Statement. . . . . . . . . . . . . . . . . .6
Penno, R. [Page 2]
Internet-Draft draft-penno-pppoe-ext-service-02.txt June,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.
Another related problem is that to add a new PPPoE session to some
other ISP or for a different service, users also need to explicit go
through the connection process.
We propose here a extension to the PPPoE protocol in which through a
new packet type, an access concentrator can request a PPPoE client
to disconnect and reconnect or to open a new session 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. New TAG_TYPEs and TAG_VALUEs
We introduce four new TAG_TYPEs called AC-Address, AC-Connect,
AC-Disconnect and AC-Session . The description follows.
0x0111 AC-Address
This TAG contains the MAC address of an Access concentrator
in binary format or the broadcast ethernet address. It is not
NULL terminated.
0x0112 AC-Connect
This TAG indicates that a new session should be established
without disconnecting the current session(s).
Penno, R. [Page 3]
Internet-Draft draft-penno-pppoe-ext-service-02.txt June,2001
0x0113 AC-Disconnect
This TAG indicates that a new session should be established and
some of the sessions already established should be 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 an 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.
If the subscriber requested a change in service, the AC sends the
client a PADC frame with Service-Name and AC-address TAG_TYPESs.
However, the AC MUST NOT make any changes to the state of the
current PPPoE session.
Upon receipt of a PADC frame, the PPPoE client MUST first check to
see if the source MAC address belongs to an AC that the client has
an active session. Then, 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.
4.1 Multiple PPPoE Sessions from the same client.
Optionally if the PADC contains an AC-Disconnect TAG_TYPE, only the
PPPoE session associated with the SESSION_ID will be disconnected.
Penno, R. [Page 4]
Internet-Draft draft-penno-pppoe-ext-service-02.txt June,2001
This means that although the PADC was received through some session,
the resquest is for the client to terminate other sessions and not
the one through which the PADC was received on. This PPPoE session
can be envisioned as a "control" PPPoE session.
If the PADC contains an AC-Connect besides the TAG_TYPE Service-
Name, this means that a new session should be established for the
service indicated without disconnecting current session(s).
5. Deployment Examples
Here we discuss deployment scenarios and how the PADC message with
the new TAG-TYPEs introduced 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 scheduled
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.
There are also cases where is possible to have the broadcast
Ethernet address in the AC-Address TAG_TYPE. For example, if the
access provider has a pool AC's, and one is about to go down, it
wants all of its sessions to terminate the hosts to reconnect,
does not particularly care which AC they reconnect to -- any AC
in the pool will do. This could be indicated by making the AC-
Address the broadcast Ethernet address.
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 5]
Internet-Draft draft-penno-pppoe-ext-service-02.txt June,2001
o Delivery of Value Added Content
Sometimes a Content Provider that has a partnership with the ISP
or the ISP itself provides some value added content such as video
or music on demand. So, when the user clicks on a web page to
request special content, a PADC message with AC-connect and
Service-Name TAG_TYPEs would be sent to the client requesting
that it opens a new session to have access to such
value added content. Having a separate unique session to access
value added content provides easier QoS control, billing and
accounting.
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
Service-Name and AC-address TAG_TYPES. The client MUST terminate
its PPPoE session. It SHOULD try to establish a new session. It MAY
use the Service-Name and AC-Address 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 sent 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. Acknowledgments
Thanks to Seetha Kodiyalam from NortelNetworks and the developers at
Broadjump Inc.
Penno, R. [Page 6]
Internet-Draft draft-penno-pppoe-ext-service-02.txt June,2001
10. 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
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.