Internet DRAFT - draft-snalluri-pppoe-bulk-session-tag
draft-snalluri-pppoe-bulk-session-tag
Network Working Group Srinivasa Nalluri
Internet Draft Ericsson
Intended status: Informational May 15, 2015
Expires: August 03, 2015
PPPoE-Bulk-Session Tag extension to PPPoE PADT message
draft-snalluri-pppoe-bulk-session-tag-01
Abstract
This draft introduces a new PPPoE Tag to PADT message to carry multiple
PPPoE session information to BRAS. New tag is intended to reduce
processing load on Access Node and BRAS in abnormal network conditions.
Status of This Memo
This document is subject to BCP 78 and the IETF Trust's Legal
provisions Relating to IETF Documents http://trustee.ietf.org/license-
info) in effect on the date of publication of this document. Please
review these documents carefully, as theydescribe your rights and
restrictions with respect to this document. Code Components extracted
from this document must include implified BSD License text as described
in Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
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."
This Internet-Draft will expire on August 03, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info)
in effect on the date of publication of this document. Please review
these documents carefully, as they describe your rights and
restrictions with respect to this document.
Code Components extracted from this document must include
Simplified BSD License text as described in Section 4.e of the Trust
Legal Provisions and are provided without warranty as described in the
Simplified BSD License.
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
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.
Table of Contents
1. Terminology
2. Introduction
3. PPPoE discover phase
4. PPPoE termination stage
5. PPPoE-Bulk-Session Tag format
5.1. TAG_TYPE
5.2. TAG_LENGTH
5.3. TAG_VALUE definition
5.3.1. SESSION_COUNT
5.3.2. RESERVED
5.3.3. SESSION ID list
6. Access Node implementation considerations
7. BRAS implementation considerations
8. IANA considerations
9. Security considerations10.Acknowledgements11.References
11.1 Informative References
11.2 Normative References
1. Terminology
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 [3].
ATM - Asynchronous Transfer Mode
PPP - Point-to-Point Protocol
PPPoA - PPP over AAL5.
PPPoE - PPP over Ethernet.
MTU - Maximum Transmit Unit
PC - Personal Computer.
CPE - Customer Premises Equipment
RG - Residential Gateway
BRAS - Broadband Remote Access Server
DSLAM - Digital Subscriber Line Access Multiplexer
PPPoE client - PC, RG or CPE which initiates a PPPoE
session
PPPoE server - BRAS terminating PPPoE sessions initiated
by client
2. Introduction
In the network designs shown in Figure 1 and Figure 2, which are
studied by the Broadband-Forum in the context of the migration to
Ethernet for broadband aggregation networks, there exist some scenarios
in which PPP clients cannot terminate session as defined in RFC 2516 or
in RFC 1661.As studied by Broadband-Forum when LOS is detected on DSL
or PON line, Access Node considers that PPP client is not reachable and
sends a PADT message to BRAS so that BRAS can clean session as in
normal session teardown scenario.
In network design shown in Figure 1, when RG sends LCP configure
request, Access node generates PPPoE PADI message towards BRAS with
self MAC address as source MAC address.
In network design shown in Figure 2, when RG sends PPPoE PADI message,
Access Node replaces source MAC address in Ethernet header with self
MAC address and forwards towards BRAS.
In Both cases mentioned above BRAS receives PADI message with source
MAC address as Access Node MAC address. Thus BRAS allows multiple PPPoE
session for same MAC address. This draft leverages the idea of
establishing multiple PPPoE sessions with same MAC address to optimize
session teardown scenarios.
<----- IPoE -----> <---- PPPoA ----> <- PPPoE session ->
+------+ +-----+
+--+ +---+ | | | |
|PC|--------------| RG|------------|Access|------------| BRAS|
+--+ <Ethernet> +---+ <ATM> | Node | <GigE> | |
+------+ +-----+
Figure 1. Broadband network design with PPPoA to PPPoE conversion
<----- IPoE -----> <---- PPPoE ----> <-- PPPoE session -->
+------+ +-----+
+--+ +---+ | | | |
|PC|--------------| RG|------------|Access|------------|BRAS |
+--+ <Ethernet> +---+ <Ethernet> | Node | <GigE> | |
+------+ +-----+
Figure 2. Broadband network design with DSLAM as PPPoE intermediate
agent
When LOS observed on multiple access lines, Access node sends one PADT
message for each PPP client that is not reachable. In specific
scenarios like Access node component crash, geographical power failures
or subtended access node failure the scale of PADT messages sent by
access node towards BRAS is very high. High number of PADT messages
results in high processing load on both Access node and BRAS.This draft
introduces a new PPPoE Tag to PADT message to carry multiple PPPoE
session information to BRAS.
3. PPPoE discover phase
Introduction of this draft does not impact PPPoE discovery phase
defined in RFC 2516.
4. PPPoE termination stage
If Access Node wants to use bulk PPPoE session teardown capability then
it MUST include an optional PPPoE-Bulk-Session tag in PADT message
generated towards BRAS.
Tag-name: PPPoE-Bulk-Session
Tag Type: 0x0122
Tag-Length: Dynamic value as calculated
Tag-Value: Binary encoded value as defined in Section 5.3
5. PPPoE-Bulk-Session Tag format
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAG_TYPE | TAG_LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAG_VALUE ...... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.1. TAG_TYPE
Tag Type 0x0122 SHOULD be registered with IANA
5.2. TAG_LENGTH
Total length of PPPoE-Bulk-Session tag in octets
5.3. TAG_VALUE definition
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_COUNT | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION ID_1 | SESSION_ID 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_ID 3 | SESSION_ID 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .......... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .......... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_ID N-1 | SESSION_ID N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.3.1. SESSION_COUNT
Number of Session records encoded in TAG_VALUE.
This value depends on MTU supported between Access Node and BRAS. In
order to make sure PADT message is transmitted between Access Node and
BRAS implementations MUST consider MTU values.
5.3.2. RESERVED
Three octets field reserved for future use and MUST be filled with
zero.
5.3.3. SESSION ID list
List of PPPoE Session IDs served by PPPoE server during PPPoE session
discover phase.
6. Access Node implementation considerations
Destination MAC address in PADT message Ethernet header SHOULD be PPPoE
server MAC address. Source MAC address in PADT message Ethernet header
MUST be same as source MAC address used during PPPoE session discover
phase. Access node MUST NOT bundle PPPoE session IDs mapped to
different source MAC addresses in one PADT message. PPPoE Session ID
MUST in PADT message with PPPoE Bulk Session Tag MUST be 0xFFFE.
In order to maintain backward compatibility, Access node MUST be
capable of generating PADT message as defined in RFC 2516. Access node
MUST consider operator configuration as selection criteria between
legacy and new PADT formats.
7. BRAS implementation considerations
BRAS or PPPoE server that can handle PPPoE-Bulk-session tag MUST handle
PADT messages with PPPoE session ID 0xFFFE and tag type 0x0122. When
received such message, BRAS should perform following.
- Extract Ethernet source MAC address from Ethernet header that
is SOURCE_ADDR.
- Extract Ethernet destination MAC address from Ethernet header
that is DESTINATION_ADDR.
- For each session ID in tag value, identify PPPoE session
uniquely by {session ID, SOURCE_ADDR, DESTINATION_ADDR} and
clean the session.
PPPoE server that cannot support PPPoE-Bulk-Session tag SHOULD ignore
and silently drop any PADT message with PPPoE-Bulk-Session tag.
In order to maintain backward compatibility BRAS MUST support
processing of PADT message format as defined in RFC 2516.
8. IANA considerations
IANA considerations required to register new PPPoE Tag type as follows
TAG Value TAG Name
---- ------ ---------
290 0x0122 PPPoE_Bulk_Session
9. Security considerations
This document introduces no new security threat
10. Acknowledgements
This document is based on concepts described in several forums,
including Broad Band forum and IETF. Many thanks to David Allan I,
Natarajan Venkataraman, Narayana Pai and Suresh Gangadharan for useful
inputs and feedback.
11. References
11.1 Informative References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2 Normative References
[2]. Mamakos L., Lidl K., Evarts J., Carrel D., Simone D.,
Wheeler R., "A Method for Transmitting PPP Over Ethernet
(PPPoE)", RFC 2516, February 1999
[3]. W. Simpson "The Point-to-Point Protocol (PPP)", RFC 1661,
July 1994
Author's Addresses
Srinivasa Rao Nalluri
Ericsson
Level-5
Ferns Icon, Outer Ring Road,
Doddanakundi
Marathahalli, Bangalore
India-560037
Email: srinivasa.rao.nalluri@ericsson.com
