draft-ietf-ancp-protocol-02.txt   draft-ietf-ancp-protocol-03.txt 
Working Group Name Sanjay Wadhwa Working Group Name Sanjay Wadhwa
Internet Draft Juniper Networks Internet Draft Juniper Networks
Expires: May 19, 2008 Intended status: Standards Track
Jerome Moisand Expires: Jan 14, 2009 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
November 19, 2007 July 14, 2008
Protocol for Access Node Control Mechanism in Broadband Networks Protocol for Access Node Control Mechanism in Broadband Networks
draft-ietf-ancp-protocol-02.txt draft-ietf-ancp-protocol-03.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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of Drafts.
Internet-Drafts are draft documents valid for a maximum of
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 May 19, 2008. This Internet-Draft will expire on Jan 14, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
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).
These proposed extensions are required to realize a protocol for These proposed extensions are required to realize a protocol for
“Access Node Control” mechanism as described in [8]. The resulting "Access Node Control" mechanism as described in [ANCP-FRAMEWORK]. The
protocol with the proposed extensions to GSMPv3 [4] is referred to as resulting protocol with the proposed extensions to GSMPv3 [RFC3292]
“Access Node Control Protocol” (ANCP). This document currently is referred to as "Access Node Control Protocol" (ANCP). This
focuses on specific use cases of access node control mechanism for document currently focuses on specific use cases of access node
topology discovery, line configuration, and OAM as described in ANCP control mechanism for topology discovery, line configuration, and OAM
framework document [8]. It is intended to be augmented by additional as described in ANCP framework document [ANCP-FRAMEWORK]. It is
protocol specification for future use cases considered in scope by intended to be augmented by additional protocol specification for
the ANCP charter. future use cases considered in scope by the ANCP charter.
ANCP framework document [8] describes the ANCP use-cases in detail. ANCP framework document [ANCP-FRAMEWORK] describes the ANCP use-cases
Illustrative text for the use-cases is included here to help the in detail. Illustrative text for the use-cases is included here to
protocol implementer understand the greater context of ANCP protocol help the protocol implementer understand the greater context of ANCP
interactions. protocol 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 2.1 Terminology..............................................5
3 Broadband Access Aggregation 5 3 Broadband Access Aggregation 6
3.1 ATM-based broadband aggregation..........................5 3.1 ATM-based broadband aggregation..........................6
3.2 Ethernet-based broadband aggregation.....................7 3.2 Ethernet-based broadband aggregation.....................7
4 Access Node Control Protocol 8 4 Access Node Control Protocol 8
4.1 Overview.................................................8 4.1 Overview.................................................8
4.2 ANCP based Access Topology Discovery.....................9 4.2 ANCP based Access Topology Discovery.....................9
4.2.1 Goals..............................................9 4.2.1 Goals..............................................9
4.2.2 Message Flow.......................................9 4.2.2 Message Flow.......................................9
4.3 ANCP based Line Configuration...........................10 4.3 ANCP based Line Configuration...........................10
4.3.1 Goals.............................................10 4.3.1 Goals.............................................10
4.3.2 Message Flow......................................11 4.3.2 Message Flow......................................11
4.4 ANCP based Transactional Multicast......................13 4.4 ANCP based Transactional Multicast......................13
4.5 ANCP based OAM..........................................14 4.5 ANCP based OAM..........................................14
4.5.1 Message Flow......................................14 4.5.1 Message Flow......................................14
5 Access Node Control Protocol (ANCP) 15 5 Access Node Control Protocol (ANCP) 15
5.1 ANCP/TCP connection establishment.......................17 5.1 ANCP/TCP connection establishment.......................17
5.2 ANCP Connection keep-alive..............................17 5.2 ANCP Connection keep-alive..............................17
5.3 Capability negotiation..................................18 5.3 Capability negotiation..................................18
5.4 GSMP Message Extensions for Access Node Control.........21 5.4 GSMP Message Extensions for Access Node Control.........21
5.4.1 General Extensions................................21 5.4.1 General Extensions................................21
5.4.2 Topology Discovery Extensions.....................24 5.4.2 Topology Discovery Extensions.....................23
5.4.3 Line Configuration Extensions.....................33 5.4.3 Line Configuration Extensions.....................33
5.4.4 OAM Extensions....................................36 5.4.4 OAM Extensions....................................36
5.5 ATM-specific considerations.............................39 5.5 ATM-specific considerations.............................39
5.6 Ethernet-specific considerations........................39 5.6 Ethernet-specific considerations........................39
6 IANA Considerations 40 6 IANA Considerations 40
7 Security Considerations 40 7 Security Considerations 40
8 References 40 8 References 40
Author's Addresses42 Author's Addresses42
Full Copyright Statement42 Full Copyright Statement42
Copyright (C) The IETF Trust (2007).42 Copyright (C) The IETF Trust (2007) 42
Intellectual Property43 Intellectual Property43
Acknowledgment 43 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 [TR-059, TR-
possible architectures for these access networks. In the scope of 058, TR-092] describe possible architectures for these access
these specifications are the delivery of voice, video and data networks. In the scope of these specifications are the delivery of
services. voice, video and data services.
When deploying value-added services across DSL access networks, When deploying value-added services across DSL access networks,
special attention regarding quality of service and service control is special attention regarding quality of service and service control is
required, which implies a tighter coordination between network required, which implies a tighter coordination between network
elements in the broadband access network without burdening the OSS elements in the broadband access network without burdening the OSS
layer. layer.
This draft defines extensions and modifications to GSMPv3 (specified This draft defines extensions and modifications to GSMPv3 (specified
in [4]) and certain new mechanisms to realize a control plane between in [RFC3292]) and certain new mechanisms to realize a control plane
a service-oriented layer 3 edge device (the NAS) and a layer2 Access between a service-oriented layer 3 edge device (the NAS) and a layer2
Node (e.g. DSLAM) in order to perform QoS-related, service-related Access Node (e.g. DSLAM) in order to perform QoS-related, service-
and subscriber-related operations. The control protocol as a result related and subscriber-related operations. The control protocol as a
of these extensions and mechanisms is referred to as “Access Node result of these extensions and mechanisms is referred to as "Access
Control Protocol” (ANCP). Node Control Protocol" (ANCP).
ANCP uses the option of transporting GSMPv3 over TCP/IP. TCP ANCP uses the option of transporting GSMPv3 over TCP/IP. TCP
encapsulation for GSMPv3 is defined in [5]. GSMPv3 encapsulation encapsulation for GSMPv3 is defined in [RFC3293]. GSMPv3
directly over Ethernet and ATM as defined in [5] is not considered encapsulation directly over Ethernet and ATM as defined in [RFC3293]
for ANCP. is not considered for ANCP.
ANCP uses a subset of GSMPv3 messages to implement currently defined ANCP uses a subset of GSMPv3 messages to implement currently defined
use-cases. These relevant GSMPv3 messages are identified in section use-cases. These relevant GSMPv3 messages are identified in section
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. Not all the
the values that ANCP should set for relevant fields in these GSMP fields in relevant GSMP messages are used by ANCP. This draft
indicates the value that ANCP should set for the 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 [RFC3292].
2.1 Terminology 2.1 Terminology
o Access Node (AN): Network device, usually located at a service o Access Node (AN): Network device, usually located at a service
provider central office or street cabinet that terminates access provider central office or street cabinet that terminates access
(local) loop connections from subscribers. In case the access loop (local) loop connections from subscribers. In case the access loop
is a Digital Subscriber Line (DSL), the Access Node provides DSL is a Digital Subscriber Line (DSL), the Access Node provides DSL
signal termination, and is referred to as DSL Access Multiplexer signal termination, and is referred to as DSL Access Multiplexer
(DSLAM). (DSLAM).
skipping to change at page 5, line 38 skipping to change at page 5, line 40
Ethernet frames). It excludes overhead that pertains to the Ethernet frames). It excludes overhead that pertains to the
physical transmission mechanism (e.g. trellis coding in case of physical transmission mechanism (e.g. trellis coding in case of
DSL). This is defined in section 3.39 of ITU-T G.993.2. 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, o DSL line (synch) rate: the total data rate of the DSL line,
including the overhead attributable to the physical transmission including the overhead attributable to the physical transmission
mechanism. mechanism.
o DSL multi-pair bonding: method for bonding (or aggregating) o DSL multi-pair bonding: method for bonding (or aggregating)
multiple xDSL lines into a single bi-directional logical link, multiple xDSL lines into a single bi-directional logical link,
henceforth referred to in this draft as “DSL bonded circuit”. DSL henceforth referred to in this draft as "DSL bonded circuit". DSL
“multi-pair” bonding allows an operator to combine the data rates "multi-pair" bonding allows an operator to combine the data rates
on two or more copper pairs, and deliver the aggregate data rate 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 to a single customer. ITU-T recommendations G.998.1 and G.998.2
respectively describe ATM and Ethernet based multi-pair bonding. 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,
skipping to change at page 6, line 29 skipping to change at page 6, line 36
and the NSP or ASP. These include traditional ATM-based offerings and and the NSP or ASP. These include traditional ATM-based offerings and
newer, more native IP-based services. This includes support for newer, more native IP-based services. This includes support for
Point-to-Point Protocol over ATM (PPPoA) and PPP over Ethernet Point-to-Point Protocol over ATM (PPPoA) and PPP over Ethernet
(PPPoE), as well as direct IP services encapsulated over an (PPPoE), as well as direct IP services encapsulated over an
appropriate layer 2 transport. appropriate layer 2 transport.
Beyond aggregation, NAS is also the injection point for policy Beyond aggregation, NAS is also the injection point for policy
management and IP QoS in the Regional/Access Networks. In order to management and IP QoS in the Regional/Access Networks. In order to
allow IP QoS support over an existing non-IP-aware layer 2 access allow IP QoS support over an existing non-IP-aware layer 2 access
network without using multiple layer 2 QoS classes, a mechanism based network without using multiple layer 2 QoS classes, a mechanism based
on hierarchical scheduling is used. This mechanism defined in [1], on hierarchical scheduling is used. This mechanism defined in [TR-
preserves IP QoS over the ATM network between the NAS and the RGs by 059], preserves IP QoS over the ATM network between the NAS and the
carefully controlling downstream traffic in the NAS, so that RGs by carefully controlling downstream traffic in the NAS, so that
significant queuing and congestion does not occur further down the significant queuing and congestion does not occur further down the
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 [ANCP-FRAMEWORK] provides detailed definition and functions of each
element in the broadband reference architecture. network element in the broadband reference architecture.
Access Customer Access Customer
<--- Aggregation ---> <------- Premises -------> <--- Aggregation ---> <------- Premises ------->
Network Network Network Network
+-------------------+ +----------------------------+ +-------------------+ +----------------------------+
+----------+ +-----+ | +-----+ +------+ |--|+-----+ +---+ +---------+ | +----------+ +-----+ | +-----+ +------+ |--|+-----+ +---+ +---------+ |
| | +-|NAS |--| |ATM |--|Access| | ||DSL |-|HGW|--|Subscriber|| | | +-|NAS |--| |ATM |--|Access| | ||DSL |-|HGW|--|Subscriber||
NSP---+Regional | | +-----+ | +-----+ | Node | | ||Modem| +---+ |Devices || NSP---+Regional | | +-----+ | +-----+ | Node | | ||Modem| +---+ |Devices ||
|Broadband | | +-----+ | +------+ | |+-----+ +----------+| |Broadband | | +-----+ | +------+ | |+-----+ +----------+|
skipping to change at page 7, line 39 skipping to change at page 7, line 39
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
defined in IEEE 802.1Q and being enhanced by IEEE 802.1ad is used as defined in IEEE 802.1Q and being enhanced by IEEE 802.1ad is used as
standard virtualization mechanism in the Ethernet aggregation network. standard virtualization mechanism in the Ethernet aggregation network.
The aggregation devices are “provider edge bridges” defined in IEEE The aggregation devices are "provider edge bridges" defined in IEEE
802.ad. 802.ad.
Stacked VLAN tags provide one possible way to create equivalent of Stacked VLAN tags provide one possible way to create equivalent of
“virtual paths” and “virtual circuits” in the aggregation network. The "virtual paths" and "virtual circuits" in the aggregation network. The
“outer” vlan could be used to create a form of “virtual path” between a "outer" vlan could be used to create a form of "virtual path" between a
given DSLAM and a given NAS. And “inner” VLAN tags to create a form of given DSLAM and a given NAS. And "inner" VLAN tags to create a form of
“virtual circuit” on a per DSL line basis. This is 1:1 VLAN allocation "virtual circuit" on a per DSL line basis. This is 1:1 VLAN allocation
model. An alternative model is to bridge sessions from multiple model. An alternative model is to bridge sessions from multiple
subscribers behind a DSLAM into a single VLAN in the aggregation subscribers behind a DSLAM into a single VLAN in the aggregation
network. This is N:1 VLAN allocation model. Architectural and network. This is N:1 VLAN allocation model. Architectural and
topological models of an Ethernet aggregation network in context of DSL topological models of an Ethernet aggregation network in context of DSL
aggregation are defined in [7]. aggregation are defined in [TR101].
4 Access Node Control Protocol 4 Access Node Control Protocol
4.1 Overview 4.1 Overview
A dedicated control protocol between NAS and access nodes can A dedicated control protocol between NAS and access nodes can
facilitate "NAS managed" tight QOS control in the access network, facilitate "NAS managed" tight QOS control in the access network,
simplified OSS infrastructure for service management, optimized simplified OSS infrastructure for service management, optimized
multicast replication to enable video services over DSL, subscriber multicast replication to enable video services over DSL, subscriber
statistics retrieval on the NAS for accounting purposes, and fault statistics retrieval on the NAS for accounting purposes, and fault
isolation capability on the NAS for the underlying access technology. isolation capability on the NAS for the underlying access technology.
This dedicated control plane is referred to as “Access Node Control This dedicated control plane is referred to as "Access Node Control
Protocol” (ANCP). This document specifies relevant extensions to Protocol" (ANCP). This document specifies relevant extensions to
GSMPv3 as defined [4] to realize ANCP. GSMPv3 as defined [RFC3292] to realize ANCP.
Following sections discuss the use of ANCP for implementing: Following sections discuss the use of ANCP for implementing:
. Dynamic discovery of access topology by the NAS to provide tight . Dynamic discovery of access topology by the NAS to provide tight
QOS control in the access network. QOS control in the access network.
. Pushing to the access-nodes, subscriber and service data . Pushing to the access-nodes, subscriber and service data
retrieved by the NAS from an OSS system (e.g. radius server), to retrieved by the NAS from an OSS system (e.g. radius server), to
simplify OSS infrastructure for service management. simplify OSS infrastructure for service management.
skipping to change at page 9, line 9 skipping to change at page 9, line 9
and/or parallel deployments. and/or parallel deployments.
GSMPv3 is an ideal fit for implementing ANCP. It is extensible and GSMPv3 is an ideal fit for implementing ANCP. It is extensible and
can be run over TCP/IP, which makes it possible to run over different can be run over TCP/IP, which makes it possible to run over different
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 [TR-059] 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 net data rates. Some of the links being used and their respective net data rates. Some of the
information required is somewhat dynamic in nature (e.g. DSL sync information required is somewhat dynamic in nature (e.g. DSL sync
rate, and therefore also the net data rate), hence cannot come from a rate, and therefore also the net data rate), hence cannot come from a
provisioning and/or inventory management OSS system. Some of the provisioning and/or inventory management OSS system. Some of the
information varies less frequently (e.g. capacity of a DSLAM uplink), information varies less frequently (e.g. capacity of a DSLAM uplink),
but nevertheless needs to be kept strictly in sync between the actual but nevertheless needs to be kept strictly in sync between the actual
capacity of the uplink and the image the NAS has of it. capacity of the uplink and the image the NAS has of it.
skipping to change at page 12, line 27 skipping to change at page 12, line 27
5. ----------------> 5. ---------------->
+-------------+ +-----+ +-------+ +----------+ +-----------+ +-------------+ +-----+ +-------+ +----------+ +-----------+
|Radius/AAA |------| NAS |---------| AN |------ | Home |------ |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)
skipping to change at page 13, line 42 skipping to change at page 13, line 43
subscription rights for the subscriber. Based on the user's subscription rights for the subscriber. Based on the user's
subscription, the NAS can replicate the same multicast stream to subscription, the NAS can replicate the same multicast stream to
multiple subscribers. This leads to a waste of access bandwidth if multiple subscribers. This leads to a waste of access bandwidth if
multiple subscribers access network services via the same access-node multiple subscribers access network services via the same access-node
(e.g. DSLAM). The amount of multicast replication is of the order of (e.g. DSLAM). The amount of multicast replication is of the order of
number of subscribers rather than the number of access-nodes. number of subscribers rather than the number of access-nodes.
It is ideal for NAS to send a single copy of the multicast stream to It is ideal for NAS to send a single copy of the multicast stream to
a given access-node, and let the access-node perform multicast a given access-node, and let the access-node perform multicast
replication by layer2 means (e.g. ATM point-to-multipoint cell replication by layer2 means (e.g. ATM point-to-multipoint cell
replication or ethernet data-link bridging) for subscribers behind replication or Ethernet data-link bridging) for subscribers behind
the access-node. However, operationally, NAS is the ideal choice to the access-node. However, operationally, NAS is the ideal choice to
handle subscriber management functions (authentication, handle subscriber management functions (authentication,
authorization, accounting and address management), multicast policies authorization, accounting and address management), multicast policies
such as per-channel authorization, and complex multicast routing such as per-channel authorization, and complex multicast routing
protocols. Therefore, some means is needed for the NAS to setup protocols. Therefore, some means is needed for the NAS to setup
multicast replication state in the access-nodes. In ATM access multicast replication state in the access-nodes. In ATM access
networks, ANCP can be used by the NAS to setup P2MP cross-connects in networks, ANCP can be used by the NAS to setup P2MP cross-connects in
the DSLAMs. Protocol support for this use-case will be provided in the DSLAMs. Protocol support for this use-case will be provided in
future. future.
skipping to change at page 14, line 28 skipping to change at page 14, line 28
in various network elements. in various network elements.
A simple solution based on ANCP can provide NAS with an access-line A simple solution based on ANCP can provide NAS with an access-line
test capability and to some extent fault isolation. Controlled by a test capability and to some extent fault isolation. Controlled by a
local management interface the NAS can use an ANCP operation to local management interface the NAS can use an ANCP operation to
trigger the access-node to perform a loopback test on the local-loop trigger the access-node to perform a loopback test on the local-loop
(between the access-node and the CPE). The access-node can respond (between the access-node and the CPE). The access-node can respond
via another ANCP operation the result of the triggered loopback test. via another ANCP operation the result of the triggered loopback test.
In case of ATM based local-loop the ANCP operation can trigger the In case of ATM based local-loop the ANCP operation can trigger the
access-node to generate ATM (F4/F5) loopback cells on the local loop. access-node to generate ATM (F4/F5) loopback cells on the local loop.
In case of Ethernet, the access-node can trigger an ethernet loopback In case of Ethernet, the access-node can trigger an Ethernet loopback
message(per EFM OAM) on the local-loop. message(per EFM OAM) on the local-loop.
4.5.1 Message Flow 4.5.1 Message Flow
“Port Management” message can be used by the NAS to request access "Port Management" message can be used by the NAS to request access
node to trigger a “remote loopback” test on the local loop. The node to trigger a "remote loopback" test on the local loop. The
result of the loopback test can be asynchronously conveyed by the result of the loopback test can be asynchronously conveyed by the
access node to the NAS in a “Port Management” response message. The access node to the NAS in a "Port Management" response message. The
format of relevant extensions to port management message is defined format of relevant extensions to port management message is defined
in section 5.4.4. in section 5.4.4.
Port Management Message Port Management Message
(Remote Loopback ATM loopback (Remote Loopback ATM loopback
Trigger Request) OR EFM Loopback Trigger Request) OR EFM Loopback
1. ----------------> 2. ----------> 1. ----------------> 2. ---------->
<---------+ <---------+
+-------------+ +-----+ +-------+ +-----------------+ +-------------+ +-----+ +-------+ +-----------------+
|Radius/AAA |------|NAS |---------| DSLAM |-------------| CPE | |Radius/AAA |------|NAS |---------| DSLAM |-------------| CPE |
|Policy Server| +-----+ +-------+ | (DSL Modem + | |Policy Server| +-----+ +-------+ | (DSL Modem + |
+-------------+ | Routing Gateway)| +-------------+ | Routing Gateway)|
+-----------------+ +-----------------+
3. <--------------- 3. <---------------
Port Management Message Port Management Message
(Remote Loopback Test Response) (Remote Loopback Test Response)
5 Access Node Control Protocol (ANCP) 5 Access Node Control Protocol (ANCP)
ANCP uses a subset of GSMPv3 messages described in [4] to implement ANCP uses a subset of GSMPv3 messages described in [RFC3292] to
currently defined use-cases. GSMPv3 general message format, used by implement currently defined use-cases. GSMPv3 general message format,
all GSMP messages other than adjacency protocol messages, is defined used by all GSMP messages other than adjacency protocol messages, is
in section 3.1.1 of GSMPv3 RFC [4]. ANCP modifies this base GSMPv3 defined in section 3.1.1 of GSMPv3 RFC [RFC3292]. ANCP modifies this
message format. The modified GSMPv3 message format is defined as base GSMPv3 message format. The modified GSMPv3 message format is
follows: defined as follows:
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 16, line 11 skipping to change at page 16, line 11
~ Message Payload ~ ~ Message Payload ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 8-bit version field in the base GSMPv3 message header is split The 8-bit version field in the base GSMPv3 message header is split
into two 4 bit fields for carrying the version and a sub-version of into two 4 bit fields for carrying the version and a sub-version of
the GSMP protocol. ANCP uses version 3 and sub-version 1 of the GSMP the GSMP protocol. ANCP uses version 3 and sub-version 1 of the GSMP
protocol. An ANCP implementation SHOULD always set the version field protocol. An ANCP implementation SHOULD always set the version field
to 3, and the sub-version field to 1. The Result field in the message to 3, and the sub-version field to 1. The Result field in the message
header has been modified to be 4 bits long, and the Code field to be header has been modified to be 4 bits long, and the Code field to be
12 bits long. The definition and semantics of all the fields in the 12 bits long. The definition and semantics of all the fields in the
header are described in section 3.1.1 of GSMPv3 RFC [4]. An ANCP header are described in section 3.1.1 of GSMPv3 RFC [RFC3292]. An
implementation SHOULD set the I and subMessage fields to 1 to signify ANCP implementation SHOULD set "I" and subMessage fields to 1 to
no fragmentation. signify no fragmentation.
Following are the relevant GSMPv3 messages defined in [4], that are Following are the relevant GSMPv3 messages defined in [RFC3292], that
currently used by ANCP. Other than the message types explicitly are currently used by ANCP. Other than the message types explicitly
listed below, no other GSMPv3 messages are used by ANCP currently. listed below, no other GSMPv3 messages are used by ANCP currently.
o Event Messages o Event Messages
o Port UP message o Port UP message
o Port DOWN message o Port DOWN message
These messages are used by ANCP topology discovery use-case. These messages are used by ANCP topology discovery use-case.
o Port Management Messages o Port Management Messages
These messages are used by ANCP “line configuration” use-case and These messages are used by ANCP "line configuration" use-case and
ANCP OAM use-case. ANCP OAM use-case.
o Adjacency Protocol Messages o Adjacency Protocol Messages
These messages are used to bring up a protocol adjacency between a These messages are used to bring up a protocol adjacency between a
NAS and an AN. NAS and an AN.
The basic format and semantics of various fields in these GSMPv3 The basic format and semantics of various fields in these GSMPv3
messages identified above are described in GSMPv3 RFC [4]. However, messages identified above are described in GSMPv3 RFC [RFC3292].
the usage of these messages by ANCP, along with relevant However, the usage of these messages by ANCP, along with relevant
modifications and extensions required by ANCP, are described in modifications and extensions required by ANCP, are described in
sections 5.3, 5.4.1, 5.4.2 and 5.4.3 of this document. Messages used sections 5.3, 5.4.1, 5.4.2 and 5.4.3 of this document. Messages used
by ANCP multicast use-case will be described in future versions of by ANCP multicast use-case will be described in future versions of
this document. this document.
ANCP modifies and extends few basic GSMPv3 procedures. These ANCP modifies and extends few basic GSMPv3 procedures. These
modifications and extensions are summarized below, and described in modifications and extensions are summarized below, and described in
more detail in the succeeding sections. more detail in the succeeding sections.
o ANCP provides support for a capability negotiation mechanism o ANCP provides support for a capability negotiation mechanism
between ANCP peers by extending the GSMPv3 adjacency protocol. between ANCP peers by extending the GSMPv3 adjacency protocol.
This mechanism and corresponding adjacency message extensions This mechanism and corresponding adjacency message extensions
are defined in section 5.3. are defined in section 5.3.
o TCP connection establishment procedure in ANCP deviates o TCP connection establishment procedure in ANCP deviates
slightly from the connection establishment in GSMPv3 as slightly from the connection establishment in GSMPv3 as
specified in [5]. This is described in section 5.1. specified in [RFC3293]. This is described in section 5.1.
o ANCP makes GSMPv3 messages extensible and flexible by adding a o ANCP makes GSMPv3 messages extensible and flexible by adding a
general “extension block” to the end of the relevant GSMPv3 general "extension block" to the end of the relevant GSMPv3
messages. The “extension block” contains a TLV structure to messages. The "extension block" contains a TLV structure to
carry information relevant to each ANCP use-case. The format of carry information relevant to each ANCP use-case. The format of
the “extension block” is defined in section 5.4.1.1. the "extension block" is defined in section 5.4.1.1.
o ANCP extends GSMPv3 message exchange with a “bulk transaction”
capability, where multiple GSMPv3 messages can be bundled into
a single GSMPv3 transaction. This is described in section
5.4.1.2.
5.1 ANCP/TCP connection establishment 5.1 ANCP/TCP connection establishment
ANCP will use TCP for exchanging protocol messages. [5] defines the ANCP will use TCP for exchanging protocol messages. [RFC3293] defines
GSMP message encapsulation for TCP. The TCP session is initiated the GSMP message encapsulation for TCP. The TCP session is
from the DSLAM (access node) to the NAS (controller). This is initiated from the DSLAM (access node) to the NAS (controller). This
necessary to avoid static provisioning on the NAS for all the DSLAMs is necessary to avoid static provisioning on the NAS for all the
that are being served by the NAS. It is easier to configure a given DSLAMs that are being served by the NAS. It is easier to configure a
DSLAM with the single IP address of the NAS that serves the DSLAM. given DSLAM with the single IP address of the NAS that serves the
This is a deviation from [5] which indicates that the controller DSLAM. This is a deviation from [RFC3293] which indicates that the
initiates the TCP connection to the switch. controller initiates the TCP connection to the switch.
NAS listens for incoming connections from the access nodes. Port 6068 NAS listens for incoming connections from the access nodes. Port 6068
is used for TCP connection. Adjacency protocol messages, which are is used for TCP connection. Adjacency protocol messages, which are
used to synchronize the NAS and access-nodes and maintain handshakes, used to synchronize the NAS and access-nodes and maintain handshakes,
are sent after the TCP connection is established. ANCP messages other are sent after the TCP connection is established. ANCP messages other
than adjacency protocol messages may be sent only after the adjacency than adjacency protocol messages may be sent only after the adjacency
protocol has achieved synchronization. protocol has achieved synchronization.
In the case of ATM access, a separate PVC (control channel) capable In the case of ATM access, a separate PVC (control channel) capable
of transporting IP would be configured between NAS and the DSLAM for of transporting IP would be configured between NAS and the DSLAM for
skipping to change at page 18, line 20 skipping to change at page 18, line 15
to the base GSMP adjacency protocol for implementing ANCP. to the base GSMP adjacency protocol for implementing ANCP.
The NAS will set the M-flag in the SYN message (signifying it is the The NAS will set the M-flag in the SYN message (signifying it is the
master). Once the adjacency is established, periodic adjacency master). Once the adjacency is established, periodic adjacency
messages (type ACK) are exchanged. The default ACK interval as messages (type ACK) are exchanged. The default ACK interval as
advertised in the adjacency messages is 10 sec for ANCP. It SHOULD be advertised in the adjacency messages is 10 sec for ANCP. It SHOULD be
configurable and is an implementation choice. It is recommended that configurable and is an implementation choice. It is recommended that
both ends specify the same timer value. However, it is not necessary both ends specify the same timer value. However, it is not necessary
for the timer values to match. for the timer values to match.
The GSMP adjacency message defined in [4] is extended for ANCP and is The GSMP adjacency message defined in [RFC3292] is extended for ANCP
shown in section 5.3 immediately following this section. The 8-bit and is shown in section 5.3 immediately following this section. The
“version” field in the adjacency protocol messages is modified to 8-bit "version" field in the adjacency protocol messages is modified
carry the version and sub-version of the GSMP protocol for version to carry the version and sub-version of the GSMP protocol for version
negotiation. ANCP uses version 3 and sub-version 1 of GSMP protocol. negotiation. ANCP uses version 3 and sub-version 1 of GSMP protocol.
The semantics and suggested values for Code, “Sender Name”, “Receiver The semantics and suggested values for Code, "Sender Name", "Receiver
Name”, “Sender Instance”, and “Receiver Instance” fields are as Name", "Sender Instance", and "Receiver Instance" fields are as
defined in [4]. The “Sender Port”, and “Receiver Port” should be set defined in [RFC3292]. The "Sender Port", and "Receiver Port" should
to 0 by both ends. The pType field should be set to 0. The pFlag be set to 0 by both ends. The pType field should be set to 0. The
should be set to 1. pFlag should be set to 1.
If the adjacency times out on either end, due to not receiving an If the adjacency times out on either end, due to not receiving an
adjacency message for a duration of (3 * Timer value), where the adjacency message for a duration of (3 * Timer value), where the
timer value is specified in the adjacency message, all the state timer value is specified in the adjacency message, all the state
received from the ANCP neighbor should be cleaned up, and the TCP received from the ANCP neighbor should be cleaned up, and the TCP
connection should be closed. The NAS would continue to listen for new connection should be closed. The NAS would continue to listen for new
connection requests. The DSLAM will try to re-establish the TCP connection requests. The DSLAM will try to re-establish the TCP
connection and both sides will attempt to re-establish the adjacency. connection and both sides will attempt to re-establish the adjacency.
The handling defined above will need some modifications when ANCP The handling defined above will need some modifications when ANCP
graceful restart procedures are defined. These procedures will be graceful restart procedures are defined. These procedures will be
defined in a separate draft. defined in a separate draft.
5.3 Capability negotiation 5.3 Capability negotiation
The adjacency message as defined in [4] is extended to carry The adjacency message as defined in [RFC3292] is extended to carry
technology specific "Capability TLVs". Both the NAS and the access technology specific "Capability TLVs". Both the NAS and the access
node will advertise supported capabilities in the originated node will advertise supported capabilities in the originated
adjacency messages. If a received adjacency message indicates absence adjacency messages. If a received adjacency message indicates absence
of support for a capability that is supported by the receiving of support for a capability that is supported by the receiving
device, it will turn off the capability locally and will send an device, it will turn off the capability locally and will send an
updated adjacency message with the capability turned off to match the updated adjacency message with the capability turned off to match the
received capability set. This process will eventually result in both received capability set. This process will eventually result in both
sides agreeing on the minimal set of supported capabilities. The sides agreeing on the minimal set of supported capabilities. The
adjacency will not come up unless the capabilities advertised by the adjacency will not come up unless the capabilities advertised by the
controller and the controlled device match. controller and the controlled device match.
skipping to change at page 20, line 45 skipping to change at page 20, line 45
Capability Data : NULL Capability Data : NULL
2. Capability Type : Line-Configuration = 0x02 2. Capability Type : Line-Configuration = 0x02
Length (in bytes) : 0 Length (in bytes) : 0
Capability Data : NULL Capability Data : NULL
3. Capability Type : Transactional-Multicast = 0x03 (controller 3. Capability Type : Transactional-Multicast = 0x03 (controller
i.e. NAS terminates IGMP messages from subscribers, and via l2 i.e. NAS terminates IGMP messages from subscribers, and via l2 control protocol, signals state to the access-nodes (e.g.
control protocol, signals state to the access-nodes (e.g.
DSLAMs) to enable layer2 replication of multicast streams. In DSLAMs) to enable layer2 replication of multicast streams. In
ATM access network this implies that NAS instructs the access- ATM access network this implies that NAS instructs the access-
node to setup a P2MP cross-connect. The details of this will be node to setup a P2MP cross-connect. The details of this will be
covered in a separate ID [6]. covered in a separate ID.
Length (in bytes) : 0 Length (in bytes) : 0
Capability Data : NULL Capability Data : NULL
4. Capability Type : OAM = 0x04 4. Capability Type : OAM = 0x04
Length (in bytes) : 0 Length (in bytes) : 0
Capability Data : NULL Capability Data : NULL
5. Capability Type : Bulk Transaction = 0x05 (defined in section
5.4.1.2).
Length (in bytes) : 0
Capability Data : NULL
5.4 GSMP Message Extensions for Access Node Control 5.4 GSMP Message Extensions for Access Node Control
5.4.1 General Extensions 5.4.1 General Extensions
Extensions to GSMP messages for various use-cases of “Acess Node Extensions to GSMP messages for various use-cases of "Acess Node
Control” mechanism are defined in sections 5.4.2 to 5.4.4. However, Control" mechanism are defined in sections 5.4.2 to 5.4.4. However,
sub-sections 5.4.1.1 and 5.4.1.2 below define extensions to GSMP that sub-sections 5.4.1.1 and 5.4.1.2 below define extensions to GSMP that
have general applicability. have general applicability.
5.4.1.1 Extension TLV 5.4.1.1 Extension TLV
In order to provide flexibility and extensibility certain GSMP In order to provide flexibility and extensibility certain GSMP
messages such as “PORT MANAGEMENT” and “EVENT” messages defined in messages such as "PORT MANAGEMENT" and "EVENT" messages defined in
[4] have been modified to include an extension block that follows a [RFC3292] have been modified to include an extension block that
TLV structure. Individual messages in the following sections describe follows a TLV structure. Individual messages in the following
the usage and format of the extension block. sections describe the usage and format of the extension block.
All Extension TLV's will be designated as follow: All Extension TLVs will be designated as follow:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length | |x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Extension Value ~ ~ Extension Value ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 22, line 32 skipping to change at page 22, line 32
Message Type Message Type
An 8-bit field corresponding to the message type where the An 8-bit field corresponding to the message type where the
extension block is used. extension block is used.
Tech Type Tech Type
An 8-bit field indicating the applicable technology type value. An 8-bit field indicating the applicable technology type value.
The Message Type plus the Tech Value uniquely define a single The Message Type plus the Tech Value uniquely define a single
Extension Type and can be treated as a single 16 bit extension Extension Type and can be treated as a single 16 bit extension
type. “Tech Type” value of 0x05 SHOULD be used by ANCP for DSL type. "Tech Type" value of 0x05 SHOULD be used by ANCP for DSL
technology. technology.
0x00 Extension block not it use. 0x00 Extension block not it use.
0x01 0x04 Already in use by various technologies 0x01 - 0x04 Already in use by various technologies
0x05 DSL 0x05 DSL
0x06 - 0xFE Reserved 0x06 - 0xFE Reserved
0xFF Base Specification Use 0xFF Base Specification Use
Block Length Block Length
A 8-bit field indicating the length of the Extension Value A 8-bit field indicating the length of the Extension Value
field in bytes. When the Tech Type = 0x00, the length value field in bytes. When the Tech Type = 0x00, the length value
MUST be set to 0. MUST be set to 0.
Extension Value Extension Value
A variable length field that is an integer number of 32 bit A variable length field that is an integer number of 32 bit
words long. The Extension Value field is interpreted according words long. The Extension Value field is interpreted according
to the specific definitions provided by the messages in the to the specific definitions provided by the messages in the
following sections. following sections.
5.4.1.2 Bulk Transaction Message 5.4.2 Topology Discovery Extensions
ANCP elements MAY support a bulk transaction capability. This
capability is negotiated during adjacency synchronization and follows
general ANCP capability negotiation rules.
In a bulk transaction, several messages can be bundled together in a
single transaction. Bulk transaction uses message type 13. Reception
of “Bulk Transaction Message” by a node that has not advertised bulk
transaction capability MUST silently discard the received message.
The Bulk Transaction message has the following format:
0 1 2 3 The GSMP Event message with PORT UP message type (80) is used for
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 conveying DSL line attributes to the NAS. The message SHOULD be
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ generated when a line first comes UP, or any of the attributes of the
| Vers | Sub | Message Type | Result| Code | line change e.g. the line re-trains to a different rate or one or more
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ of the configured line attributes are administratively modified. Also,
| Partition ID | Transaction Identifier | when the ANCP session first comes up, the DSLSM SHOULD transmit a PORT
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UP message to the NAS for each line that is up. When a DSL line goes
|I| SubMessage Number | Length | down (idle or silent), the DSLAM SHOULD transmit an Event message with
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PORT DOWN message type (81) to the NAS. It is recommended that the
| Reserved | Count | DSLAMs use a dampening mechanism per DSL line to control the rate of
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ state changes per DSL line, communicated to the NAS.
| |
~ Message Payload ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In a Bulk Transaction Message, each of the message in the payload is Not all the fields in GSMP Event message are applicable to ANCP. The
framed with a complete header and is acted on individually. The fields that are not applicable are set to 0 by the ANCP sender, and
response to the Bulk Transaction message contains the response ignored by the receiver. The fields in the PORT UP and PORT DOWN
message that would have been generated by each of the messages had it messages to be set by the ANCP sender, and corresponding handling by the
been sent individually. Each response message will have the ANCP receiver is described below.
appropriate result and code field filled. Any message can be included
in the bulk Transaction message except for adjacency message and
another bulk transaction message. If a prohibited message is included
in a bulk Transaction message, it MUST be included in the Bulk
response with a failure response. The response code for that failure
is 0x81 (“Message type prohibited in bulk Transaction”). While the
individual message would fail, this would not constitute a failure
for the Bulk Transaction message
5.4.2 Topology Discovery Extensions The version field MUST be set to 3, and the sub field MUST be set to 1.
As defined in [RFC3292], the one byte Message Type field MUST be set to
80 for PORT UP Event message, and to 81 for PORT DOWN Event Message. The
4 bit Result field and the 8 bit Code field MUST both be set to 0. The
24-bit Transaction Identifier field MUST be set to 0. The "I" bit and
the SubMessage field MUST be set to 1 to signify no fragmentation. The
Length field is two bytes and MUST contain the length of the message
(including header and the payload) in bytes.
The GSMP Event message with PORT UP message type (80) is used for The "Port" field, "Port Session Number" field and "Event Sequence
conveying DSL line attributes to the NAS. The version field should be Number" field are 4 bytes each, and MUST be set to 0 by the ANCP sender.
set to 3, and the sub field should be set to 1. The I and subMessage LABEL field in event messages is defined as a TLV in [RFC 3292]. ANCP
fields SHOULD be set to 1 to signify no fragmentation. The Port and does NOT use the Label TLV. In both PORT UP and PORT DOWN event messages
Label fields should be set to 0. The “Port Session Number” should be set an ANCP sender MUST treat the Label field, immediately following the
to 0, and the “Event Sequence Number” should be 0. The Tech Type field "Event Sequence Number" field, as a fixed 8 byte field, and MUST set
is extended with new type "DSL". The value for this field is 0x05. The these 8 bytes to 0. The receiver MUST not interpret the LABEL field as a
message SHOULD be generated when a line first comes UP, or any of the TLV and MUST ignore the 8 bytes immediately following the "Event
attributes of the line change e.g. the line re-trains to a different Sequence Number" field. In future versions of ANCP, if necessary the
rate or one or more of the configured line attributes are un-used fields in GSMP Event message, which do not have ANCP specific
administratively modified. Also, when the ANCP session first comes up, semantics, can be used partially or completely, by re-naming
the DSLSM SHOULD transmit a PORT UP message to the NAS for each line appropriately, and associating valid semantics with these fields.
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.
When a DSL line goes down (idle or silent), the DSLAM SHOULD transmit an The Tech Type field is extended with new type "DSL". The value for this
Event message with PORT DOWN message type (81) to the NAS. It is field is 0x05.
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.
In case of bonded copper loops to the customer premise (as per DSL 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 multi-pair bonding described by [G.998.1] and [G.998.2]), the DSLAM MUST
aggregate net data rate and other attributes for the “DSL bonded report the aggregate net data rate and other attributes for the "DSL
circuit” (represented as a single logical port) to the NAS in a PORT UP bonded circuit" (represented as a single logical port) to the NAS in a
message. Any change in the aggregate net data rate of the “DSL bonded PORT UP message. Any change in the aggregate net data rate of the "DSL
circuit” (due to a change in net data rate of individual constituent DSL bonded circuit" (due to a change in net data rate of individual
lines or due to change in state of the individual constituent DSL lines) constituent DSL lines or due to change in state of the individual
MUST be reported by the DSLAM to the NAS in a PORT UP message. The DSLAM constituent DSL lines) MUST be reported by the DSLAM to the NAS in a
MUST also report the “aggregate” state of the “DSL bonded circuit” to PORT UP message. The DSLAM MUST also report the "aggregate" state of the
the NAS via PORT UP and PORT DOWN messages. "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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number | | Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Sequence Number | | Event Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| | | |
+-+-+-+-+ Label | + Label +
~ ~ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length | |x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Extension Value ~ ~ Extension Value ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the "Extension Value" field for Tech Type “DSL” is The format of the "Extension Value" field for Tech Type "DSL" is
as follows : as follows :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs | Extension block length (bytes)| | # of TLVs | Extension block length (bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ ~ ~ ~
~ TLVs ~ ~ TLVs ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The “Extension Value” contains one or more TLVs to identify a DSL line The "Extension Value" contains one or more TLVs to identify a DSL line
and define it’s characteristics. A TLV can consist of multiple sub-TLVs. and define its characteristics. A TLV can consist of multiple sub-TLVs.
First 2 byte of the “Extension Value” contains the number of TLVs that First 2 byte of the "Extension Value" contains the number of TLVs that
follow. The next 2 bytes contain the total length of the TLVs carried in follow. The next 2 bytes contain the total length of the TLVs carried in
the extension block in bytes (existing “Block Length” field in the GSMP the extension block in bytes (existing "Block Length" field in the GSMP
message is limited to 255 bytes and is not sufficient). message is limited to 255 bytes and is not sufficient).
General format of a TLV is : General format of a TLV is :
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ ~ ~ ~
skipping to change at page 26, line 25 skipping to change at page 26, line 25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value field in each TLV is padded to a 4-octet alignment. The Length The value field in each TLV is padded to a 4-octet alignment. The Length
field in each TLV contains the actual number of bytes in the TLV (not field in each TLV contains the actual number of bytes in the TLV (not
including the padding if present). If a TLV is not understood by the including the padding if present). If a TLV is not understood by the
NAS, it is silently ignored. Currently defined types start from 0x01. NAS, it is silently ignored. Currently defined types start from 0x01.
Following TLVs are currently defined: Following TLVs are currently defined:
1. Type (Access-Loop-Circuit-ID = 0x01): This is a mandatory TLV and 1. Type (Access-Loop-Circuit-ID = 0x01): This is a mandatory TLV and
contains an identifier of the subscriber’s connection to the access contains an identifier of the subscriber's connection to the access
node (i.e. “local loop”). The “local loop” can be ATM based or node (i.e. "local loop"). The "local loop" can be ATM based or
Ethernet based. The “Access Loop Circuit ID” has local significance Ethernet based. The "Access Loop Circuit ID" has local significance
at the access node. The exact usage on the NAS is beyond the scope at the access node. The exact usage on the NAS is beyond the scope
of this document. The format used for “local loop” identification of this document. The format used for "local loop" identification
in ANCP messages MUST be identical to what is used by the access in ANCP messages MUST be identical to what is used by the access
nodes in subscriber signaling messages when the access nodes act as nodes in subscriber signaling messages when the access nodes act as
“signaling relay agents” as outlined in [6] and [7]. "signaling relay agents" as outlined in [RFC3046] and [TR-101].
Length : (upto 63 bytes) Length : (upto 63 bytes)
Value : ASCII string. Value : ASCII string.
For an ATM based local loop the string consists of slot/port and For an ATM based local loop the string consists of slot/port and
VPI/VCI information corresponding to the subscribers DSL VPI/VCI information corresponding to the subscriber's DSL
connection. Default syntax for the string inserted by the access connection. Default syntax for the string inserted by the access
node as per [7] is: node as per [TR101] is:
“Access-Node-Identifier atm slot/port:vpi.vci” "Access-Node-Identifier atm slot/port:vpi.vci"
The Access-Node-Identifier uniquely identifies the access node in The Access-Node-Identifier uniquely identifies the access node in
the access network. The slot/port and VPI/VCI uniquely identifies the access network. The slot/port and VPI/VCI uniquely identifies
the DSL line on the access node. Also, there is one to one the DSL line on the access node. Also, there is one to one
correspondence between DSL line and the VC between the access node correspondence between DSL line and the VC between the access node
and the NAS. and the NAS.
For local loop which is Ethernet based (and tagged), the string For local loop which is Ethernet based (and tagged), the string
consists of slot/port and VLAN tag corresponding to the consists of slot/port and VLAN tag corresponding to the
subscriber. Default syntax for the string inserted by the access subscriber. Default syntax for the string inserted by the access
node as per [7] is: node as per [TR101] is:
"Access-Node-Identifier eth slot/port[:vlan-id]" "Access-Node-Identifier eth slot/port[:vlan-id]"
2. Type (Access-Loop-Remote-Id = 0x02): This is an optional TLV and 2. Type (Access-Loop-Remote-Id = 0x02): This is an optional TLV and
contains an identifier to uniquely identify a user on a local loop contains an identifier to uniquely identify a user on a local loop
on the access node. The exact usage on the NAS is out of scope of on the access node. The exact usage on the NAS is out of scope of
this document. It is desirable that the format used for the field this document. It is desirable that the format used for the field
is similar to what is used by the access nodes in subscriber is similar to what is used by the access nodes in subscriber
signaling messages when the access nodes act as “signaling relay signaling messages when the access nodes act as "signaling relay
agents” as outlined in [6] and [7]. agents" as outlined in [RFC3046] and [TR101].
Length : (upto 63 bytes) Length : (upto 63 bytes)
Value : ASCII string Value : ASCII string
3. Type (Access-Aggregation-Circuit-ID-Binary = 0x06) 3. Type (Access-Aggregation-Circuit-ID-Binary = 0x06)
Length : (8 bytes) Length : (8 bytes)
Value : two 32 bit integers. Value : two 32 bit integers.
For ethernet access aggregation, where a per-subscriber (stacked) For ethernet access aggregation, where a per-subscriber (stacked)
VLAN can be applied (1:1 model defined in [7]), the VLAN stack VLAN can be applied (1:1 model defined in [TR101]), the VLAN stack
provides a convenient way to uniquely identify the DSL line. The provides a convenient way to uniquely identify the DSL line. The
outer VLAN is equivalent to virtual path between a DSLAM and the outer VLAN is equivalent to virtual path between a DSLAM and the
NAS and inner VLAN is equivalent to a virtual circuit on a per DSL NAS and inner VLAN is equivalent to a virtual circuit on a per DSL
line basis. In this scenario, any subscriber data received by the line basis. In this scenario, any subscriber data received by the
access node and transmitted out the uplink to the aggregation access node and transmitted out the uplink to the aggregation
network will be tagged with the VLAN stack assigned by the access network will be tagged with the VLAN stack assigned by the access
node node
This TLV can carry the VLAN tags assigned by the access node in the This TLV can carry the VLAN tags assigned by the access node in the
ANCP messages. The VLAN tags can uniquely identify the DSL line ANCP messages. The VLAN tags can uniquely identify the DSL line
skipping to change at page 28, line 25 skipping to change at page 28, line 25
Length : (upto 63 bytes) Length : (upto 63 bytes)
Value : ASCII string. Value : ASCII string.
This field contains information pertaining to an uplink on the This field contains information pertaining to an uplink on the
access node. For Ethernet access aggregation, assuming the access access node. For Ethernet access aggregation, assuming the access
node assigns VLAN tags (1:1 model), typical format for the string node assigns VLAN tags (1:1 model), typical format for the string
is: is:
“Access-Node-Identifier eth slot/port [:inner-vlan-id][:outer-vlan-id]” "Access-Node-Identifier eth slot/port [:inner-vlan-id][:outer-vlan-id]"
The slot/port corresponds to the ethernet uplink on the access node The slot/port corresponds to the ethernet uplink on the access node
towards the NAS. towards the NAS.
For an ATM aggregation network, typical format for the string is: For an ATM aggregation network, typical format for the string is:
“Access-Node-Identifier atm slot/port:vpi.vci” "Access-Node-Identifier atm slot/port:vpi.vci"
This TLV allows the NAS to associate the information contained in This TLV allows the NAS to associate the information contained in
the ANCP messages to the DSL line on the access node. the ANCP messages to the DSL line on the access node.
If the access node inserts this string in the ANCP messages, when If the access node inserts this string in the ANCP messages, when
referring to local loop characteristics (e.g. DSL line in case of a referring to local loop characteristics (e.g. DSL line in case of a
DSLAM), then it should be able to map the information contained in DSLAM), then it should be able to map the information contained in
the string uniquely to the local loop (e.g. DSL line). the string uniquely to the local loop (e.g. DSL line).
On the NAS, the information contained in this string can be used to On the NAS, the information contained in this string can be used to
derive an “aggregation network” facing construct (e.g. an IP derive an "aggregation network" facing construct (e.g. an IP
interface) corresponding to the local loop (e.g. DSL line). The interface) corresponding to the local loop (e.g. DSL line). The
association could be based on “local configuration” on the NAS. association could be based on "local configuration" on the NAS.
The access node can also convey to the NAS, the characteristics The access node can also convey to the NAS, the characteristics
(e.g. bandwidth) of the uplink on the access node. This TLV then (e.g. bandwidth) of the uplink on the access node. This TLV then
serves the purpose of uniquely identifying the uplink whose serves the purpose of uniquely identifying the uplink whose
characteristics are being defined. A separate set of sub-TLVs will characteristics are being defined. A separate set of sub-TLVs will
be defined for the uplink characteristics (TBD). be defined for the uplink characteristics (TBD).
This TLV is optional. This TLV is optional.
5. Type (DSL Line Attributes = 0x04): 5. Type (DSL Line Attributes = 0x04):
Length : variable (up to 1024 bytes) Length : variable (up to 1024 bytes)
Value : This consists of one or more Sub-TLVs corresponding to DSL Value : This is a mandatory TLV and consists of one or more Sub-
line attributes. No sub-TLVs other than the “DSL type” and “DSL TLVs corresponding to DSL line attributes. No sub-TLVs other than
line state” SHOULD be included in a PORT DOWN message. the "DSL type" and "DSL line state" SHOULD be included in a PORT
DOWN message.
The general format of the sub-TLVs is identical to the general TLV The general format of the sub-TLVs is identical to the general TLV
format. The value field in each sub-TLV is padded to a 4-octet format. The value field in each sub-TLV is padded to a 4-octet
alignment. The Length field in each sub-TLV contains the actual alignment. The Length field in each sub-TLV contains the actual
number of bytes in the TLV (not including the padding if present). number of bytes in the TLV (not including the padding if present).
Current defined sub-TLV types are start from 0x81. Current defined sub-TLV types are start from 0x81.
Following sub-TLVs are currently defined : Following sub-TLVs are currently defined :
. Type (DSL-Type = 0x91) : Defines the type of transmission system . Type (DSL-Type = 0x91) : Defines the type of transmission system
skipping to change at page 33, 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 Port Management message format defined in [4] has been modified to The Port Management message format defined in [RFC3292] has been
contain an extension block (described above in section 5.4.1.1) at the modified to contain an extension block (described above in section
end of the message. Also, the original two byte Function field has been 5.4.1.1) at the end of the message. Also, the original two byte Function
modified to contain one byte for the Function field indicating a field has been modified to contain one byte for the Function field
specific action to be taken by the recipient of the message, and one indicating a specific action to be taken by the recipient of the
byte for X-Function field, which could further qualify the action message, and one byte for X-Function field, which could further qualify
specified in the Function field. Any Function specific data MUST be the action specified in the Function field. Any Function specific data
carried in the extension block. MUST be carried in the extension block.
The NAS uses the extension block in the Port Management messages to The NAS uses the extension block in the Port Management messages to
convey service attributes of the DSL lines to the DSLAM. TLVs are convey service attributes of the DSL lines to the DSLAM. TLVs are
defined for DSL line identification and service data for the DSL lines. 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 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 Connection Service Data" (value 0x8) is defined. The "Function" field is
set to the action type. This action type indicates to the device being set to the action type. This action type indicates to the device being
controlled (Access Node i.e. DSLAM) to apply service configuration data controlled (Access Node i.e. DSLAM) to apply service configuration data
contained in the extension value (TLVs), to the DSL line (identified by 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 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 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 Type field is extended with new type "DSL". The value for this field is
0x05. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 34, line 42 skipping to change at page 34, line 42
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs | Extension Block length (bytes)| | # of TLVs | Extension Block length (bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ ~ ~ ~
~ TLVs ~ ~ TLVs ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The “Extension Value” field contains one or more TLVs containing DSL The "Extension Value" field contains one or more TLVs containing DSL
line identifier and desired service attributes of the the DSL line. line identifier and desired service attributes of the the DSL line.
First 2 byte of the “Extension Value” contains the number of TLVs First 2 byte of the "Extension Value" contains the number of TLVs
that follow. The next 2 bytes contain the total length of the that follow. The next 2 bytes contain the total length of the
extension block in bytes (existing “Block Length” field in the GSMP extension block in bytes (existing "Block Length" field in the GSMP
message is limited to 255 bytes and is not sufficient). message is limited to 255 bytes and is not sufficient).
General format of a TLV is: General format of a TLV is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ ~ ~ ~
~ Value ~ ~ Value ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value field is padded to a 4-octet alignment. The Length field in The value field is padded to a 4-octet alignment. The Length field in
each TLV contains the actual number of bytes in the TLV (not each TLV contains the actual number of bytes in the TLV (not
including the padding if present). If a TLV is not understood by the including the padding if present). If a TLV is not understood by the
access-node, it is silently ignored. Depending upon the deployment access-node, it is silently ignored. Depending upon the deployment
scenario, the NAS may specify “Access Loop Circuit-ID” or the “Access scenario, the NAS may specify "Access Loop Circuit-ID" or the "Access
Aggregation Circuit-ID) as defined in section 5.4.1. Following TLVs Aggregation Circuit-ID") as defined in section 5.4.1. Following TLVs
can appear in this message: can appear in this message:
o Type (Access-Loop-Circuit-ID = 0x01) : defined in section 5.4.1 o Type (Access-Loop-Circuit-ID = 0x01) : defined in section 5.4.1
o Type (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in o Type (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in
section 5.4.1. section 5.4.1.
o Type (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in section o Type (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in section
5.4.1. 5.4.1.
skipping to change at page 36, line 7 skipping to change at page 36, line 7
Value : ASCII string containing the profile name (NAS learns Value : ASCII string containing the profile name (NAS learns
from a policy server after a subscriber is authorized). from a policy server after a subscriber is authorized).
In future, more TLVs MAY be defined for individual service attributes In future, more TLVs MAY be defined for individual service attributes
of a DSL line (e.g. rates, interleaving delay, multicast channel of a DSL line (e.g. rates, interleaving delay, multicast channel
entitlement access-list etc). entitlement access-list etc).
5.4.4 OAM Extensions 5.4.4 OAM Extensions
GSMP “Port Management” message (type 32) SHOULD be used by the NAS to GSMP "Port Management" message (type 32) SHOULD be used by the NAS to
trigger access node to run a loopback test on the local loop. The trigger access node to run a loopback test on the local loop. The
message format is defined in section 5.4.2. The version field SHOULD message format is defined in section 5.4.2. The version field SHOULD
be set to 3 and sub-version field SHOULD be set to 1. The remaining be set to 3 and sub-version field SHOULD be set to 1. The remaining
fields in the GSMP header have standard semantics. The function type fields in the GSMP header have standard semantics. The function type
used in the request message SHOULD be set to “remote loopback” (type used in the request message SHOULD be set to "remote loopback" (type
= 0x09). The port, “port session number”, “event sequence number”, = 0x09). The port, "port session number", "event sequence number",
duration, “event flags”, “flow control flags” and code fields SHOULD duration, "event flags", "flow control flags" and code fields SHOULD
all be set to 0. The result field SHOULD be set to “AckAll” to all be set to 0. The result field SHOULD be set to "AckAll" to
indicate requirement for the access node to send a success for indicate requirement for the access node to send a success or failure
failure response. The transaction ID SHOULD contain a sequence number response. The transaction ID SHOULD contain a sequence number
inserted by the NAS in each request that it generates. The extension inserted by the NAS in each request that it generates. The extension
field format is also defined above in section 5.4.2. The extension field format is also defined above in section 5.4.2. The extension
value field can contain one or more TLVs including the access-line value field can contain one or more TLVs including the access-line
identifier on the DSLAM and OAM test characteristics desired by the identifier on the DSLAM and OAM test characteristics desired by the
NAS. NAS.
The TLV format is defined above in section 5.4.2. The value field is The TLV format is defined above in section 5.4.2. The value field is
padded to a 4-octet alignment. The Length field in each TLV contains padded to a 4-octet alignment. The Length field in each TLV contains
the actual number of bytes in the TLV (not including the padding if the actual number of bytes in the TLV (not including the padding if
present). If a TLV is not understood by the NAS, it is silently present). If a TLV is not understood by the NAS, it is silently
ignored. Depending upon the deployment scenario, the NAS may specify ignored. Depending upon the deployment scenario, the NAS may specify
“Access Loop Circuit-ID” or the “Access Aggregation Circuit-ID) as "Access Loop Circuit-ID" or the "Access Aggregation Circuit-ID") as
defined in section 5.4.1. Following TLVs can appear in this message: defined in section 5.4.1. Following TLVs can appear in this message:
o Type (Access-Loop-Circuit-ID = 0x01) : defined in section 5.4.1 o Type (Access-Loop-Circuit-ID = 0x01) : defined in section 5.4.1
o Type (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in o Type (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in
section 5.4.1. section 5.4.1.
o Type (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in section o Type (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in section
5.4.1. 5.4.1.
skipping to change at page 37, line 7 skipping to change at page 37, line 7
Length: 4 bytes Length: 4 bytes
Value : two 1 byte numbers described below (listed in order of Value : two 1 byte numbers described below (listed in order of
most to least significant). Thus, the 4 bytes consist of 1 byte most to least significant). Thus, the 4 bytes consist of 1 byte
of Count, followed by 1 byte of Timeout, followed by two pad bytes of Count, followed by 1 byte of Timeout, followed by two pad bytes
of zero. of zero.
o Count (1 byte) : Number of loopback cells/messages that should o Count (1 byte) : Number of loopback cells/messages that should
be generated on the local loop as part of the loopback test. be generated on the local loop as part of the loopback test.
The NAS SHOULD restrict the “count” to be greater than 0 and The NAS SHOULD restrict the "count" to be greater than 0 and
less than or equal to 32. The DSLAM SHOULD discard the request less than or equal to 32. The DSLAM SHOULD discard the request
for a loopback test, if the received test parameters contain an for a loopback test, if the received test parameters contain an
out of range value for the “count” field. The DSLAM MAY out of range value for the "count" field. The DSLAM MAY
optionally send a failure response to the NAS with the code optionally send a failure response to the NAS with the code
“invalid test parameter”. "invalid test parameter".
o Timeout (1 byte) : Upper bound on the time in seconds that the o Timeout (1 byte) : Upper bound on the time in seconds that the
NAS would wait for a response from the DSLAM. If the total time NAS would wait for a response from the DSLAM. If the total time
taken by the DSLAM to complete a test with requested taken by the DSLAM to complete a test with requested
parameters, exceeds the specified “timeout” value, it can parameters, exceeds the specified "timeout" value, it can
choose to omit the generation of a response to the NAS. DSLAM choose to omit the generation of a response to the NAS. DSLAM
SHOULD use a locally determined value for the “timeout”, if the SHOULD use a locally determined value for the "timeout", if the
received value of the “timeout” parameter is 0. received value of the "timeout" parameter is 0.
o Type (Opaque-Data = 0x08) : This is an optional TLV. If present in o Type (Opaque-Data = 0x08) : This is an optional TLV. If present in
the request message, the DSLAM SHOULD reflect it back in the the request message, the DSLAM SHOULD reflect it back in the
response unmodified. response unmodified.
Length : 8 bytes Length : 8 bytes
Value : Two 32 bit integers inserted by the NAS (not to be Value : Two 32 bit integers inserted by the NAS (not to be
interpreted by the DSLAM, but just reflected back in the interpreted by the DSLAM, but just reflected back in the
response). response).
The access node generates a success or failure response when it deems The access node generates a success or failure response when it deems
the loopback test to be complete. “Port Management” message (type 32) the loopback test to be complete. "Port Management" message (type 32)
is used. The result field SHOULD be set to success or failure. The is used. The result field SHOULD be set to success or failure. The
function type SHOULD be set to 0x09. The transaction ID SHOULD be function type SHOULD be set to 0x09. The transaction ID SHOULD be
copied from the sequence number contained in the corresponding copied from the sequence number contained in the corresponding
request. The other parameters not explicitly defined here SHOULD be request. The other parameters not explicitly defined here SHOULD be
set as specified in the request message above. The code field SHOULD set as specified in the request message above. The code field SHOULD
be set to a value in the range 0x500 to 0x5ff (to be reserved with be set to a value in the range 0x500 to 0x5ff (to be reserved with
IANA) to indicate the status of the executed test. The valid values IANA) to indicate the status of the executed test. The valid values
defined are (can be extended in future): defined are (can be extended in future):
0x500 : Specified access line does not exist. 0x500 : Specified access line does not exist.
skipping to change at page 39, line 23 skipping to change at page 39, line 23
identifier (more generally referred to as "Access Loop Circuit-ID") identifier (more generally referred to as "Access Loop Circuit-ID")
corresponding to a subscriber. The "Access loop circuit-ID" has no corresponding to a subscriber. The "Access loop circuit-ID" has no
local significance on the NAS. The ANCP messages for topology local significance on the NAS. The ANCP messages for topology
discovery and line configuration carry opaque "Access loop Circuit- discovery and line configuration carry opaque "Access loop Circuit-
ID" which has only local significance on the DSLAMs. ID" which has only local significance on the DSLAMs.
The access loop circuit identifier can be carried as an ASCII string The access loop circuit identifier can be carried as an ASCII string
in the ANCP messages. This allows ANCP to be decoupled from the in the ANCP messages. This allows ANCP to be decoupled from the
specifics of the underlying access technology being controlled. On specifics of the underlying access technology being controlled. On
the other hand, this requires a NAS mechanism by which such the other hand, this requires a NAS mechanism by which such
identifier can be correlated to the context of an “aggregation identifier can be correlated to the context of an "aggregation
network” facing IP interface (corresponding to the subscriber) on the network" facing IP interface (corresponding to the subscriber) on the
NAS. This would typically require local configuration of such IP NAS. This would typically require local configuration of such IP
interfaces, or of the underlying ATM interfaces. interfaces, or of the underlying ATM interfaces.
5.6 Ethernet-specific considerations 5.6 Ethernet-specific considerations
One possible way of approaching the use of Ethernet technology in the One possible way of approaching the use of Ethernet technology in the
access aggregation network is to recreate the equivalent of Virtual access aggregation network is to recreate the equivalent of Virtual
Paths (VPs) and Virtual Circuits (VCs) by using stacked Virtual LAN Paths (VPs) and Virtual Circuits (VCs) by using stacked Virtual LAN
tags. As an example, one could use an “outer” VLAN to create a form of tags. As an example, one could use an "outer" VLAN to create a form of
“virtual path” between a given DSLAM and a given NAS. And then use "virtual path" between a given DSLAM and a given NAS. And then use
“inner” VLAN tags to create a form of “virtual circuit” on a per DSL "inner" VLAN tags to create a form of "virtual circuit" on a per DSL
line basis. In this case, VLAN tags conveyed in topology discovery and line basis. In this case, VLAN tags conveyed in topology discovery and
line configuration messages will allow to uniquely identify the DSL line line configuration messages will allow to uniquely identify the DSL line
in a straightforward manner, assuming the VLAN tags are not translated in a straightforward manner, assuming the VLAN tags are not translated
in some way by the aggregation network, and are unique across physical in some way by the aggregation network, and are unique across physical
ports. ports.
However, some carriers do not wish to use this “connection oriented” However, some carriers do not wish to use this "connection oriented"
approach. Therefore, an alternative model is to bridge sessions from approach. Therefore, an alternative model is to bridge sessions from
multiple subscribers behind a DSLAM to a single VLAN in the aggregation multiple subscribers behind a DSLAM to a single VLAN in the aggregation
network. This is the N:1 model. In this model, or in the case where user network. This is the N:1 model. In this model, or in the case where user
traffic is sent untagged, the access node needs to insert the exact traffic is sent untagged, the access node needs to insert the exact
identity of the DSL line in the topology discovery and line identity of the DSL line in the topology discovery and line
configuration messages, and then have a mechanism by which this can be configuration messages, and then have a mechanism by which this can be
correlated to the context of an “aggregation network” facing IP correlated to the context of an "aggregation network" facing IP
interface (for the subscriber) on the NAS. This can either be based on interface (for the subscriber) on the NAS. This can either be based on
local configuration on the NAS, or on the fact that such DSLAM (access local configuration on the NAS, or on the fact that such DSLAM (access
node) typically inserts the “Access Loop Circuit ID” in subscriber node) typically inserts the "Access Loop Circuit ID" in subscriber
signaling messages relayed to the NAS (i.e. DHCP or PPPoE discovery signaling messages relayed to the NAS (i.e. DHCP or PPPoE discovery
messages). messages).
Section 5.4.1 defines “Access Loop Circuit ID”. Section 5.4.1 defines "Access Loop Circuit ID".
6 IANA Considerations 6 IANA Considerations
New Tech-Type, capability types, sub-TLV types related to topology New Tech-Type, capability types, sub-TLV types related to topology
discovery and line configuration will need to be reserved. discovery and line configuration will need to be reserved.
7 Security Considerations 7 Security Considerations
The NAS and DSLAMs are implicitly in a trusted domain, so security The NAS and DSLAMs are implicitly in a trusted domain, so security
for ANCP is not a strong requirement. However, if needed security can for ANCP is not a strong requirement. However, if needed security can
be provided using IP security as indicated in [RFC3293]. be provided using IP security as indicated in [RFC3293].
8 References 8 References
[1] DSLForum TR-059, DSL Evolution - Architecture Requirements for 8.1 Normative References
the Support of QoS-Enabled IP Services, Tom Anschutz (BellSouth
Telecommunications), 09/2003.
[2] DSLForum TR-058, Multi-Service Architecture & Framework [RFC3292] Doria, A. et al, "General Switch Management Protocol- V3"
Requirements, Mark Elias (SBC) and Sven Ooghe (Alcatel), (GSMP v3), RFC 3292, June 2002.
09/2003.
[3] DSLForum TR-092, Broadband Remote access server requirements [RFC3293] Worster, T., Doria, A. and J. Buerkle, "General Switch
document. Management Protocol (GSMP) Packet Encapsulations for Asynchronous
Transfer Mode (ATM), Ethernet and Transmission Control Protocol
(TCP)", RFC 3293, June 2002.
[4] Doria, A. et al, "General Switch Management Protocol- V3" (GSMP [RFC3046] "DHCP Relay Agent Information Option", RFC 3046, January
v3), RFC 3292, June 2002. 2001.
[5] Worster, T., Doria, A. and J. Buerkle, "General Switch 8.2 Informative References
Management Protocol (GSMP) Packet Encapsulations for
Asynchronous Transfer Mode (ATM), Ethernet and Transmission
Control Protocol (TCP)", RFC 3293, June 2002.
[6] “DHCP Relay Agent Information Option”, RFC 3046, January 2001. [TR-059] DSL Forum TR-059, DSL Evolution - Architecture Requirements
for the Support of QoS-Enabled IP Services, Tom Anschutz (BellSouth
Telecommunications), 09/2003.
[7] Architecture & Transport: Migration to Ethernet Based DSL [TR-058] DSL Forum TR-058, Multi-Service Architecture & Framework
Aggregation, DSL Forum WT-101, Cohen et al. Requirements, Mark Elias (SBC) and Sven Ooghe (Alcatel), 09/2003.
[8] Framework for Access Node Control Mechanism in Broadband [TR-092] DSL Forum TR-092, Broadband Remote access server
Networks, draft-ietf-ancp-framework-00.txt. requirements document.
[9] ITU-T recommendation G.998.1, ATM-based multi-pair bonding, [TR-101] Architecture & Transport: "Migration to Ethernet Based DSL
Aggregation", DSL Forum TR-101, Cohen et al.
[ANCP-FRAMEWORK] Framework for Access Node Control Mechanism in
Broadband Networks, draft-ietf-ancp-framework-00.txt.
[G.998.1] ITU-T recommendation G.998.1, ATM-based multi-pair bonding,
2005. 2005.
[10] ITU-T recommendation G.998.2, Ethernet-based multi-pair [G.998.2] ITU-T recommendation G.998.2, Ethernet-based multi-pair
bonding, 2005. 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
skipping to change at page 42, line 40 skipping to change at page 42, line 40
Email: thomas.haag@t-systems.com Email: thomas.haag@t-systems.com
Norber Voigt Norber Voigt
Siemens Siemens
Email: norbert.voigt@siemens.com Email: norbert.voigt@siemens.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. This document and the information contained retain all their rights. This document and the information contained
herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE
ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE
INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
 End of changes. 108 change blocks. 
279 lines changed or deleted 255 lines changed or added

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