draft-ietf-ancp-protocol-01.txt   draft-ietf-ancp-protocol-02.txt 
Working Group Name Sanjay Wadhwa Working Group Name Sanjay Wadhwa
Internet Draft Juniper Networks Internet Draft Juniper Networks
Expires: January 9, 2008 Expires: May 19, 2008
Jerome Moisand Jerome Moisand
Juniper Networks Juniper Networks
Swami Subramanian Swami Subramanian
Juniper Networks Juniper Networks
Thomas Haag Thomas Haag
T-Systems T-Systems
Norbert Voigt Norbert Voigt
Siemens Siemens
July 9, 2007 November 19, 2007
Protocol for Access Node Control Mechanism in Broadband Networks Protocol for Access Node Control Mechanism in Broadband Networks
draft-ietf-ancp-protocol-01.txt draft-ietf-ancp-protocol-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with section 6 of BCP 79. aware will be disclosed, in accordance with section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 45 skipping to change at page 1, line 45
six months and may be updated, replaced, or obsoleted by other six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on Jan 9, 2008. This Internet-Draft will expire on May 19, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes proposed extensions to the GSMPv3 protocol to This document describes proposed extensions to the GSMPv3 protocol to
allow its use in a broadband environment, as a control plane between allow its use in a broadband environment, as a control plane between
Access Nodes (e.g. DSLAM) and Broadband Network Gateways (e.g. NAS). Access Nodes (e.g. DSLAM) and Broadband Network Gateways (e.g. NAS).
skipping to change at page 2, line 35 skipping to change at page 2, line 35
Illustrative text for the use-cases is included here to help the Illustrative text for the use-cases is included here to help the
protocol implementer understand the greater context of ANCP protocol protocol implementer understand the greater context of ANCP protocol
interactions. interactions.
Table of Contents Table of Contents
1 Specification Requirements 4 1 Specification Requirements 4
2 Introduction 4 2 Introduction 4
2.1 Terminology..............................................5
3 Broadband Access Aggregation 5 3 Broadband Access Aggregation 5
3.1 ATM-based broadband aggregation..........................5 3.1 ATM-based broadband aggregation..........................5
3.2 Ethernet-based broadband aggregation.....................6 3.2 Ethernet-based broadband aggregation.....................7
4 Access Node Control Protocol 7 4 Access Node Control Protocol 8
4.1 Overview.................................................7 4.1 Overview.................................................8
4.2 ANCP based Access Topology Discovery.....................8 4.2 ANCP based Access Topology Discovery.....................9
4.2.1 Goals..............................................8 4.2.1 Goals..............................................9
4.2.2 Message Flow.......................................8 4.2.2 Message Flow.......................................9
4.3 ANCP based Line Configuration............................9 4.3 ANCP based Line Configuration...........................10
4.3.1 Goals..............................................9 4.3.1 Goals.............................................10
4.3.2 Message Flow......................................10 4.3.2 Message Flow......................................11
4.4 ANCP based Transactional Multicast......................12 4.4 ANCP based Transactional Multicast......................13
4.5 ANCP based OAM..........................................13 4.5 ANCP based OAM..........................................14
4.5.1 Message Flow......................................13 4.5.1 Message Flow......................................14
5 Access Node Control Protocol (ANCP) 14 5 Access Node Control Protocol (ANCP) 15
5.1 ANCP/TCP connection establishment.......................16
5.2 ANCP Connection keep-alive..............................16
5.3 Capability negotiation..................................17
5.4 GSMP Message Extensions for Access Node Control.........20
5.4.1 General Extensions................................20
5.4.2 Topology Discovery Extensions.....................23
5.4.3 Line Configuration Extensions.....................32
5.4.4 OAM Extensions....................................34
5.5 ATM-specific considerations.............................37
5.6 Ethernet-specific considerations........................38
6 IANA Considerations 38
7 Security Considerations 38 5.1 ANCP/TCP connection establishment.......................17
5.2 ANCP Connection keep-alive..............................17
5.3 Capability negotiation..................................18
5.4 GSMP Message Extensions for Access Node Control.........21
5.4.1 General Extensions................................21
5.4.2 Topology Discovery Extensions.....................24
5.4.3 Line Configuration Extensions.....................33
5.4.4 OAM Extensions....................................36
5.5 ATM-specific considerations.............................39
5.6 Ethernet-specific considerations........................39
6 IANA Considerations 40
8 References 39 7 Security Considerations 40
Author's Addresses 40 8 References 40
Full Copyright Statement 40 Author's Addresses42
Copyright (C) The IETF Trust (2007). 40 Full Copyright Statement42
Intellectual Property 41 Copyright (C) The IETF Trust (2007).42
Acknowledgment 41 Intellectual Property43
Acknowledgment 43
1 Specification Requirements 1 Specification Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT",“SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in NOT",“SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119. this document are to be interpreted as described in RFC 2119.
2 Introduction 2 Introduction
DSL is a widely deployed access technology for Broadband Access for DSL is a widely deployed access technology for Broadband Access for
Next Generation Networks. Several specifications like [1-3] describe Next Generation Networks. Several specifications like [1-3] describe
skipping to change at page 5, line 5 skipping to change at page 5, line 5
5. GSMPv3 procedures with suitable extensions, as used by ANCP, are 5. GSMPv3 procedures with suitable extensions, as used by ANCP, are
described in sections 5.1, 5.2 and 5.3. GSMPv3 general extensions and described in sections 5.1, 5.2 and 5.3. GSMPv3 general extensions and
GSMPv3 message specific extensions required by ANCP are described in GSMPv3 message specific extensions required by ANCP are described in
sub-sections of 5.4. In addition to specifying extensions and sub-sections of 5.4. In addition to specifying extensions and
modifications to relevant GSMP messages applicable to ANCP, this modifications to relevant GSMP messages applicable to ANCP, this
draft also defines the usage of these messages by ANCP, and indicates draft also defines the usage of these messages by ANCP, and indicates
the values that ANCP should set for relevant fields in these GSMP the values that ANCP should set for relevant fields in these GSMP
messages. However, to understand the basic semantics of various messages. However, to understand the basic semantics of various
fields in GSMP messages, the reader is referred to [4]. fields in GSMP messages, the reader is referred to [4].
2.1 Terminology
o Access Node (AN): Network device, usually located at a service
provider central office or street cabinet that terminates access
(local) loop connections from subscribers. In case the access loop
is a Digital Subscriber Line (DSL), the Access Node provides DSL
signal termination, and is referred to as DSL Access Multiplexer
(DSLAM).
o Network Access Server (NAS): Network element which aggregates
subscriber traffic from a number of Access Nodes. The NAS is an
injection point for policy management and IP QoS in the access
network. IT is also referred to as Broadband Network Gateway (BNG)
or Broadband Remote Access Server (BRAS).
o Home Gateway (HGW): Network element that connects subscriber
devices to the Access Node and the access network. In case of DSL,
the Home Gateway is a DSL network termination that could either
operate as a layer 2 bridge or as a layer 3 router. In the latter
case, such a device is also referred to as a Routing Gateway (RG).
o Net Data Rate: portion of the total data rate of the DSL line that
can be used to transmit actual user information (e.g. ATM cells of
Ethernet frames). It excludes overhead that pertains to the
physical transmission mechanism (e.g. trellis coding in case of
DSL). This is defined in section 3.39 of ITU-T G.993.2.
o DSL line (synch) rate: the total data rate of the DSL line,
including the overhead attributable to the physical transmission
mechanism.
o DSL multi-pair bonding: method for bonding (or aggregating)
multiple xDSL lines into a single bi-directional logical link,
henceforth referred to in this draft as “DSL bonded circuit”. DSL
“multi-pair” bonding allows an operator to combine the data rates
on two or more copper pairs, and deliver the aggregate data rate
to a single customer. ITU-T recommendations G.998.1 and G.998.2
respectively describe ATM and Ethernet based multi-pair bonding.
3 Broadband Access Aggregation 3 Broadband Access Aggregation
3.1 ATM-based broadband aggregation 3.1 ATM-based broadband aggregation
End to end DSL network consists of network and application service End to end DSL network consists of network and application service
provider networks (NSP and ASP networks), regional/access network, provider networks (NSP and ASP networks), regional/access network,
and customer premises network. Fig1. shows ATM broadband access and customer premises network. Fig1. shows ATM broadband access
network components. network components.
The Regional/Access Network consists of the Regional Network, Network The Regional/Access Network consists of the Regional Network, Network
skipping to change at page 6, line 14 skipping to change at page 7, line 14
ATM network. This is achieved by using a diffserv-aware hierarchical ATM network. This is achieved by using a diffserv-aware hierarchical
scheduler in the NAS that will account for downstream trunk scheduler in the NAS that will account for downstream trunk
bandwidths and DSL synch rates. bandwidths and DSL synch rates.
[8] provides detailed definition and functions of each network [8] provides detailed definition and functions of each network
element in the broadband reference architecture. element in the broadband reference architecture.
Access Customer Access Customer
<--- Aggregation ---> <------- Premises -------> <--- Aggregation ---> <------- Premises ------->
Network Network Network Network
+-------------------+ +--------------------------+ +-------------------+ +----------------------------+
+----------+ +-----+ | +-----+ +------+ |--|+-----+ +--+ +----------+ | +----------+ +-----+ | +-----+ +------+ |--|+-----+ +---+ +---------+ |
| | +-|NAS |---| |ATM |--|Access| | ||DSL |-|RG|-|Subscriber| | | | +-|NAS |--| |ATM |--|Access| | ||DSL |-|HGW|--|Subscriber||
NSP---+Regional | | +-----+ | +-----+ | Node | | ||Modem| +--+ |Devices | | NSP---+Regional | | +-----+ | +-----+ | Node | | ||Modem| +---+ |Devices ||
|Broadband | | +-----+ | +------+ | |+-----+ +----------+ | |Broadband | | +-----+ | +------+ | |+-----+ +----------+ |
|Network |-+-|NAS | +---------------|---+ +--------------------------+ |Network |-+-|NAS | +---------------|---+ +---------------------------+
ASP---+ | | +-----+ | +--------------------------+ ASP---+ | | +-----+ | +----------------------------+
| | | +-----+ | | +-----+ +--+ +----------+| | | | +-----+ | | +-----+ +---+ +----------+|
+----------+ +-|NAS | +------| | DSL |-|RG|-|Subscriber|| +----------+ +-|NAS | +-----| | DSL |-|HGW|--|Subscriber||
+-----+ | |Modem| +--+ |Devices || +-----+ | |Modem| +---+ |Devices ||
| +-----+ +----------+| | +-----+ +----------+|
+--------------------------+ +----------------------------+
RG : Routing Gateway HGW : Home Gateway
NAS : Network Access Server NAS : Network Access Server
Fig.1 ATM Broadband Aggregation Topology Fig.1 ATM Broadband Aggregation Topology
3.2 Ethernet-based broadband aggregation 3.2 Ethernet-based broadband aggregation
The Ethernet aggregation network architecture builds on the Ethernet The Ethernet aggregation network architecture builds on the Ethernet
bridging/switching concepts defined in IEEE 802. The Ethernet bridging/switching concepts defined in IEEE 802. The Ethernet
aggregation network provides traffic aggregation, class of service aggregation network provides traffic aggregation, class of service
distinction, and customer separation and traceability. VLAN tagging distinction, and customer separation and traceability. VLAN tagging
skipping to change at page 8, line 13 skipping to change at page 9, line 13
access technologies. access technologies.
4.2 ANCP based Access Topology Discovery 4.2 ANCP based Access Topology Discovery
4.2.1 Goals 4.2.1 Goals
[1] discusses various queuing/scheduling mechanisms to avoid [1] discusses various queuing/scheduling mechanisms to avoid
congestion in the access network while dealing with multiple flows congestion in the access network while dealing with multiple flows
with distinct QoS requirements. Such mechanisms require that the NAS with distinct QoS requirements. Such mechanisms require that the NAS
gains knowledge about the topology of the access network, the various gains knowledge about the topology of the access network, the various
links being used and their respective rates. Some of the information links being used and their respective net data rates. Some of the
required is somewhat dynamic in nature (e.g. DSL sync rate), hence information required is somewhat dynamic in nature (e.g. DSL sync
cannot come from a provisioning and/or inventory management OSS rate, and therefore also the net data rate), hence cannot come from a
system. Some of the information varies less frequently (e.g. capacity provisioning and/or inventory management OSS system. Some of the
of a DSLAM uplink), but nevertheless needs to be kept strictly in information varies less frequently (e.g. capacity of a DSLAM uplink),
sync between the actual capacity of the uplink and the image the NAS but nevertheless needs to be kept strictly in sync between the actual
has of it. capacity of the uplink and the image the NAS has of it.
Following section describes ANCP messages that allow the Access Node Following section describes ANCP messages that allow the Access Node
(e.g. DSLAM) to communicate to the NAS, access network topology (e.g. DSLAM) to communicate to the NAS, access network topology
information and any corresponding updates. information and any corresponding updates.
Some of the parameters that can be communicated from the DSLAM to the Some of the parameters that can be communicated from the DSLAM to the
NAS include DSL line state, actual upstream and downstream data rates NAS include DSL line state, actual upstream and downstream net data
of a synchronized DSL link, maximum attainable upstream and rates of a synchronized DSL link, maximum attainable upstream and
downstream data rates, interleaving delay etc. Topology discovery is downstream net data rates, interleaving delay etc. Topology discovery
specifically important in case the net data rate of the DSL line is specifically important in case the net data rate of the DSL line
changes over time. The DSL net data rate may be different every time changes over time. The DSL net data rate may be different every time
the DSL modem is turned on. Additionally, during the time the DSL the DSL modem is turned on. Additionally, during the time the DSL
modem is active, data rate changes can occur due to environmental modem is active, data rate changes can occur due to environmental
conditions (the DSL line can get "out of sync" and can retrain to a conditions (the DSL line can get "out of sync" and can retrain to a
lower value. lower value).
4.2.2 Message Flow 4.2.2 Message Flow
When a DSL line initially comes up or resynchronizes to a different When a DSL line initially comes up or resynchronizes to a different
rate, the DSLAM generates and transmits a GSMP PORT UP EVENT message to rate, the DSLAM generates and transmits a GSMP PORT UP EVENT message to
the NAS. The extension field in the message carries the TLVs containing the NAS. The extension field in the message carries the TLVs containing
DSL line specific parameters. On a loss of signal on the DSL line, a DSL line specific parameters. On a loss of signal on the DSL line, a
GSMP PORT DOWN message is generated by the DSLAM to the NAS. In order to GSMP PORT DOWN message is generated by the DSLAM to the NAS. In order to
provide expected service level, NAS needs to learn the initial provide expected service level, NAS needs to learn the initial
attributes of the DSL line before the subscriber can log in and access attributes of the DSL line before the subscriber can log in and access
the provisioned services for the subscriber. the provisioned services for the subscriber.
<----- Port UP(EVENT Message) <----- DSL <----- Port UP(EVENT Message) <----- DSL
(default line parameters) Signal (default line parameters) Signal
1. NAS ----------------------- DSLAM ----------- Routing ----- Subscriber 1. NAS ----------------------- Access ----------- Home ----- Subscriber
Gateway Node Gateway
<----- Port UP (EVENT Message) <----- DSL <----- Port UP (EVENT Message) <----- DSL
(updated line parameters) Resynch (updated line parameters) Resynch
2. NAS ----------------------- DSLAM ----------- Routing ------ Subscriber 2. NAS ----------------------- Access ----------- Home ------ Subscriber
Gateway Node Gateway
<--- Port DOWN (EVENT Message) <---- DSL <--- Port DOWN (EVENT Message) <---- DSL
Loss of Signal Loss of Signal
3. NAS ---------------------- DSLAM ------------- Routing ----- Subscriber 3. NAS ---------------------- Access ------------- Home ----- Subscriber
Gateway Node Gateway
Fig 2. Message flow (ANCP mapping) for topology discovery Fig 2. Message flow (ANCP mapping) for topology discovery
The Event message with PORT UP message type (80) is used for The Event message with PORT UP message type (80) is used for
conveying DSL line attributes to the NAS. This message with relevant conveying DSL line attributes to the NAS. This message with relevant
extensions is defined in section 5.4.2. extensions is defined in section 5.4.2.
4.3 ANCP based Line Configuration 4.3 ANCP based Line Configuration
4.3.1 Goals 4.3.1 Goals
skipping to change at page 11, line 19 skipping to change at page 12, line 19
<-------------------------- <--------------------------
3. PPP/DHCP Session 3. PPP/DHCP Session
<----------------------------------------------------- <-----------------------------------------------------
4. Authorization 4. Authorization
& Authentication & Authentication
<------------------- <-------------------
Port Management Message Port Management Message
(Line Configuration) (Line Configuration)
5. ----------------> 5. ---------------->
+-------------+ +-----+ +-------+ +----------+ +-----------+ +-------------+ +-----+ +-------+ +----------+ +-----------+
|Radius/AAA |------|NAS |---------| DSLAM |------ | Routing |------ |Subscriber | |Radius/AAA |------| NAS |---------| AN |------ | Home |------ |Subscriber |
|Policy Server| +-----+ +-------+ | Gateway | +-----------+ |Policy Server| +-----+ +-------+ | Gateway | +-----------+
+-------------+ +----------+ +-------------+ +----------+
Fig 3. Message flow - ANCP mapping for Initial Line Configuration Fig 3. Message flow - ANCP mapping for Initial Line Configuration
The NAS may update the line configuration due to a subscriber service The NAS may update the line configuration due to a subscriber service
change (e.g. triggered by the policy server). Figure 4 summarizes the change (e.g. triggered by the policy server). Figure 4 summarizes the
interaction interaction
1. PPP/DHCP Session 1. PPP/DHCP Session
<------------------------------------------ <------------------------------------------
+-------------+ 2. Service On Demand +-------------+ 2. Service On Demand
| |<------------------------------------------------ | |<------------------------------------------------
| Web portal | | Web portal |
| OSS etc | 3.Change of 4.Port Management | OSS etc | 3.Change of 4.Port Management
| | Authorization Message | | Authorization Message
| Radius AAA | --------> (Updated Line | Radius AAA | --------> (Updated Line
| Policy | Config - New Profile) | Policy | Config - New Profile)
| | -------------. | | -------------.
| | +------+ +-------+ +---------+ +----------+ | | +------+ +-------+ +---------+ +----------+
| |----| NAS |-----| DSLAM |---| Routing |--|Subscriber| | |----| NAS |-----| AN |---| Home |--|Subscriber|
| | +------+ +-------+ | Gateway | +----------+ | | +------+ +-------+ | Gateway | +----------+
+-------------+ +---------+ +-------------+ +---------+
Fig 4. Message flow - ANCP mapping for Updated Line Configuration Fig 4. Message flow - ANCP mapping for Updated Line Configuration
The format of relevant extensions to port management message is The format of relevant extensions to port management message is
defined in section 5.4.3. The line configuration models could be defined in section 5.4.3. The line configuration models could be
viewed as a form of delegation of authorization from the NAS to the viewed as a form of delegation of authorization from the NAS to the
DSLAM. DSLAM.
skipping to change at page 24, line 5 skipping to change at page 24, line 35
administratively modified. Also, when the ANCP session first comes up, administratively modified. Also, when the ANCP session first comes up,
the DSLSM SHOULD transmit a PORT UP message to the NAS for each line the DSLSM SHOULD transmit a PORT UP message to the NAS for each line
that is up. A DSLAM MAY use a Bulk Transaction message as defined in that is up. A DSLAM MAY use a Bulk Transaction message as defined in
5.4.1.2 to aggregate the transmission of PORT UP messages. 5.4.1.2 to aggregate the transmission of PORT UP messages.
When a DSL line goes down (idle or silent), the DSLAM SHOULD transmit an When a DSL line goes down (idle or silent), the DSLAM SHOULD transmit an
Event message with PORT DOWN message type (81) to the NAS. It is Event message with PORT DOWN message type (81) to the NAS. It is
recommended that the DSLAMs use a dampening mechanism per DSL line to recommended that the DSLAMs use a dampening mechanism per DSL line to
control the rate of state changes per DSL line, communicated to the NAS. control the rate of state changes per DSL line, communicated to the NAS.
In case of bonded copper loops to the customer premise (as per DSL
multi-pair bonding described by [9] and [10]), the DSLAM MUST report the
aggregate net data rate and other attributes for the “DSL bonded
circuit” (represented as a single logical port) to the NAS in a PORT UP
message. Any change in the aggregate net data rate of the “DSL bonded
circuit” (due to a change in net data rate of individual constituent DSL
lines or due to change in state of the individual constituent DSL lines)
MUST be reported by the DSLAM to the NAS in a PORT UP message. The DSLAM
MUST also report the “aggregate” state of the “DSL bonded circuit” to
the NAS via PORT UP and PORT DOWN messages.
0 1 2 3 0 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | Message Type | Result| Code | | Vers | Sub | Message Type | Result| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier | | Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length | |I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | | Port |
skipping to change at page 28, line 35 skipping to change at page 29, line 35
. Type (DSL-Type = 0x91) : Defines the type of transmission system . Type (DSL-Type = 0x91) : Defines the type of transmission system
in use. This is a mandatory TLV. in use. This is a mandatory TLV.
Length : (4 bytes) Length : (4 bytes)
Value : (Transmission system : ADSL1 = 0x01, ADSL2 = 0x02, Value : (Transmission system : ADSL1 = 0x01, ADSL2 = 0x02,
ADSL2+ = 0x03, VDSL1 = 0x04, VDSL2 = 0x05, SDSL = 0x06, UNKNOWN ADSL2+ = 0x03, VDSL1 = 0x04, VDSL2 = 0x05, SDSL = 0x06, UNKNOWN
= 0x07). = 0x07).
. Type (Actual-Data-Rate-Upstream = 0x81) : Actual data rate . Type (Actual-Net-Data-Upstream = 0x81): Actual upstream net data
upstream of a synchronized DSL line. This is a mandatory TLV. rate on a DSL line. This is a mandatory TLV.
This rate value and all the subsequent ones account for the DSL
overhead (i.e. signify the net rate).
Length : (4 bytes) Length : (4 bytes)
Value : (Rate in Kb/sec) Value : (Rate in Kb/sec)
. Type (Actual-Data-Rate-Downstream = 0x82) : Actual data rate . Type (Actual-Net-Data-Rate-Downstream = 0x82) : Actual
downstream of a synchronized DSL line. This is a mandatory TLV. downstream net data rate on a DSL line. This is a mandatory TLV.
Length : (4 bytes) Length : (4 bytes)
Value : (Rate in Kb/sec)
. Type (Minimum-Data-Rate-Upstream = 0x83) : Minimum data rate Value : (Rate in Kb/sec)
desired by the operator. This is optional. . Type (Minimum-Net-Data-Rate-Upstream = 0x83) : Minimum net data
rate desired by the operator. This is optional.
Length : (4 bytes) Length : (4 bytes)
Value : (Rate in Kb/sec) Value : (Rate in Kb/sec)
. Type (Minimum-Data-Rate-Downstream = 0x84) : Minimum data rate . Type (Minimum-Net-Data-Rate-Downstream = 0x84) : Minimum net
desired by the operator. This is optional. data rate desired by the operator. This is optional.
Length : (4 bytes) Length : (4 bytes)
Value : (Rate in Kb/sec) Value : (Rate in Kb/sec)
. Type (Attainable-Data-Rate-Upstream = 0x85) : Maximum upstream . Type (Attainable-Net-Data-Rate-Upstream = 0x85) : Maximum net
rate that can be attained on the DSL line. This is an optional upstream rate that can be attained on the DSL line. This is an
TLV. optional TLV.
Length : (4 bytes) Length : (4 bytes)
Value : (Rate in Kb/sec) Value : (Rate in Kb/sec)
. Type (Attainable-Data-Rate-Downstream = 0x86) : Maximum . Type (Attainable-Net-Data-Rate-Downstream = 0x86) : Maximum net
downstream rate that can be attained on the DSL line. This is downstream rate that can be attained on the DSL line. This is
an optional TLV. an optional TLV.
Length : (4 bytes) Length : (4 bytes)
Value : (Rate in Kb/sec) Value : (Rate in Kb/sec)
. Type (Maximum-Data-Rate-Upstream = 0x87) : Maximum data rate . Type (Maximum-Net-Data-Rate-Upstream = 0x87) : Maximum net data
desired by the operator. This is optional. rate desired by the operator. This is optional.
Length : (4 bytes) Length : (4 bytes)
Value : (Rate in Kb/sec) Value : (Rate in Kb/sec)
. Type (Maximum-Data-Rate-Downstream = 0x88) : Maximum data rate . Type (Maximum-Net-Data-Rate-Downstream = 0x88) : Maximum net
desired by the operator. This is optional. data rate desired by the operator. This is optional.
Length : (4 bytes) Length : (4 bytes)
Value : (Rate in Kb/sec) Value : (Rate in Kb/sec)
. Type (Minimum-Low-Power-Data-Rate-Upstream = 0x89) : Minimum . Type (Minimum-Net-Low-Power-Data-Rate-Upstream = 0x89) : Minimum
data rate desired by the operator in low power state. This is net data rate desired by the operator in low power state. This
optional. is optional.
Length : (4 bytes) Length : (4 bytes)
Value : (Rate in Kb/sec) Value : (Rate in Kb/sec)
. Type (Minimum-Low-Power-Data-Rate-Downstream = 0x8A) : Minimum . Type (Minimum-Net-Low-Power-Data-Rate-Downstream = 0x8A) :
data rate desired by the operator in low power state. This is Minimum net data rate desired by the operator in low power
optional. state. This is optional.
Length : (4 bytes) Length : (4 bytes)
Value : (Rate in Kb/sec) Value : (Rate in Kb/sec)
. Type (Maximum-Interleaving-Delay-Upstream = 0x8B) : maximum one . Type (Maximum-Interleaving-Delay-Upstream = 0x8B) : maximum one
way interleaving delay. This is optional. way interleaving delay. This is optional.
Length : (4 bytes) Length : (4 bytes)
skipping to change at page 32, line 13 skipping to change at page 33, line 13
Ethernet over AAL5 NULL with FCS = 7, Ethernet over AAL5 NULL with FCS = 7,
Ethernet over AAL5 NULL without FCS = 8} Ethernet over AAL5 NULL without FCS = 8}
If this TLV is present, the Data Link protocol MUST be indicated as If this TLV is present, the Data Link protocol MUST be indicated as
defined above. However, the Access Node can choose to not convey the defined above. However, the Access Node can choose to not convey the
encapsulation on the access loop by specifying a value of 0 (NA) for the encapsulation on the access loop by specifying a value of 0 (NA) for the
two encapsulation fields. two encapsulation fields.
5.4.3 Line Configuration Extensions 5.4.3 Line Configuration Extensions
The NAS uses extension block in the Port Management messages to convey The Port Management message format defined in [4] has been modified to
service attributes of the DSL lines to the DSLAM. TLVs are defined for contain an extension block (described above in section 5.4.1.1) at the
DSL line identification and service data for the DSL lines. Port number end of the message. Also, the original two byte Function field has been
is set to 0 in the message. A new action type "Configure Connection modified to contain one byte for the Function field indicating a
Service Data" (value 0x8) is defined. The "Function" field is set to the specific action to be taken by the recipient of the message, and one
action type. This action type indicates to the device being controlled byte for X-Function field, which could further qualify the action
(access-node i.e. DSLAM) to apply service configuration data contained specified in the Function field. Any Function specific data MUST be
in the extension value (TLVs), to the DSL line (identified by one of the carried in the extension block.
TLVs in the extension value). The Tech Type field is extended with new
type "DSL". The value for this field is 0x05. The NAS uses the extension block in the Port Management messages to
convey service attributes of the DSL lines to the DSLAM. TLVs are
defined for DSL line identification and service data for the DSL lines.
Port number is set to 0 in the message. A new action type "Configure
Connection Service Data" (value 0x8) is defined. The "Function" field is
set to the action type. This action type indicates to the device being
controlled (Access Node i.e. DSLAM) to apply service configuration data
contained in the extension value (TLVs), to the DSL line (identified by
one of the TLVs in the extension value). For the action type “Configure
Connection Service Data”, X-Function field MUST be set to 0. The Tech
Type field is extended with new type "DSL". The value for this field is
0x05.
0 1 2 3 0 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | Message Type | Result| Code | | Vers | Sub | Message Type | Result| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier | | Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length | |I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 40, line 5 skipping to change at page 41, line 8
Control Protocol (TCP)", RFC 3293, June 2002. Control Protocol (TCP)", RFC 3293, June 2002.
[6] “DHCP Relay Agent Information Option”, RFC 3046, January 2001. [6] “DHCP Relay Agent Information Option”, RFC 3046, January 2001.
[7] Architecture & Transport: Migration to Ethernet Based DSL [7] Architecture & Transport: Migration to Ethernet Based DSL
Aggregation, DSL Forum WT-101, Cohen et al. Aggregation, DSL Forum WT-101, Cohen et al.
[8] Framework for Access Node Control Mechanism in Broadband [8] Framework for Access Node Control Mechanism in Broadband
Networks, draft-ietf-ancp-framework-00.txt. Networks, draft-ietf-ancp-framework-00.txt.
[9] ITU-T recommendation G.998.1, ATM-based multi-pair bonding,
2005.
[10] ITU-T recommendation G.998.2, Ethernet-based multi-pair
bonding, 2005.
Author's Addresses Author's Addresses
Sanjay Wadhwa Sanjay Wadhwa
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
Email: swadhwa@juniper.net Email: swadhwa@juniper.net
Jerome Moisand Jerome Moisand
skipping to change at page 41, line 38 skipping to change at page 43, line 38
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org ietf-ipr@ietf.org
Acknowledgment Acknowledgment
Thanks to Peter Arberg, Josef Froehler, Derek Harkness, Kim Thanks to Peter Arberg, Josef Froehler, Derek Harkness, Kim
Hyldgaard, Sandy Ng, Robert Peschi, and Michel Platnic for their Hyldgaard, Sandy Ng, Robert Peschi, Michel Platnic, Stefaan DE
input to this document. Cnodder and Wojciech Dec for their input to this document.
 End of changes. 41 change blocks. 
101 lines changed or deleted 168 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/