Internet DRAFT - draft-haag-pppext-spppoe
draft-haag-pppext-spppoe
Network Working Group Jeffrey Haag
Internet-Draft Vince Mammoliti
<draft-haag-pppext-spppoe-00.txt> W. Mark Townsley
February 2005 cisco Systems
Simple PPP over Ethernet (sPPPoE)
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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 (2004). All Rights Reserved.
Abstract
This document defines a simple method for carrying PPP frames over
Ethernet. PPP control packets are carried over a PPP ethertype,
while IP packets may be carried as native IP over Ethernet. This has
particular application in migration of ATM access networks to
Ethernet.
Haag, Mammoliti, Townsley Informational [Page 1]
INTERNET DRAFT Simple PPP over Ethernet (sPPPoE) February 2005
Contents
Status of this Memo.......................................... 1
1. Introduction.............................................. 2
2. Protocol Overview......................................... 4
2.1 "Upstream" (CPE to BRAS) Encapsulation................ 5
2.2 "Downstream" (BRAS to CPE) Encapsulation.............. 6
2.3 Determination of BRAS MAC Address..................... 7
2.3.1 IP-Directed...................................... 7
2.3.2 Active Discovery................................. 8
3.0 PPP Packet Flow between PPPoA and sPPPoE.............. 8
3.1 PPP LCP............................................... 8
3.2 PPP Authentication.................................... 9
3.3 PPP IPCP.............................................. 9
4. Security Considerations................................... 10
5. IANA Considerations....................................... 10
6. Acknowledgments........................................... 10
7. References................................................ 10
7.1 Normative References.................................. 10
7.2 Informative References................................ 10
8. Contacts.................................................. 10
Specification of Requirements
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in [RFC2119].
1. Introduction
This document defines a simple method for carrying PPP frames over
Ethernet (sPPPoE). PPP control packets are carried over a PPP
ethertype, while IP packets may be carried as native IP over
Ethernet. Unlike PPPoE defined in [RFC2516], this protocol involves
no control plane (beyond what PPP already has) and does not have any
additional encapsulation between the PPP and ethernet framing.
This method of PPP over Ethernet encapsulation has particular
Haag, Mammoliti, Townsley Informational [Page 2]
INTERNET DRAFT Simple PPP over Ethernet (sPPPoE) February 2005
application in migration of ATM access networks to Ethernet. In one
common deployment of Digital Subscriber Line (DSL) access networks, a
Digital Subscriber Line Access Module (DSLAM) sits on an ATM network
between a Broadband Remote Access Server (BRAS) and Customer Premise
Equipment (CPE) devices. The subscriber connection between the CPE
and BRAS is often PPPoA [RFC2364]. This particular migration
deployment scenario is give as Figure 1 and referenced throughout
this document.
PPPoA sPPPoE
CPE ---------- DSLAM ------------ BRAS
ATM GigE
Figure 1: ATM to GigE DSL Migration
The ATM access network for DSL is facing a migration to switched
Gigabit Ethernet (GigE) networks. As this migration occurs in stages,
it is desirable to be able to keep the PPPoA CPEs and DSL connection
between the CPE and DSLAM as ATM, while migrating the network between
the DSLAM and the BRAS. This creates a need for the DSLAM to switch
PPP frames over ATM (PPPoA) towards the CPE, PPP over GigE towards
the BRAS, and vice-versa. This document focuses on a mechanism to
transport PPP control and data packets across an ATM network to a
GigE network, so that the PPP Session will terminate at a BRAS on the
GigE network. There may be other uses for Simplified PPPoE
encapsulation, but they are currently outside the scope of this
document.
One method for would be to create an Interworking Function (IWF) for
PPPoA [RFC2364] to PPPoE [RFC2516]. Such an IWF would need to solve
difficult problems, including:
- 1492 Maximum MTU in PPPoE, where PPPoA CPEs are commonly
deployed with a 1500 byte MRU. While PPP should negotiate down to
1492, this would not be transparent to the CPE, and could be
noticable to the end-user.
- Messages used in PPPoE (undocumented extensions in some cases)
which the BRAS may expect to be delivered to the user, would in
fact stop at the DSLAM.
- Inconsistency between state of BRAS, DSLAM and CPE, exacerbated
by the PPPoE PADT message sent from the BRAS being defined
optional and unreliable (not retransmitted).
In short, a PPPoA to PPPoE IWF may be noticeable to a PPPoA CPE, and
may require changes to processing at the BRAS. Thus, the IWF is not
transparent to entities on either side of the DSLAM.
Haag, Mammoliti, Townsley Informational [Page 3]
INTERNET DRAFT Simple PPP over Ethernet (sPPPoE) February 2005
This document aims to define a method for transporting PPP over
Ethernet that is transparent to the PPPoA CPE in this case, is far
simpler for a DSLAM to implement (which may be important given that
DSLAMs are traditionally simple network devices which may be short on
computing resources), and relatively simple for a BRAS to implement.
Compared to an IWF function between PPPoA and PPPoE, "simplified"
sPPPoE:
- Mitigates MRU problems, as the PPPoA CPE may retain a 1500-byte
MRU, which is the most commonly used setting for PPPoA
deployments. Thus it is transparent to the PPPoA CPE.
- The DSLAM can utilize a very simple mapping of ATM VC to
Ethernet VLAN or vMAC address.
- The DSLAM does not have to implement the PPPoE PAD discovery
stack.
- There is no confusion between "true" PPPoE sessions and
"translated" PPPoE sessions at the BRAS.
2. Protocol Overview
Given the DSL migration scenario depicted in Figure 1, the DSLAM will
map traffic from individual CPE PVCs on the ATM side to individual
Virtual MAC (vMAC) addresses on the GigE side. There will either be a
one-to-one mapping between ATM PVCs to Ethernet vMACs, or between ATM
PVCs and Ethernet 802.1Q VLANs. The BRAS and DSLAM will a configured
VLAN or a unique (unique at the DSLAM) source "Virtual MAC" (vMAC)
address to identify an individual ATM VC, and hence an individual
PPPoA session.
The DSLAM will need to split incoming PPPoA traffic from the CPE into
2 categories:
1 - Data traffic (which can be transported directly
over Ethernet (IPv4, IPv6, etc)
2 - PPP Control Traffic (LCP, IPCP, etc)
"Upstream" PPP control packets from the CPE destined for the BRAS are
stripped of all ATM encoding, and transported over the PPP Ethertype
0x880B, with PPP headers intact. PPP data packets are stripped of
their PPP headers and encapsulated directly over ethernet with the
corresponding ethertype for that that data. For example, IPv4
traffic is encapsulated with the native ethertype for that type of
data (e.g., 0x800 for IPv4, 0x86DD for IPv6). All sPPPoE (Simplified
PPPoE) traffic arriving at the BRAS is identified either by the
Haag, Mammoliti, Townsley Informational [Page 4]
INTERNET DRAFT Simple PPP over Ethernet (sPPPoE) February 2005
ethernet vMAC or 802.1Q VLAN tag for a given PPP session.
If a VLAN tag is used to identify PPP sessions, the VLAN value MUST
be configured at the BRAS and DSLAM for each ATM VC mapping. A single
source and destination ethernet MAC addresses for the DSLAM and BRAS
may be dynamically discovered as described in section 3.3. If a VLAN
tag is not used to identify separate PPP sessions, a unique vMAC
address MUST be dynamically assigned at the DSLAM for each ATM VC
carrying PPPoA. MAC addresses may still be discovered as in section
2.3, but the DSLAM MUST source each PPP session with its own vMAC
address.
2.1 "Upstream" (CPE to BRAS) Encapsulation
An upstream packet from the CPE will start out as a PPPoA packet and
look like the following:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| + + + + + |
| CID + LI + UUI + HEC + + |
| + + + + PPP Packet + CRC-16 |
| + + + + (Protocol + Payload) + |
| (8) + (6) + (5) + (5) + + (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: The size of the fields denote bit-width
The Protocol and Payload combined will contain a PPP protocol or data
packet as defined [RFC1661].
The DSLAM will strip the ATM header and CRC. After applying the
ethernet encapsulation, the packet will look like the following when
traveling from the DSLAM to the BRAS.
Haag, Mammoliti, Townsley Informational [Page 5]
INTERNET DRAFT Simple PPP over Ethernet (sPPPoE) February 2005
An Ethernet frame forwarded from ATM to GigE
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DESTINATION_ADDR |
| (6 octets) |
| BRAS or router MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_ADDR |
| (6 octets) |
| vMAC of CPE PVC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE (2 octets) |
| PPP or native ether type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
~ Payload ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHECKSUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ETHERTYPE will correspond to the native type for data packets,
such as 0x0800 for IP, or to the PPP ethertype 0x880B for all non-
data packets, such as PPP control and authentication packets.
The Payload will contain a complete PPP packet, including the PPP
Header, but with address and control fields (0xFF03) removed.
2.2 "Downstream" (BRAS to CPE) Encapsulation
All packets on the GigE network received on a vMAC or MAC w/VLAN at
the DSLAM will be forwarded to the corresponding CPE VC on the ATM
network after translating the header encapsulating the PPP control
packet or data packet.
The Destination Address in the ethernet frame will be used to map the
packet to a particular destination CPE PVC. The Source Address will
be that of the BRAS that generated the frame. If the Ethertype is
PPP, then the DSLAM can simply encapsulate the received Payload in
the corresponding PPPoA frame for the destination CPE. If the
ethertype is that of a data packet, such as IP, then the DSLAM will
have to prepend the corresponding PPP protocol field to the Payload
in order to perform the necessary PPPoA encapsulation.
Haag, Mammoliti, Townsley Informational [Page 6]
INTERNET DRAFT Simple PPP over Ethernet (sPPPoE) February 2005
An Ethernet frame forwarded from ATM to GigE
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DESTINATION_ADDR |
| (6 octets) |
| vMAC of CPE PVC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_ADDR |
| (6 octets) |
| BRAS or router MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE (2 octets) |
| PPP or native ether type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
~ payload ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHECKSUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PPPoA encapsulated PPP Packet on the ATM side will look like:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| + + + + + |
| CID + LI + UUI + HEC + + |
| + + + + PPP Packet + CRC-16 |
| + + + + (Protocol + Payload) + |
| (8) + (6) + (5) + (5) + + (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: The size of the fields denote bit-width
2.3 Determination of BRAS MAC Address
The DSLAM SHOULD monitor PPP control packets to determine when a new
PPP session has begun. When an LCP CONFREQ arrives from a CPE on a
PPPoA interface that is configured to forward over sPPPoE, the DSLAM
SHOULD determine the destination MAC address of the BRAS via one of
the methods described in section 2.3.1 or 2.3.2. Note that it is not
strictly necessary for the DSLAM to monitor when a PPP session ends.
2.3.1 IP-Directed
Based on a configured IP address of the BRAS, the DSLAM performs an
ARP on the given ethernet segment to determine the MAC of the BRAS
Haag, Mammoliti, Townsley Informational [Page 7]
INTERNET DRAFT Simple PPP over Ethernet (sPPPoE) February 2005
and uses this as the destination address on the GigE network for the
corresponding CPE PVC. Multiple IP addresses may be configured for
load-balancing across multiple BRASes.
2.3.2 Active Discovery
In this case, the DSLAM will send out the CPE's initial LCP CONFREQ
as an ethernet broadcast on the GigE network. One or more BRASes may
respond. The DSLAM will choose one of the responders as the
destination MAC for sPPPoE session. The DSLAM SHOULD send an LCP
TERMREQ to other BRASes that responded, but did not get chosen.
Note that the CPE device may timeout and retransmit its initial
CONFREQ before any BRAS responses get back to it, or the DSLAM has
chosen a BRAS. The DSLAM may or may not have already chosen a BRAS.
It does not matter when the DSLAM chooses the BRAS, since it will
only ever transmit packets from a single BRAS to the CPE.
3.0 PPP Packet Flow between PPPoA and sPPPoE
This section outlines example packet flows between a CPE, DSLAM and
BRAS. For sPPPoE, source and destination MAC addresses are noted.
Ethernet VLANs are not depicted, but may be present for identifying
individual PPP sessions from a given DSLAM or BRAS source MAC.
3.1 PPP LCP
CPE ------ PPPoA ------ DSLAM ----- sPPPoE ---- BRAS
--- ----- ----
PPP LCP ConfREQ -> PPP LCP ConfREQ ->
Source: vMAC
Dest: B-cast
<- PPP LCP ConfACK <- PPP LCP ConfACK
Source: BRAS MAC
Dest: vMAC
<- PPP LCP ConfREQ <- PPP LCP ConfREQ
Source: BRAS MAC
Dest: vMAC
PPP LCP ConfACK -> PPP LCP ConfACK ->
Source: vMAC
Dest: BRAS MAC
Haag, Mammoliti, Townsley Informational [Page 8]
INTERNET DRAFT Simple PPP over Ethernet (sPPPoE) February 2005
3.2 PPP Authentication
CPE ------ PPPoA ------ DSLAM ----- sPPPoE ---- BRAS
--- ----- ----
<- PPP Authen <- PPP Authen
Challenge Challenge
Source: BRAS MAC
Dest: vMAC
PPP Authen -> PPP Authen ->
Response Response
Source: vMAC
Dest: BRAS MAC
3.3 PPP IPCP
CPE ------ PPPoA ------ DSLAM ----- sPPPoE ---- BRAS
--- ----- ----
IPCP ConfREQ -> IPCP ConfREQ ->
IP 0.0.0.0 IP 0.0.0.0
Source: vMAC
Dest: BRAS MAC
<- IPCP ConfNAK <- IPCP ConfNAK
IP 10.2.3.5 IP 10.2.3.5
Source: BRAS MAC
Dest: vMAC
<- PPP IPCP ConfREQ <- PPP IPCP ConfREQ
IP 10.0.0.1 Source: BRAS MAC
Dest: vMAC
IP 10.0.0.1
IPCP ConfREQ -> IPCP ConfREQ ->
IP 10.2.3.5 IP 10.2.3.5
Source: vMAC
Dest: BRAS MAC
<- IPCP ConfACK <- IPCP ConfACK
IP 10.2.3.5 IP 10.2.3.5
Source: BRAS MAC
Dest: vMAC
IPCP ConfACK -> IPCP ConfREQ ->
IP 10.0.0.1 Source: vMAC
Dest: BRAS MAC
Haag, Mammoliti, Townsley Informational [Page 9]
INTERNET DRAFT Simple PPP over Ethernet (sPPPoE) February 2005
IP 10.0.0.1
4. Security Considerations
Measures should be taken to protect any BRAS configured to accept
sPPPoE packets from insertion and spoofing from a foreign source.
Further, sPPPoE control packets should be rate-limited before
processing at the BRAS in order to mitigate DOS attacks.
5. IANA Considerations
There are no IANA considerations for this document.
6. Acknowledgments
7. References
7.1 Normative References
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC2364] Gross, G., "PPP Over AAL5", Standards Track,
RFC 2364, July 1998
7.2 Informative References
[RFC2516] Mamakos, Lidl, Evarts, Carrel, Simone, Wheeler,
"A Method for Transmitting PPP Over Ethernet (PPPoE)",
RFC 2516, February 1999.
8. Contacts
Jeffrey Haag
cisco Systems
hagg@cisco.com
Vince Mammoliti
cisco Systems
vince@cisco.com
W. Mark Townsley
cisco Systems
mark@townsley.net
Haag, Mammoliti, Townsley Informational [Page 10]
INTERNET DRAFT Simple PPP over Ethernet (sPPPoE) February 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Haag, Mammoliti, Townsley Informational [Page 11]
