draft-ietf-ancp-protocol-03.txt   draft-ietf-ancp-protocol-04.txt 
Working Group Name Sanjay Wadhwa Network Working Group S. Wadhwa
Internet Draft Juniper Networks Internet-Draft J. Moisand
Intended status: Standards Track Intended status: Standards Track S. Subramanian
Expires: Jan 14, 2009 Jerome Moisand Expires: May 7, 2009 Juniper Networks
Juniper Networks T. Haag
T-systems
Swami Subramanian N. Voigt
Juniper Networks
Thomas Haag
T-Systems
Norbert Voigt
Siemens Siemens
R. Maglione
July 14, 2008 Telecom Italia
November 3, 2008
Protocol for Access Node Control Mechanism in Broadband Networks Protocol for Access Node Control Mechanism in Broadband Networks
draft-ietf-ancp-protocol-04
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. Drafts.
Internet-Drafts are draft documents valid for a maximum of Internet-Drafts are draft documents valid for a maximum of six months
six months and may be updated, replaced, or obsoleted by other and may be updated, replaced, or obsoleted by other documents at any
documents at any time. It is inappropriate to use Internet-Drafts as time. It is inappropriate to use Internet-Drafts as reference
reference material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html.
This Internet-Draft will expire on Jan 14, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008). This Internet-Draft will expire on May 7, 2009.
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.
These proposed extensions are required to realize a protocol for NAS). These proposed extensions are required to realize a protocol
"Access Node Control" mechanism as described in [ANCP-FRAMEWORK]. The for "Access Node Control" mechanism as described in [ANCP-FRAMEWORK].
resulting protocol with the proposed extensions to GSMPv3 [RFC3292]
is referred to as "Access Node Control Protocol" (ANCP). This The resulting protocol with the proposed extensions to GSMPv3
document currently focuses on specific use cases of access node [RFC3292] is referred to as "Access Node Control Protocol" (ANCP).
This document currently focuses on specific use cases of access node
control mechanism for topology discovery, line configuration, and OAM control mechanism for topology discovery, line configuration, and OAM
as described in ANCP framework document [ANCP-FRAMEWORK]. It is as described in ANCP framework document [ANCP-FRAMEWORK]. It is
intended to be augmented by additional protocol specification for intended to be augmented by additional protocol specification for
future use cases considered in scope by the ANCP charter. future use cases considered in scope by the ANCP charter.
ANCP framework document [ANCP-FRAMEWORK] describes the ANCP use-cases ANCP framework document [ANCP-FRAMEWORK] describes the ANCP use-cases
in detail. Illustrative text for the use-cases is included here to in detail. Illustrative text for the use-cases is included here to
help the protocol implementer understand the greater context of ANCP help the protocol implementer understand the greater context of ANCP
protocol 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
3. Broadband Access Aggregation . . . . . . . . . . . . . . . . . 5
2.1 Terminology..............................................5 3.1. ATM-based broadband aggregation . . . . . . . . . . . . . 5
3 Broadband Access Aggregation 6 3.2. Ethernet-based broadband aggregation . . . . . . . . . . . 7
4. Access Node Control Protocol . . . . . . . . . . . . . . . . . 7
3.1 ATM-based broadband aggregation..........................6 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Ethernet-based broadband aggregation.....................7 4.2. ANCP based Access Topology Discovery . . . . . . . . . . . 8
4 Access Node Control Protocol 8 4.2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 9
4.1 Overview.................................................8 4.3. ANCP based Line Configuration . . . . . . . . . . . . . . 10
4.2 ANCP based Access Topology Discovery.....................9 4.3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1 Goals..............................................9 4.3.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 11
4.2.2 Message Flow.......................................9 4.4. ANCP based Transactional Multicast . . . . . . . . . . . . 13
4.3 ANCP based Line Configuration...........................10 4.4.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3.1 Goals.............................................10 4.4.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 14
4.3.2 Message Flow......................................11 4.5. ANCP based OAM . . . . . . . . . . . . . . . . . . . . . . 14
4.4 ANCP based Transactional Multicast......................13 4.5.1. Message Flow . . . . . . . . . . . . . . . . . . . . . 15
4.5 ANCP based OAM..........................................14 5. Access Node Control Protocol (ANCP) . . . . . . . . . . . . . 15
4.5.1 Message Flow......................................14 5.1. ANCP/TCP connection establishment . . . . . . . . . . . . 19
5 Access Node Control Protocol (ANCP) 15 5.2. ANCP Connection keep-alive . . . . . . . . . . . . . . . . 21
5.3. Capability negotiation . . . . . . . . . . . . . . . . . . 21
5.1 ANCP/TCP connection establishment.......................17 5.4. GSMP Message Extensions for Access Node Control . . . . . 24
5.2 ANCP Connection keep-alive..............................17 5.4.1. General Extensions . . . . . . . . . . . . . . . . . . 24
5.3 Capability negotiation..................................18 5.4.2. Topology Discovery Extensions . . . . . . . . . . . . 25
5.4 GSMP Message Extensions for Access Node Control.........21 5.4.3. Line Configuration Extensions . . . . . . . . . . . . 35
5.4.1 General Extensions................................21 5.4.4. OAM Extensions . . . . . . . . . . . . . . . . . . . . 38
5.4.2 Topology Discovery Extensions.....................23 5.4.5. Multicast Extensions . . . . . . . . . . . . . . . . . 41
5.4.3 Line Configuration Extensions.....................33 5.4.5.1. General well known TLVs . . . . . . . . . . . . . 42
5.4.4 OAM Extensions....................................36 5.4.5.1.1. Target TLV . . . . . . . . . . . . . . . . . . 42
5.5 ATM-specific considerations.............................39 5.4.5.1.2. Command TLV . . . . . . . . . . . . . . . . . 43
5.6 Ethernet-specific considerations........................39 5.4.5.1.3. Status-Info TLV . . . . . . . . . . . . . . . 44
6 IANA Considerations 40 5.4.5.2. Multicast Replication Control Message . . . . . . 45
5.4.5.3. Multicast Status Message . . . . . . . . . . . . . 52
7 Security Considerations 40 5.5. ATM-specific considerations . . . . . . . . . . . . . . . 53
5.6. Ethernet-specific considerations . . . . . . . . . . . . . 54
8 References 40 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
7. Security Considerations . . . . . . . . . . . . . . . . . . . 55
Author's Addresses 42 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 55
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Full Copyright Statement 42 9.1. Normative References . . . . . . . . . . . . . . . . . . . 55
9.2. Informative References . . . . . . . . . . . . . . . . . . 55
Copyright (C) The IETF Trust (2007) 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
Intellectual Property and Copyright Statements . . . . . . . . . . 59
Intellectual Property 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",
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
this document are to be interpreted as described in RFC 2119. document are to be interpreted as described in [RFC2119].
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 [TR-059, TR- Next Generation Networks. Several specifications like [TR-059],
058, TR-092] describe possible architectures for these access [TR-058], [TR-092] describe possible architectures for these access
networks. In the scope of these specifications are the delivery of networks. In the scope of these specifications are the delivery of
voice, video and data 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
skipping to change at page 4, line 39 skipping to change at page 4, line 40
result of these extensions and mechanisms is referred to as "Access result of these extensions and mechanisms is referred to as "Access
Node 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 [RFC3293]. GSMPv3 encapsulation for GSMPv3 is defined in [RFC3293]. GSMPv3
encapsulation directly over Ethernet and ATM as defined in [RFC3293] encapsulation directly over Ethernet and ATM as defined in [RFC3293]
is not considered 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 Section 5. GSMPv3 procedures with suitable extensions, as used by
described in sections 5.1, 5.2 and 5.3. GSMPv3 general extensions and ANCP, are described in sections Section 5.1, Section 5.2 and
GSMPv3 message specific extensions required by ANCP are described in Section 5.3. GSMPv3 general extensions and GSMPv3 message specific
sub-sections of 5.4. In addition to specifying extensions and extensions required by ANCP are described in sub-sections of
modifications to relevant GSMP messages applicable to ANCP, this Section 5.4. In addition to specifying extensions and modifications
draft also defines the usage of these messages by ANCP. Not all the to relevant GSMP messages applicable to ANCP, this draft also defines
fields in relevant GSMP messages are used by ANCP. This draft the usage of these messages by ANCP. Not all the fields in relevant
indicates the value that ANCP should set for the fields in these GSMP GSMP messages are used by ANCP. This draft indicates the value that
messages. However, to understand the basic semantics of various ANCP should set for the fields in these GSMP messages.
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
is a Digital Subscriber Line (DSL), the Access Node provides DSL loop is a Digital Subscriber Line (DSL), the Access Node provides
signal termination, and is referred to as DSL Access Multiplexer DSL signal termination, and is referred to as DSL Access
(DSLAM). Multiplexer (DSLAM).
o Network Access Server (NAS): Network element which aggregates o Network Access Server (NAS): Network element which aggregates
subscriber traffic from a number of Access Nodes. The NAS is an subscriber traffic from a number of Access Nodes. The NAS is an
injection point for policy management and IP QoS in the access injection point for policy management and IP QoS in the access
network. IT is also referred to as Broadband Network Gateway (BNG) network. IT is also referred to as Broadband Network Gateway
or Broadband Remote Access Server (BRAS). (BNG) or Broadband Remote Access Server (BRAS).
o Home Gateway (HGW): Network element that connects subscriber o Home Gateway (HGW): Network element that connects subscriber
devices to the Access Node and the access network. In case of DSL, devices to the Access Node and the access network. In case of
the Home Gateway is a DSL network termination that could either DSL, the Home Gateway is a DSL network termination that could
operate as a layer 2 bridge or as a layer 3 router. In the latter either operate as a layer 2 bridge or as a layer 3 router. In the
case, such a device is also referred to as a Routing Gateway (RG). latter case, such a device is also referred to as a Routing
Gateway (RG).
o Net Data Rate: portion of the total data rate of the DSL line that o Net Data Rate: portion of the total data rate of the DSL line that
can be used to transmit actual user information (e.g. ATM cells of can be used to transmit actual user information (e.g. ATM cells
Ethernet frames). It excludes overhead that pertains to the of 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,
and customer premises network. Fig1. shows ATM broadband access and customer premises network. Figure 1 shows ATM broadband access
network components. network components.
The Regional/Access Network consists of the Regional Network, Network The Regional/Access Network consists of the Regional Network, Network
Access Server, and the Access Network as show in Fig 1. Its primary Access Server, and the Access Network as show in Figure 1. Its
function is to provide end-to-end transport between the customer primary function is to provide end-to-end transport between the
premises and the NSP or ASP. The Access Node terminates the DSL customer premises and the NSP or ASP. The Access Node terminates the
signal. It could consist of DSLAM in the central office, or remote DSL signal. It could consist of DSLAM in the central office, or
DSLAM, or a Remote Access Multiplexer (RAM). Access node is the first remote DSLAM, or a Remote Access Multiplexer (RAM). Access node is
point in the network where traffic on multiple DSL lines will be the first point in the network where traffic on multiple DSL lines
aggregated onto a single network. will be aggregated onto a single network. The NAS performs multiple
functions in the network.
The NAS performs multiple functions in the network. The NAS is the The NAS is the aggregation point for the subscriber traffic. It
aggregation point for the subscriber traffic. It provides aggregation provides aggregation capabilities (e.g. IP, PPP, ATM) between the
capabilities (e.g. IP, PPP, ATM) between the Regional/Access Network Regional/Access Network and the NSP or ASP. These include
and the NSP or ASP. These include traditional ATM-based offerings and traditional ATM-based offerings and newer, more native IP-based
newer, more native IP-based services. This includes support for services. This includes support for Point-to-Point Protocol over ATM
Point-to-Point Protocol over ATM (PPPoA) and PPP over Ethernet (PPPoA) and PPP over Ethernet (PPPoE), as well as direct IP services
(PPPoE), as well as direct IP services encapsulated over an 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 [TR- on hierarchical scheduling is used. This mechanism defined in
059], preserves IP QoS over the ATM network between the NAS and the [TR-059], preserves IP QoS over the ATM network between the NAS and
RGs by carefully controlling downstream traffic in the NAS, so that the RGs by carefully controlling downstream traffic in the NAS, so
significant queuing and congestion does not occur further down the that significant queuing and congestion does not occur further down
ATM network. This is achieved by using a diffserv-aware hierarchical the ATM network. This is achieved by using a diffserv-aware
scheduler in the NAS that will account for downstream trunk hierarchical scheduler in the NAS that will account for downstream
bandwidths and DSL synch rates. trunk bandwidths and DSL synch rates.
[ANCP-FRAMEWORK] provides detailed definition and functions of each [ANCP-FRAMEWORK] provides detailed definition and functions of each
network 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|| NSP| | +-|NAS|-| |ATM |-|Access| | ||DSL |-|HGW|-|Subscriber||
NSP---+Regional | | +-----+ | +-----+ | Node | | ||Modem| +---+ |Devices || ---+ Regional| | +---+ | +-----+ | Node | | ||Modem| +---+ |Devices ||
|Broadband | | +-----+ | +------+ | |+-----+ +----------+| |Broadband| | +---+ | +------+ | |+-----+ +----------+|
|Network |-+-|NAS | +---------------|---+ +---------------------------+ ASP|Network |-+-|NAS| +--------------|---+ +--------------------------+
ASP---+ | | +-----+ | +----------------------------+ ---+ | | +---+ | +--------------------------+
| | | +-----+ | | +-----+ +---+ +----------+| | | | +---+ | |+-----+ +---+ +----------+|
+----------+ +-|NAS | +-----| | DSL |-|HGW|--|Subscriber|| +---------+ +-|NAS| +-----|| DSL |-|HGW|-|Subscriber||
+-----+ | |Modem| +---+ |Devices || +---+ ||Modem| +---+ |Devices ||
| +-----+ +----------+| | +-----+ +----------+|
+----------------------------+ +--------------------------+
HGW : Home Gateway HGW : Home Gateway
NAS : Network Access Server NAS : Network Access Server
Fig.1 ATM Broadband Aggregation Topology Figure 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
The aggregation devices are "provider edge bridges" defined in IEEE network. The aggregation devices are "provider edge bridges" defined
802.ad. in IEEE 802.ad. Stacked VLAN tags provide one possible way to create
Stacked VLAN tags provide one possible way to create equivalent of equivalent of "virtual paths" and "virtual circuits" in the
"virtual paths" and "virtual circuits" in the aggregation network. The aggregation network. The "outer" vlan could be used to create a form
"outer" vlan could be used to create a form of "virtual path" between a of "virtual path" between a given DSLAM and a given NAS. And "inner"
given DSLAM and a given NAS. And "inner" VLAN tags to create a form of VLAN tags to create a form of "virtual circuit" on a per DSL line
"virtual circuit" on a per DSL line basis. This is 1:1 VLAN allocation basis. This is 1:1 VLAN allocation model. An alternative model is
model. An alternative model is to bridge sessions from multiple to bridge sessions from multiple subscribers behind a DSLAM into a
subscribers behind a DSLAM into a single VLAN in the aggregation single VLAN in the aggregation network. This is N:1 VLAN allocation
network. This is N:1 VLAN allocation model. Architectural and model. Architectural and topological models of an Ethernet
topological models of an Ethernet aggregation network in context of DSL aggregation network in context of DSL aggregation are defined in
aggregation are defined in [TR101]. [TR-101]
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 [RFC3292] 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 o 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 o Pushing to the access-nodes, subscriber and service data retrieved
retrieved by the NAS from an OSS system (e.g. radius server), to by the NAS from an OSS system (e.g. radius server), to simplify
simplify OSS infrastructure for service management. OSS infrastructure for service management.
. Optimized, "NAS controlled and managed" multicast replication by o Optimized, "NAS controlled and managed" multicast replication by
access-nodes at L2 layer. access-nodes at L2 layer.
. NAS controlled, on-demand access-line test capability o NAS controlled, on-demand access-line test capability (rudimentary
(rudimentary end-to-end OAM). end-to-end OAM).
In addition to DSL, alternate broadband access technologies (e.g. In addition to DSL, alternate broadband access technologies (e.g.
Metro-Ethernet, Passive Optical Networking, WiMax) will have similar Metro-Ethernet, Passive Optical Networking, WiMax) will have similar
challenges to address, and could benefit from the same approach of a challenges to address, and could benefit from the same approach of a
control plane between a NAS and an Access Node (e.g. OLT), providing control plane between a NAS and an Access Node (e.g. OLT), providing
a unified control and management architecture for multiple access a unified control and management architecture for multiple access
technologies, hence facilitating migration from one to the other technologies, hence facilitating migration from one to the other
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
[TR-059] 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.
Following section describes ANCP messages that allow the Access Node Following section describes ANCP messages that allow the Access Node
(e.g. DSLAM) to communicate to the NAS, access network topology (e.g. DSLAM) to communicate to the NAS, access network topology
information and any corresponding updates. information and any corresponding updates.
Some of the parameters that can be communicated from the DSLAM to the Some of the parameters that can be communicated from the DSLAM to the
NAS include DSL line state, actual upstream and downstream net data NAS include DSL line state, actual upstream and downstream net data
rates of a synchronized DSL link, maximum attainable upstream and rates of a synchronized DSL link, maximum attainable upstream and
downstream net data rates, interleaving delay etc. Topology discovery downstream net data rates, interleaving delay etc. Topology
is specifically important in case the net data rate of the DSL line discovery is specifically important in case the net data rate of the
changes over time. The DSL net data rate may be different every time DSL line changes over time. The DSL net data rate may be different
the DSL modem is turned on. Additionally, during the time the DSL every time the DSL modem is turned on. Additionally, during the time
modem is active, data rate changes can occur due to environmental the DSL modem is active, data rate changes can occur due to
conditions (the DSL line can get "out of sync" and can retrain to a environmental conditions (the DSL line can get "out of sync" and can
lower value). retrain to a lower value).
4.2.2 Message Flow 4.2.2. Message Flow
When a DSL line initially comes up or resynchronizes to a different When a DSL line initially comes up or resynchronizes to a different
rate, the DSLAM generates and transmits a GSMP PORT UP EVENT message to rate, the DSLAM generates and transmits a GSMP PORT UP EVENT message
the NAS. The extension field in the message carries the TLVs containing to the NAS. The extension field in the message carries the TLVs
DSL line specific parameters. On a loss of signal on the DSL line, a containing DSL line specific parameters. On a loss of signal on the
GSMP PORT DOWN message is generated by the DSLAM to the NAS. In order to DSL line, a GSMP PORT DOWN message is generated by the DSLAM to the
provide expected service level, NAS needs to learn the initial NAS. In order to provide expected service level, NAS needs to learn
attributes of the DSL line before the subscriber can log in and access the initial attributes of the DSL line before the subscriber can log
the provisioned services for the subscriber. in and access the provisioned services for the subscriber. Figure 2
summarizes the interaction.
<----- Port UP(EVENT Message) <----- DSL <----- Port UP(EVENT Message) <----- DSL
(default line parameters) Signal (default line parameters) Signal
1. NAS ----------------------- Access ----------- Home ----- Subscriber 1. NAS ------------------ Access ----------- Home ----- Subscriber
Node Gateway Node Gateway
<----- Port UP (EVENT Message) <----- DSL <----- Port UP (EVENT Message) <----- DSL
(updated line parameters) Resynch (updated line parameters) Resynch
2. NAS ----------------------- Access ----------- Home ------ Subscriber 2. NAS ------------------ Access ----------- Home ------ Subscriber
Node Gateway Node Gateway
<--- Port DOWN (EVENT Message) <---- DSL <--- Port DOWN (EVENT Message) <---- DSL
Loss of Signal Loss of Signal
3. NAS ---------------------- Access ------------- Home ----- Subscriber 3. NAS ----------------- Access ------------- Home ----- Subscriber
Node Gateway Node Gateway
Fig 2. Message flow (ANCP mapping) for topology discovery Figure 2: Message flow (ANCP mapping) for topology discovery
The Event message with PORT UP message type (80) is used for The Event message with PORT UP message type (80) is used for
conveying DSL line attributes to the NAS. This message with relevant conveying DSL line attributes to the NAS. This message with relevant
extensions is defined in section 5.4.2. extensions is defined in section Section 5.4.2.
4.3 ANCP based Line Configuration 4.3. ANCP based Line Configuration
4.3.1 Goals 4.3.1. Goals
Following dynamic discovery of access topology (identification of DSL Following dynamic discovery of access topology (identification of DSL
line and its attributes) as assisted by the mechanism described in line and its attributes) as assisted by the mechanism described in
the previous section (topology discovery), the NAS could then query a the previous section (topology discovery), the NAS could then query a
subscriber management OSS system (e.g. RADIUS server) to retrieve subscriber management OSS system (e.g. RADIUS server) to retrieve
subscriber authorization data (service profiles, aka user subscriber authorization data (service profiles, aka user
entitlement). Most of such service mechanisms are typically enforced entitlement). Most of such service mechanisms are typically enforced
by the NAS itself, but there are a few cases where it might be useful by the NAS itself, but there are a few cases where it might be useful
to push such service parameter to the DSLAM for local enforcement of to push such service parameter to the DSLAM for local enforcement of
a mechanism (e.g. DSL-related) on the corresponding subscriber line. a mechanism (e.g. DSL-related) on the corresponding subscriber line.
skipping to change at page 11, line 28 skipping to change at page 11, line 20
management, allowing fully centralized subscriber-related service management, allowing fully centralized subscriber-related service
data (e.g. RADIUS server back-end) and avoiding complex cross- data (e.g. RADIUS server back-end) and avoiding complex cross-
organization B2B interactions. organization B2B interactions.
The best way to change line parameters would be by using profiles. The best way to change line parameters would be by using profiles.
These profiles (DSL profiles for different services) are pre- These profiles (DSL profiles for different services) are pre-
configured on the DSLAMs. The NAS can then indicate a reference to configured on the DSLAMs. The NAS can then indicate a reference to
the right DSL profile via ANCP. Alternatively, discrete DSL the right DSL profile via ANCP. Alternatively, discrete DSL
parameters can also be conveyed by the NAS in ANCP. parameters can also be conveyed by the NAS in ANCP.
4.3.2 Message Flow 4.3.2. Message Flow
Triggered by topology information reporting a new DSL line or triggered Triggered by topology information reporting a new DSL line or
by a subsequent user session establishment (PPP or DHCP), the NAS may triggered by a subsequent user session establishment (PPP or DHCP),
send line configuration information (e.g. reference to a DSL profile) to the NAS may send line configuration information (e.g. reference to a
the DSLAM using GSMP Port Management messages. The NAS may get such line DSL profile) to the DSLAM using GSMP Port Management messages. The
configuration data from a policy server (e.g. RADIUS). Figure 3 NAS may get such line configuration data from a policy server (e.g.
summarizes the interaction. RADIUS). Figure 3 summarizes the interaction.
1.DSL Signal 1.DSL Signal
<----------- <-----------
2. Port UP (EVENT Message) 2. Port UP (EVENT Message)
(Access Topology Discovery) (Access Topology Discovery)
<-------------------------- <----------------
3. PPP/DHCP Session 3. PPP/DHCP Session
<----------------------------------------------------- <--------------------------------
4. Authorization 4. Authorization
& Authentication & Authentication
<------------------- <-------------------
Port Management Message Port Management Message
(Line Configuration) (Line Configuration)
5. ----------------> 5. -------->
+-------------+ +-----+ +-------+ +----------+ +-----------+ +----------+ +-----+ +-----+ +-------+ +-----------+
|Radius/AAA |------| NAS |---------| AN |------ | Home |------ |Subscriber | |Radius/AAA|---| NAS |-----| AN |----| Home |----|Subscriber |
|Policy Server| +-----+ +-------+ | Gateway | +-----------+ |Policy | +-----+ +-----+ |Gateway| +-----------+
+-------------+ +----------+ |Server | +-------+
+----------+
Fig 3. Message flow - ANCP mapping for Initial Line Configuration Figure 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
interaction. the interaction.
1. PPP/DHCP Session 1. PPP/DHCP Session
<------------------------------------------ <------------------------------------------
+-------------+ 2. Service On Demand +-----------+ 2. Service On Demand
| |<------------------------------------------------ | |<-----------------------------------------------
| Web portal | | Web portal |
| OSS etc | 3.Change of 4.Port Management | OSS etc | 3.Change of 4.Port Management
| | Authorization Message | | Authorization Message
| Radius AAA | --------> (Updated Line | Radius AAA | --------> (Updated Line
| Policy | Config - New Profile) | Policy | Config - New Profile)
| | -------------. | | ------------->
| | +------+ +-------+ +---------+ +----------+ | | +------+ +-------+ +---------+ +----------+
| |----| NAS |-----| AN |---| Home |--|Subscriber| | |----| NAS |-----| AN |---| Home |--|Subscriber|
| | +------+ +-------+ | Gateway | +----------+ | | +------+ +-------+ | Gateway | +----------+
+-------------+ +---------+ +-----------+ +---------+
Fig 4. Message flow - ANCP mapping for Updated Line Configuration Figure 4: Message flow - ANCP mapping for Updated Line Configuration
The format of relevant extensions to port management message is The format of relevant extensions to port management message is
defined in section 5.4.3. The line configuration models could be defined in section Section 5.4.3. The line configuration models
viewed as a form of delegation of authorization from the NAS to the could be viewed as a form of delegation of authorization from the NAS
DSLAM. to the DSLAM.
4.4 ANCP based Transactional Multicast 4.4. ANCP based Transactional Multicast
4.4.1. Goals
Typical IP multicast in access networks involves the NAS terminating Typical IP multicast in access networks involves the NAS terminating
user requests for receiving multicast channels via IGMP. The NAS user requests for receiving multicast channels via IGMP. The NAS
authorizes the subscriber, and dynamically determines the multicast authorizes the subscriber, and dynamically determines the multicast
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
number of subscribers rather than the number of access-nodes. of 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 a
It is ideal for NAS to send a single copy of the multicast stream to 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 is defined in section
future. Section 5.4.5
4.5 ANCP based OAM 4.4.2. Message Flow
The Multicast Replication Control Message is sent by the NAS to the
AN with a directive to either join or leave one or more multicast
flows. The AN will use a Multicast Status Message when conveying the
outcome of the directive. The message flows in Figure 5 illustrates
the behavior of the AN in case of receiving a Multicast Replication
Control Message.
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<-------------------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | Multicast-Replication-Crl |
| | |(Target,add, Flowi..Flowj) |
| | |<--------------------------|
| Mcast Flow 1 | |
|<==========================+ |
| | | Multicast-Status |
| | |-------------------------->|
| | | |
| | | Multicast-Replication-Crl |
| | |(Target,delete,Flowi.Flowj)|
| | |<--------------------------|
| | | |
| <Stop Replication of X |
| Mcast Flow 1> | Multicast-Status |
| | |-------------------------->|
Figure 5: NAS-Controlled Multicast Replication
4.5. ANCP based OAM
In a mixed Ethernet and ATM access network (including the local In a mixed Ethernet and ATM access network (including the local
loop), it is desirable to provide similar mechanisms for connectivity loop), it is desirable to provide similar mechanisms for connectivity
checks and fault isolation, as those used in an ATM based checks and fault isolation, as those used in an ATM based
architecture. This can be achieved using an ANCP based mechanism architecture. This can be achieved using an ANCP based mechanism
until end-to-end Ethernet OAM mechanisms are more widely implemented until end-to-end Ethernet OAM mechanisms are more widely implemented
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
skipping to change at page 14, line 26 skipping to change at page 15, line 4
architecture. This can be achieved using an ANCP based mechanism architecture. This can be achieved using an ANCP based mechanism
until end-to-end Ethernet OAM mechanisms are more widely implemented until end-to-end Ethernet OAM mechanisms are more widely implemented
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 The format of relevant extensions to port management
message is defined in section Section 5.4.4. Figure 6 summarizes the
interaction.
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) Figure 6: Message Flow: ANCP based OAM
5. Access Node Control Protocol (ANCP)
ANCP uses a subset of GSMPv3 messages described in [RFC3292] to ANCP uses a subset of GSMPv3 messages described in [RFC3292] to
implement currently defined use-cases. GSMPv3 general message format, implement currently defined use-cases. GSMPv3 general message
used by all GSMP messages other than adjacency protocol messages, is format, used by all GSMP messages other than adjacency protocol
defined in section 3.1.1 of GSMPv3 RFC [RFC3292]. ANCP modifies this messages, is defined in section 3.1.1 of GSMPv3 [RFC3292]. ANCP
base GSMPv3 message format. The modified GSMPv3 message format is modifies this base GSMPv3 message format. The modified GSMPv3
defined as follows: message format is 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Message Payload ~ ~ Message Payload ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Modified GSMPv3 message format
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
header has been modified to be 4 bits long, and the Code field to be message header has been modified to be 4 bits long, and the Code
12 bits long. The definition and semantics of all the fields in the field to be 12 bits long.
header are described in section 3.1.1 of GSMPv3 RFC [RFC3292]. An
ANCP implementation SHOULD set "I" and subMessage fields to 1 to Version:
signify no fragmentation.
The version number of the GSMP protocol being used in this
session. ANCP uses version 3.
Sub-Version:
The sub-version number of the GSMP protocol being used in this
session. ANCP uses sub-version 1 of the GSMP protocol.
Result:
The Result field derived from GSMP [RFC3292] has the following
codes:
Ignore:
Res = 0x00 - Ignore this field on receipt and follow the
procedures specified for the received message type.
Nack:
Res = 0x01 - Result code indicating that no response is
expected to the message other than in cases of failure
caused during the processing of the message contents or that
of the contained directive(s).
AckAll:
Res = 0x02 - Result code indicating that a response to the
message is requested in all cases. It is specifically
intended to be used in some cases for Request messages only,
and is not to be used in Event messages.
Success:
Res = 0x03 - Set by receiver to indicate successful
execution of all directives in the corresponding Request
message.
Failure:
Res = 0x4 - Set by receiver in the Response message if one
or more directives in the corresponding Request message
fails.
Message-Type:
The GSMP and ANCP message type.
Code:
This field gives further information concerning the result in a
response message. It is mostly used to pass an error code in a
failure response but can also be used to give further information
in a success response message or an event message. In a request
message, the code field is not used and is set to zero. In an
adjacency protocol message, the Code field is used to determine
the function of the message.
Partition ID:
This field is a 8 bit number which signifies a partition on the
AN. [ TBD How AN and NAS agree on the partition numbers. Possible
options:
1 - The partition ID could be configured on the AN and learnt by
NAS in the adjacency message;
2 - The partition ID could be statically configured on the NAS as
part of configuring the neighbor information.]
Transaction ID:
24-bit field set by the sender of a Request message to associate a
Response message with the original Request message. The receiver
of a Request message reflects the transaction ID from the Request
message in the corresponding Response message. For event
messages, the transaction identifier SHOULD be set to zero. The
Transaction Identifier is not used, and the field is not present,
in the adjacency protocol. The specific use of transaction ID as
applicable to multicast use case is defined in Section 5.4.5
I flag:
An ANCP implementation SHOULD set "I" and subMessage fields to 1
to signify no fragmentation.
Length:
Length of the GSMP message including its header fields and defined
GSMP message body.
Additional General Message Information:
o Any field in a GSMP message that is unused or defined as
"reserved" MUST be set to zero by the sender and ignored by the
receiver;
o Flags that are undefined will be designated as: x: reserved.
Following are the relevant GSMPv3 messages defined in [RFC3292], that Following are the relevant GSMPv3 messages defined in [RFC3292], that
are 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 * Port UP Message
o Port DOWN message * 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
ANCP OAM use-case. and 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
NAS and an AN. between a NAS and an AN.
The basic format and semantics of various fields in these GSMPv3
messages identified above are described in GSMPv3 RFC [RFC3292].
However, the usage of these messages by ANCP, along with relevant
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
by ANCP multicast use-case will be described in future versions of
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
are defined in section 5.3. defined in section Section 5.3
o TCP connection establishment procedure in ANCP deviates o TCP connection establishment procedure in ANCP deviates slightly
slightly from the connection establishment in GSMPv3 as from the connection establishment in GSMPv3 as specified in
specified in [RFC3293]. This is described in section 5.1. [RFC3293]. This is described in section 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
carry information relevant to each ANCP use-case. The format of information relevant to each ANCP use-case. The format of the
the "extension block" is defined in section 5.4.1.1. "extension block" is defined in section Section 5.4.1.1.
5.1 ANCP/TCP connection establishment o
ANCP will use TCP for exchanging protocol messages. [RFC3293] defines 5.1. ANCP/TCP connection establishment
the GSMP message encapsulation for TCP. The TCP session is
initiated from the DSLAM (access node) to the NAS (controller). This ANCP will use TCP for exchanging protocol messages [RFC3293]. defines
is necessary to avoid static provisioning on the NAS for all the the GSMP message encapsulation for TCP. The TCP session is initiated
DSLAMs that are being served by the NAS. It is easier to configure a from the DSLAM (access node) to the NAS (controller). This is
given DSLAM with the single IP address of the NAS that serves the necessary to avoid static provisioning on the NAS for all the DSLAMs
DSLAM. This is a deviation from [RFC3293] which indicates that the that are being served by the NAS. It is easier to configure a given
DSLAM with the single IP address of the NAS that serves the DSLAM.
This is a deviation from [RFC3293] which indicates that the
controller 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 When GSMP messages are sent over a TCP connection a four-byte TLV
is used for TCP connection. Adjacency protocol messages, which are header field is prepended to the GSMP message to provide delineation
used to synchronize the NAS and access-nodes and maintain handshakes, of GSMP messages within the TCP stream.
are sent after the TCP connection is established. ANCP messages other
than adjacency protocol messages may be sent only after the adjacency 0 1 2 3
protocol has achieved synchronization. 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 (0x88-0C) | Length |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ GSMP Message ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: GSMPv3 with TCP/IP Encapsulation message format
Type
This 2-byte field indicates the type code of the following
message. The type code for GSMP messages is 0x88-0C (i.e., the
same as GSMP's Ethertype).
Length
This 2-byte unsigned integer indicates the total length of the
GSMP message only. It does not include the 4-byte TLV header.
NAS listens for incoming connections from the access nodes. Port
6068 is used for TCP connection. Adjacency protocol messages, which
are used to synchronize the NAS and access-nodes and maintain
handshakes, are sent after the TCP connection is established. ANCP
messages other than adjacency protocol messages may be sent only
after the adjacency 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
ANCP messages. ANCP messages.
5.2 ANCP Connection keep-alive In case of an Ethernet access/aggregation network, a typical practice
is to send the Access Node Control Protocol messages over a dedicated
Ethernet Virtual LAN (VLAN) using a separate VLAN identifier (VLAN
ID).
5.2. ANCP Connection keep-alive
GSMPv3 defines an adjacency protocol. The adjacency protocol is used GSMPv3 defines an adjacency protocol. The adjacency protocol is used
to synchronize states across the link, to negotiate which version of to synchronize states across the link, to negotiate which version of
the GSMP protocol to use, to discover the identity of the entity at the GSMP protocol to use, to discover the identity of the entity at
the other end of a link, and to detect when it changes. GSMP is a the other end of a link, and to detect when it changes. GSMP is a
hard state protocol. It is therefore important to detect loss of hard state protocol. It is therefore important to detect loss of
contact between switch and controller, and to detect any change of contact between switch and controller, and to detect any change of
identity of switch or controller. No protocol messages other than identity of switch or controller. No protocol messages other than
those of the adjacency protocol may be sent across the link until the those of the adjacency protocol may be sent across the link until the
adjacency protocol has achieved synchronization. There are no changes adjacency protocol has achieved synchronization. There are no
to the base GSMP adjacency protocol for implementing ANCP. changes 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
configurable and is an implementation choice. It is recommended that be configurable and is an implementation choice. It is recommended
both ends specify the same timer value. However, it is not necessary that both ends specify the same timer value. However, it is not
for the timer values to match. necessary for the timer values to match.
The GSMP adjacency message defined in [RFC3292] is extended for ANCP The GSMP adjacency message defined in [RFC3292] is extended for ANCP
and is shown in section 5.3 immediately following this section. The and is shown in section 5.3 immediately following this section. The
8-bit "version" field in the adjacency protocol messages is modified 8-bit "version" field in the adjacency protocol messages is modified
to 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 [RFC3292]. The "Sender Port", and "Receiver Port" should defined in [RFC3292]. The "Sender Port", and "Receiver Port" should
be set to 0 by both ends. The pType field should be set to 0. The be set to 0 by both ends. The pType field should be set to 0. The
pFlag 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
connection requests. The DSLAM will try to re-establish the TCP new 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 [RFC3292] 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
of support for a capability that is supported by the receiving absence of support for a capability that is supported by the
device, it will turn off the capability locally and will send an receiving device, it will turn off the capability locally and will
updated adjacency message with the capability turned off to match the send an updated adjacency message with the capability turned off to
received capability set. This process will eventually result in both match the received capability set. This process will eventually
sides agreeing on the minimal set of supported capabilities. The result in both sides agreeing on the minimal set of supported
adjacency will not come up unless the capabilities advertised by the capabilities. The adjacency will not come up unless the capabilities
controller and the controlled device match. advertised by the controller and the controlled device match.
After initial synchronization, if at anytime a capability mismatch is After initial synchronization, if at anytime a capability mismatch is
detected, the adjacency will be brought down (RSTACK will be detected, the adjacency will be brought down (RSTACK will be
generated by the device detecting the mismatch), and synchronization generated by the device detecting the mismatch), and synchronization
will be re-attempted. will be re-attempted.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Sub | Message Type | Timer |M| Code | | Ver | Sub | Message Type | Timer |M| Code |
skipping to change at page 19, line 38 skipping to change at page 22, line 45
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Receiver Instance | | Partition ID | Receiver Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tech Type | # of TLVs | Total Length | | Tech Type | # of TLVs | Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Capability TLVs ~ ~ Capability TLVs ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9
The format of capability TLV is: The format of capability TLV is:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capability Type | Capability Length | | Capability Type | Capability Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ ~ ~ ~
~ Capability Data ~ ~ Capability Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Capability TLV
The Tech Type field type indicates the technology to which the The Tech Type field type indicates the technology to which the
capability extension applies. For access node control in case of DSL capability extension applies. For access node control in case of DSL
networks, new type "DSL" is proposed. The value for this field is networks, new type "DSL" is proposed. The value for this field is
0x05. This is the first available value in the range that is not 0x05. This is the first available value in the range that is not
currently allocated. It will need to be reserved with IANA. currently allocated. It will need to be reserved with IANA.
Capability length is the number of actual bytes contained in the Capability length is the number of actual bytes contained in the
value portion of the TLV. The TLV is padded to a 4-octet alignment. value portion of the TLV. The TLV is padded to a 4-octet alignment.
Therefore, a TLV with no data will contain a zero in the length field Therefore, a TLV with no data will contain a zero in the length field
(if capability data is three octets, the length field will contain a (if capability data is three octets, the length field will contain a
three, but the size of the actual TLV is eight octets). three, but the size of the actual TLV is eight octets). Capability
data field can be empty if the capability is just a boolean. In case
the capability is a boolean, it is inferred from the presence of the
TLV (with no data).
Capability data field can be empty if the capability is just a Capability data provides the flexibility to advertise more than mere
boolean. In case the capability is a boolean, it is inferred from the presence or absence of a capability. Capability types can be
presence of the TLV (with no data). Capability data provides the registered with IANA. Following capabilities are defined for ANCP as
flexibility to advertise more than mere presence or absence of a applied to DSL access:
capability. Capability types can be registered with IANA. Following
capabilities are defined for ANCP as applied to DSL access:
1. Capability Type : Dynamic-Topology-Discovery = 0x01 1. Capability Type : Dynamic-Topology-Discovery = 0x01
Length (in bytes) : 0 Length (in bytes) : 0
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.
i.e. NAS terminates IGMP messages from subscribers, and via l2 control protocol, signals state to the access-nodes (e.g. NAS terminates IGMP messages from subscribers, and via l2 control
protocol, signals state to the access-nodes (e.g. DSLAMs) to
DSLAMs) to enable layer2 replication of multicast streams. In enable layer2 replication of multicast streams. In ATM access
ATM access network this implies that NAS instructs the access- network this implies that NAS instructs the access-node to setup
node to setup a P2MP cross-connect. The details of this will be a P2MP cross-connect. The details of this will be covered in a
covered in a separate ID. 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.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 "Access Node
Control" mechanism are defined in sections 5.4.2 to 5.4.4. However, Control" mechanism are defined in sections Section 5.4.2 to
sub-sections 5.4.1.1 and 5.4.1.2 below define extensions to GSMP that Section 5.4.5. However, sub-sections Section 5.4.1.1 below define
have general applicability. extensions to GSMP that 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
[RFC3292] have been modified to include an extension block that [RFC3292] have been modified to include an extension block that
follows a TLV structure. Individual messages in the following follows a TLV structure. Individual messages in the following
sections describe the usage and format of the extension block. sections describe the usage and format of the extension block.
All Extension TLVs 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 ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
x: Reserved Flags Figure 11: Extension TLV
x: Reserved Flags
These are generally used by specific messages and will be These are generally used by specific messages and will be
defined in those messages. defined in those messages.
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
skipping to change at page 23, line 4 skipping to change at page 25, line 31
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.2 Topology Discovery Extensions 5.4.2. Topology Discovery Extensions
The GSMP Event message with PORT UP message type (80) is used for The GSMP Event message with PORT UP message type (80) is used for
conveying DSL line attributes to the NAS. The message SHOULD be 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 generated when a line first comes UP, or any of the attributes of the
line change e.g. the line re-trains to a different rate or one or more line change e.g. the line re-trains to a different rate or one or
of the configured line attributes are administratively modified. Also, more of the configured line attributes are administratively modified.
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 Also, when the ANCP session first comes up, the DSLAM SHOULD transmit
down (idle or silent), the DSLAM SHOULD transmit an Event message with a PORT UP message to the NAS for each line that is up. When a DSL
PORT DOWN message type (81) to the NAS. It is recommended that the line goes down (idle or silent), the DSLAM SHOULD transmit an Event
DSLAMs use a dampening mechanism per DSL line to control the rate of message with PORT DOWN message type (81) to the NAS. It is
state changes per DSL line, communicated to the NAS. 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.
Not all the fields in GSMP Event message are applicable to ANCP. The Not all the fields in GSMP Event message are applicable to ANCP. The
fields that are not applicable are set to 0 by the ANCP sender, and fields that are not applicable MUST be set to zero by the ANCP sender
ignored by the receiver. The fields in the PORT UP and PORT DOWN and ignored by the ANCP receiver. The fields in the PORT UP and PORT
messages to be set by the ANCP sender, and corresponding handling by the DOWN messages to be set by the ANCP sender, and corresponding
ANCP receiver is described below. handling by the ANCP receiver is described below.
The version field MUST be set to 3, and the sub field MUST be set to 1. The version field MUST be set to 3, and the sub field MUST be set to
As defined in [RFC3292], the one byte Message Type field MUST be set to 1. As defined in [RFC3292], the one byte Message Type field MUST be
80 for PORT UP Event message, and to 81 for PORT DOWN Event Message. The set to 80 for PORT UP Event message, and to 81 for PORT DOWN Event
4 bit Result field and the 8 bit Code field MUST both be set to 0. The Message. The 8 bit Code field MUST be set to 0. The 4 bit Result
24-bit Transaction Identifier field MUST be set to 0. The "I" bit and field MUST be set to 0 (signifying Ignore.) If a PORT UP message
the SubMessage field MUST be set to 1 to signify no fragmentation. The with a Result field set to 0 is received by the NAS and the NAS is
Length field is two bytes and MUST contain the length of the message able to process the message correctly, the NAS MUST NOT generate any
(including header and the payload) in bytes. ANCP message in response to the PORT UP. If the PORT UP message
received cannot be processed correctly by the NAS (e.g. the message
is malformed) the NAS MAY respond with an ANCP Error Message (TBD)
containing the reason of the failure. 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 "Port" field, "Port Session Number" field and "Event Sequence The "Port" field, "Port Session Number" field and "Event Sequence
Number" field are 4 bytes each, and MUST be set to 0 by the ANCP sender. Number" field are 4 bytes each, and MUST be set to 0 by the ANCP
LABEL field in event messages is defined as a TLV in [RFC 3292]. ANCP sender. LABEL field in event messages is defined as a TLV in
does NOT use the Label TLV. In both PORT UP and PORT DOWN event messages [RFC3292]. ANCP does NOT use the Label TLV. In both PORT UP and
an ANCP sender MUST treat the Label field, immediately following the PORT DOWN event messages an ANCP sender MUST treat the Label field,
"Event Sequence Number" field, as a fixed 8 byte field, and MUST set immediately following the "Event Sequence Number" field, as a fixed 8
these 8 bytes to 0. The receiver MUST not interpret the LABEL field as a byte field, and MUST set these 8 bytes to 0. The receiver MUST NOT
TLV and MUST ignore the 8 bytes immediately following the "Event interpret the LABEL field as a TLV and MUST ignore the 8 bytes
Sequence Number" field. In future versions of ANCP, if necessary the immediately following the "Event Sequence Number" field. In future
un-used fields in GSMP Event message, which do not have ANCP specific versions of ANCP, if necessary, the un-used fields in GSMP Event
semantics, can be used partially or completely, by re-naming message, which do not have ANCP specific semantics, can be used
appropriately, and associating valid semantics with these fields. partially or completely, by re-naming appropriately, and associating
valid semantics with these fields.
The Tech Type field is extended with new type "DSL". The value for this The Tech Type field is extended with new type "DSL". The value for
field is 0x05. this field is 0x05.
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 [G.998.1] and [G.998.2]), the DSLAM MUST multi-pair bonding described by [G.988.1] and [G.988.2]), the DSLAM
report the aggregate net data rate and other attributes for the "DSL MUST report the aggregate net data rate and other attributes for the
bonded circuit" (represented as a single logical port) to the NAS in a "DSL bonded circuit" (represented as a single logical port) to the
PORT UP message. Any change in the aggregate net data rate of the "DSL NAS in a PORT UP message. Any change in the aggregate net data rate
bonded circuit" (due to a change in net data rate of individual of the "DSL bonded circuit" (due to a change in net data rate of
constituent DSL lines or due to change in state of the individual individual constituent DSL lines or due to change in state of the
constituent DSL lines) MUST be reported by the DSLAM to the NAS in a individual constituent DSL lines) MUST be reported by the DSLAM to
PORT UP message. The DSLAM MUST also report the "aggregate" state of the the NAS in a PORT UP message. The DSLAM MUST also report the
"DSL bonded circuit" to the NAS via PORT UP and PORT DOWN messages. "aggregate" state of the "DSL bonded circuit" to the NAS via PORT UP
and PORT DOWN messages.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | Message Type | Result| Code | | Vers | Sub | Message Type | Result| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier | | Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length | |I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 25, line 31 skipping to change at page 27, line 41
+ 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 Figure 12
as follows :
The format of the "Extension Value" field for Tech Type "DSL" is as
follows :
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # 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 Figure 13: Extension Value
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 The "Extension Value" contains one or more TLVs to identify a DSL
follow. The next 2 bytes contain the total length of the TLVs carried in line and define its characteristics. A TLV can consist of multiple
the extension block in bytes (existing "Block Length" field in the GSMP sub-TLVs. First 2 byte of the "Extension Value" contains the number
message is limited to 255 bytes and is not sufficient). of TLVs that 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 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 in each TLV is padded to a 4-octet alignment. The Length Figure 14: General TLV
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 The value field in each TLV is padded to a 4-octet alignment. The
NAS, it is silently ignored. Currently defined types start from 0x01. Length 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 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
node (i.e. "local loop"). The "local loop" can be ATM based or access node (i.e. "local loop"). The "local loop" can be ATM
Ethernet based. The "Access Loop Circuit ID" has local significance based or Ethernet based. The "Access Loop Circuit ID" has local
at the access node. The exact usage on the NAS is beyond the scope significance at the access node. The exact usage on the NAS is
of this document. The format used for "local loop" identification beyond the scope of this document. The format used for "local
in ANCP messages MUST be identical to what is used by the access loop" identification in ANCP messages MUST be identical to what
nodes in subscriber signaling messages when the access nodes act as is used by the access nodes in subscriber signaling messages when
"signaling relay agents" as outlined in [RFC3046] and [TR-101]. the access nodes act as "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
VPI/VCI information corresponding to the subscriber's DSL and 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
node as per [TR101] is: access node as per [TR-101] 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
the access network. The slot/port and VPI/VCI uniquely identifies in the access network. The slot/port and VPI/VCI uniquely
the DSL line on the access node. Also, there is one to one identifies the DSL line on the access node. Also, there is
correspondence between DSL line and the VC between the access node one to one correspondence between DSL line and the VC between
and the NAS. the access node and the NAS.
For local loop which is Ethernet based (and tagged), the string For local loop which is Ethernet based (and tagged), the
consists of slot/port and VLAN tag corresponding to the string 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
node as per [TR101] is: access node as per [TR-101] 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
on the access node. The exact usage on the NAS is out of scope of loop on the access node. The exact usage on the NAS is out of
this document. It is desirable that the format used for the field scope of this document. It is desirable that the format used for
is similar to what is used by the access nodes in subscriber the field is similar to what is used by the access nodes in
signaling messages when the access nodes act as "signaling relay subscriber signaling messages when the access nodes act as
agents" as outlined in [RFC3046] and [TR101]. "signaling relay agents" as outlined in [RFC3046] and [TR-101].
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) VLAN can be applied (1:1 model defined in [TR-101]),
For ethernet access aggregation, where a per-subscriber (stacked) the VLAN stack provides a convenient way to uniquely identify
VLAN can be applied (1:1 model defined in [TR101]), the VLAN stack the DSL line. The outer VLAN is equivalent to virtual path
provides a convenient way to uniquely identify the DSL line. The between a DSLAM and the NAS and inner VLAN is equivalent to a
outer VLAN is equivalent to virtual path between a DSLAM and the virtual circuit on a per DSL line basis. In this scenario,
NAS and inner VLAN is equivalent to a virtual circuit on a per DSL any subscriber data received by the access node and
line basis. In this scenario, any subscriber data received by the transmitted out the uplink to the aggregation network will be
access node and transmitted out the uplink to the aggregation tagged with the VLAN stack assigned by the access node
network will be tagged with the VLAN stack assigned by the access
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
ANCP messages. The VLAN tags can uniquely identify the DSL line in the ANCP messages. The VLAN tags can uniquely identify the
being referred to in the ANCP messages, assuming the VLAN tags are DSL line being referred to in the ANCP messages, assuming the
not in any way translated in the aggregation network and are unique VLAN tags are not in any way translated in the aggregation
across physical ports. Each 32 bit integer (least significant bits) network and are unique across physical ports. Each 32 bit
contains a 12 bit VLAN identifier (which is part of the VLAN tag integer (least significant bits) contains a 12 bit VLAN
defined by IEEE 802.1Q). identifier (which is part of the VLAN tag defined by IEEE
802.1Q).
Also, in case of an ATM aggregation network, where the DSLAM is Also, in case of an ATM aggregation network, where the DSLAM
directly connected to the NAS (without an intermediate ATM switch), is directly connected to the NAS (without an intermediate ATM
the two values can contain VPI and VCI on the DSLAM uplink (and can switch), the two values can contain VPI and VCI on the DSLAM
uniquely identify the DSL line on the DSLAM). uplink (and can uniquely identify the DSL line on the DSLAM).
This TLV is optional. This is optional.
4. Type (Access-Aggregation-Circuit-ID-ASCII = 0x03) 4. Type (Access-Aggregation-Circuit-ID-ASCII = 0x03)
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
node assigns VLAN tags (1:1 model), typical format for the string access node assigns VLAN tags (1:1 model), typical format for
is: the string 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
towards the NAS. node 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
the ANCP messages to the DSL line on the access node. in 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,
referring to local loop characteristics (e.g. DSL line in case of a when referring to local loop characteristics (e.g. DSL line
DSLAM), then it should be able to map the information contained in in case of a DSLAM), then it should be able to map the
the string uniquely to the local loop (e.g. DSL line). information contained in 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
derive an "aggregation network" facing construct (e.g. an IP used to derive an "aggregation network" facing construct (e.g.
interface) corresponding to the local loop (e.g. DSL line). The an IP interface) corresponding to the local loop (e.g. DSL
association could be based on "local configuration" on the NAS. line). The 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
(e.g. bandwidth) of the uplink on the access node. This TLV then characteristics (e.g. bandwidth) of the uplink on the access
serves the purpose of uniquely identifying the uplink whose node. This TLV then serves the purpose of uniquely
characteristics are being defined. A separate set of sub-TLVs will identifying the uplink whose characteristics are being
be defined for the uplink characteristics (TBD). defined. A separate set of sub-TLVs will 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 is a mandatory TLV and consists of one or more Sub- Value : This is a mandatory TLV and consists of one or more
TLVs corresponding to DSL line attributes. No sub-TLVs other than Sub-TLVs corresponding to DSL line attributes. No sub-TLVs
the "DSL type" and "DSL line state" SHOULD be included in a PORT other than the "DSL type" and "DSL line state" SHOULD be
DOWN message. 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
format. The value field in each sub-TLV is padded to a 4-octet TLV format. The value field in each sub-TLV is padded to a
alignment. The Length field in each sub-TLV contains the actual 4-octet alignment. The Length field in each sub-TLV contains
number of bytes in the TLV (not including the padding if present). the actual number of bytes in the TLV (not including the
Current defined sub-TLV types are start from 0x81. padding if present). 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
in use. This is a mandatory TLV. system in use. This is a mandatory TLV.
Length : (4 bytes) Length : (4 bytes)
Value : (Transmission system : ADSL1 = 0x01, ADSL2 = 0x02, Value : (Transmission system : ADSL1 = 0x01, ADSL2 =
ADSL2+ = 0x03, VDSL1 = 0x04, VDSL2 = 0x05, SDSL = 0x06, UNKNOWN 0x02, ADSL2+ = 0x03, VDSL1 = 0x04, VDSL2 = 0x05, SDSL =
= 0x07). 0x06, UNKNOWN = 0x07).
. Type (Actual-Net-Data-Upstream = 0x81): Actual upstream net data + Type (Actual-Net-Data-Upstream = 0x81): Actual upstream net
rate on a DSL line. This is a mandatory TLV. data rate on a DSL line. This is a mandatory TLV.
Length : (4 bytes) Length : (4 bytes)
Value : (Rate in Kb/sec) Value : (Rate in Kb/sec)
. Type (Actual-Net-Data-Rate-Downstream = 0x82) : Actual + Type (Actual-Net-Data-Rate-Downstream = 0x82) : Actual
downstream net data rate on a DSL line. This is a mandatory TLV. downstream net data rate on a DSL line. This is a
mandatory TLV.
Length : (4 bytes) Length : (4 bytes)
Value : (Rate in Kb/sec) Value : (Rate in Kb/sec)
. Type (Minimum-Net-Data-Rate-Upstream = 0x83) : Minimum net data
rate desired by the operator. This is optional. + Type (Minimum-Net-Data-Rate-Upstream = 0x83) : Minimum net
data rate desired by the operator. This is optional.
Length : (4 bytes) Length : (4 bytes)
Value : (Rate in Kb/sec) Value : (Rate in Kb/sec)
. Type (Minimum-Net-Data-Rate-Downstream = 0x84) : Minimum net + Type (Minimum-Net-Data-Rate-Downstream = 0x84) : Minimum
data rate desired by the operator. This is optional. net data rate desired by the operator. This is optional.
Length : (4 bytes) Length : (4 bytes)
Value : (Rate in Kb/sec) Value : (Rate in Kb/sec)
. Type (Attainable-Net-Data-Rate-Upstream = 0x85) : Maximum net + Type (Attainable-Net-Data-Rate-Upstream = 0x85) : Maximum
upstream rate that can be attained on the DSL line. This is an net upstream rate that can be attained on the DSL line.
optional TLV. This is an optional TLV.
Length : (4 bytes) Length : (4 bytes)
Value : (Rate in Kb/sec) Value : (Rate in Kb/sec)
. Type (Attainable-Net-Data-Rate-Downstream = 0x86) : Maximum net + Type (Attainable-Net-Data-Rate-Downstream = 0x86) : Maximum
downstream rate that can be attained on the DSL line. This is net downstream rate that can be attained on the DSL line.
an optional TLV. This is an optional TLV.
Length : (4 bytes) Length : (4 bytes)
Value : (Rate in Kb/sec) Value : (Rate in Kb/sec)
. Type (Maximum-Net-Data-Rate-Upstream = 0x87) : Maximum net data + Type (Maximum-Net-Data-Rate-Upstream = 0x87) : Maximum net
rate desired by the operator. This is optional. data rate desired by the operator. This is optional.
Length : (4 bytes) Length : (4 bytes)
Value : (Rate in Kb/sec) Value : (Rate in Kb/sec)
. Type (Maximum-Net-Data-Rate-Downstream = 0x88) : Maximum net + Type (Maximum-Net-Data-Rate-Downstream = 0x88) : Maximum
data rate desired by the operator. This is optional. net data rate desired by the operator. This is optional.
Length : (4 bytes) Length : (4 bytes)
Value : (Rate in Kb/sec) Value : (Rate in Kb/sec)
. Type (Minimum-Net-Low-Power-Data-Rate-Upstream = 0x89) : Minimum
net data rate desired by the operator in low power state. This + Type (Minimum-Net-Low-Power-Data-Rate-Upstream = 0x89) :
is optional. Minimum net data rate desired by the operator in low power
state. This is optional.
Length : (4 bytes) Length : (4 bytes)
Value : (Rate in Kb/sec) Value : (Rate in Kb/sec)
. Type (Minimum-Net-Low-Power-Data-Rate-Downstream = 0x8A) : + Type (Minimum-Net-Low-Power-Data-Rate-Downstream = 0x8A) :
Minimum net data rate desired by the operator in low power Minimum net data rate desired by the operator in low power
state. This is optional. state. This is optional.
Length : (4 bytes) Length : (4 bytes)
Value : (Rate in Kb/sec) Value : (Rate in Kb/sec)
. Type (Maximum-Interleaving-Delay-Upstream = 0x8B) : maximum one + Type (Maximum-Interleaving-Delay-Upstream = 0x8B) : maximum
way interleaving delay. This is optional. one way interleaving delay. This is optional.
Length : (4 bytes) Length : (4 bytes)
Value : (Time in msec) Value : (Time in msec)
. Type (Actual-Interleaving-Delay-Upstream = 0x8C) : Value + Type (Actual-Interleaving-Delay-Upstream = 0x8C) : Value
corresponding to the interleaver setting. This is optional. corresponding to the interleaver setting. This is
optional.
Length : (4 bytes) Length : (4 bytes)
Value : (Time in msec) Value : (Time in msec)
. Type (Maximum-Interleaving-Delay-Downstream = 0x8D) : maximum + Type (Maximum-Interleaving-Delay-Downstream = 0x8D) :
one way interleaving delay. This is optional. maximum one way interleaving delay. This is optional.
Length : (4 bytes) Length : (4 bytes)
Value : (Time in msec) Value : (Time in msec)
. Type (Actual-Interleaving-Delay-Downstream = 0x8E) : Value + Type (Actual-Interleaving-Delay-Downstream = 0x8E) : Value
corresponding to the interleaver setting. This is optional. corresponding to the interleaver setting. This is
optional.
Length : (4 bytes) Length : (4 bytes)
Value : (Time in msec) Value : (Time in msec)
. Type (DSL line state = 0x8F) : The state of the DSL line. For
PORT UP message, at this time, the TLV is optional (since the + Type (DSL line state = 0x8F) : The state of the DSL line.
message type implicitly conveys the state of the line). For PORT For PORT UP message, at this time, the TLV is optional
DOWN, the TLV is mandatory, since it further communicates the (since the message type implicitly conveys the state of the
state of the line as IDLE or SILENT. line). For PORT DOWN, the TLV is mandatory, since it
further communicates the state of the line as IDLE or
SILENT.
Length : (4 bytes) Length : (4 bytes)
Value : { SHOWTIME = 0x01, IDLE = 0x02, SILENT = 0x03 } Value : { SHOWTIME = 0x01, IDLE = 0x02, SILENT = 0x03 }
. Type (Access Loop Encapsulation = 0x90) : The data link protocol + Type (Access Loop Encapsulation = 0x90) : The data link
and, optionally the encapsulation overhead on the access loop. protocol and, optionally the encapsulation overhead on the
This is an optional TLV. However, when this TLV is present, the access loop. This is an optional TLV. However, when this
data link protocol MUST minimally be indicated. The TLV is present, the data link protocol MUST minimally be
encapsulation overhead can be optionally indicated. indicated. The encapsulation overhead can be optionally
indicated.
Length : (3 bytes) Length : (3 bytes)
Value : The three bytes (most to least significant) and
valid set of values for each byte are defined below.
Value : The three bytes (most to least significant) and valid Data Link (1 byte): {ATM AAL5 = 0, ETHERNET = 1}
set of values for each byte are defined below.
Data Link (1 byte): {ATM AAL5 = 0,
ETHERNET = 1} Encaps 1 (1 byte): {
Encaps 1 (1 byte): {NA = 0, NA = 0,
Untagged Ethernet = 1, Untagged Ethernet = 1,
Single-tagged Ethernet = 2} Single-tagged Ethernet = 2}
Encaps 2 (1 byte):{ NA = 0, Encaps 2 (1 byte):{
PPPoA LLC = 1, NA = 0,
PPPoA LLC = 1
PPPoA NULL = 2, PPPoA NULL = 2,
IPoA LLC = 3, IPoA LLC = 3,
IPoA NuLL = 4, IPoA NuLL = 4,
Ethernet over AAL5 LLC with FCS = 5, Ethernet over AAL5 LLC with FCS = 5,
Ethernet over AAL5 LLC without FCS = 6, Ethernet over AAL5 LLC without FCS = 6,
skipping to change at page 33, line 4 skipping to change at page 35, line 34
IPoA LLC = 3, IPoA LLC = 3,
IPoA NuLL = 4, IPoA NuLL = 4,
Ethernet over AAL5 LLC with FCS = 5, Ethernet over AAL5 LLC with FCS = 5,
Ethernet over AAL5 LLC without FCS = 6, Ethernet over AAL5 LLC without FCS = 6,
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
defined above. However, the Access Node can choose to not convey the indicated as defined above. However, the Access Node can
encapsulation on the access loop by specifying a value of 0 (NA) for the choose to not convey the encapsulation on the access loop
two encapsulation fields. by specifying a value of 0 (NA) for the two encapsulation
fields
5.4.3 Line Configuration Extensions 5.4.3. Line Configuration Extensions
The Port Management message format defined in [RFC3292] has been The Port Management message format defined in [RFC3292] has been
modified to contain an extension block (described above in section modified to contain an extension block (described above in section
5.4.1.1) at the end of the message. Also, the original two byte Function Section 5.4.1.1) at the end of the message. Also, the original two
field has been modified to contain one byte for the Function field byte Function field has been modified to contain one byte for the
indicating a specific action to be taken by the recipient of the Function field indicating a specific action to be taken by the
message, and one byte for X-Function field, which could further qualify recipient of the message, and one byte for X-Function field, which
the action specified in the Function field. Any Function specific data could further qualify the action specified in the Function field.
MUST be carried in the extension block.
Any Function specific data MUST be carried in the extension block.
Not all the fields in GSMP Port Management message are applicable to
ANCP. The fields that are not applicable MUST be set to zero by the
ANCP sender and ignored by the ANCP receiver.
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
Port number is set to 0 in the message. A new action type "Configure lines. Port number is set to 0 in the message. A new action type
Connection Service Data" (value 0x8) is defined. The "Function" field is "Configure Connection Service Data" (value 0x8) is defined. The
set to the action type. This action type indicates to the device being "Function" field is set to the action type. This action type
controlled (Access Node i.e. DSLAM) to apply service configuration data indicates to the device being controlled (Access Node i.e. DSLAM) to
contained in the extension value (TLVs), to the DSL line (identified by apply service configuration data contained in the extension value
one of the TLVs in the extension value). For the action type "Configure (TLVs), to the DSL line (identified by one of the TLVs in the
Connection Service Data", X-Function field MUST be set to 0. The Tech extension value). For the action type "Configure Connection Service
Type field is extended with new type "DSL". The value for this field is Data", X-Function field MUST be set to 0. The Tech Type field is
0x05. extended with new type "DSL". The value for this field is 0x05.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | Message Type | Result| Code | | Vers | Sub | Message Type | Result| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier | | Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length | |I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | | Port |
skipping to change at page 34, line 31 skipping to change at page 36, line 49
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Flags | Flow Control Flags | | Event Flags | Flow Control Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15
The format of the "Extension Value" field is as follows: The format of the "Extension Value" field is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs | Extension Block length (bytes)| | # of TLVs | Extension Block length (bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ ~
~ TLVs ~ ~ TLVs ~
~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Extension Value
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 Figure 17: General TLV
each TLV contains the actual number of bytes in the TLV (not
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
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 Section 5.4.1.
can appear in this message: Following TLVs can appear in this message:
oType (Access-Loop-Circuit-ID = 0x01) : defined in section 5.4.1 o Type (Access-Loop-Circuit-ID = 0x01) : defined in section
Section 5.4.1
oType (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in oType (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in
section 5.4.1. section Section 5.4.1
o Type (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in
oType (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in section section Section 5.4.1
5.4.1.
oType (Service-Profile-Name = 0x05): Reference to a pre-configured oType (Service-Profile-Name = 0x05): Reference to a pre-configured
profile on the DSLAM that contains service specific data for the profile on the DSLAM that contains service specific data for the
subscriber. subscriber.
Length : (upto 64 bytes) Length : (upto 64 bytes)
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
of a DSL line (e.g. rates, interleaving delay, multicast channel attributes of a DSL line (e.g. rates, interleaving delay,
entitlement access-list etc). multicast channel 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 Section 5.4.2. The version
be set to 3 and sub-version field SHOULD be set to 1. The remaining field SHOULD be set to 3 and sub-version field SHOULD be set to 1.
fields in the GSMP header have standard semantics. The function type The remaining fields in the GSMP header have standard semantics. The
used in the request message SHOULD be set to "remote loopback" (type function type used in the request message SHOULD be set to "remote
= 0x09). The port, "port session number", "event sequence number", loopback" (type = 0x09). The port, "port session number", "event
duration, "event flags", "flow control flags" and code fields SHOULD sequence number", duration, "event flags", "flow control flags" and
all be set to 0. The result field SHOULD be set to "AckAll" to code fields SHOULD all be set to 0. The result field SHOULD be set
indicate requirement for the access node to send a success or failure to "AckAll" to indicate requirement for the access node to send a
response. The transaction ID SHOULD contain a sequence number success or failure response. The transaction ID SHOULD contain a
inserted by the NAS in each request that it generates. The extension sequence number inserted by the NAS in each request that it
field format is also defined above in section 5.4.2. The extension generates.
value field can contain one or more TLVs including the access-line
identifier on the DSLAM and OAM test characteristics desired by the
NAS.
The TLV format is defined above in section 5.4.2. The value field is Not all the fields in GSMP Port Management message are applicable to
padded to a 4-octet alignment. The Length field in each TLV contains ANCP. The fields that are not applicable MUST be set to zero by the
the actual number of bytes in the TLV (not including the padding if ANCP sender and ignored by the ANCP receiver.
present). If a TLV is not understood by the NAS, it is silently
ignored. Depending upon the deployment scenario, the NAS may specify
"Access Loop Circuit-ID" or the "Access Aggregation Circuit-ID") as
defined in section 5.4.1. Following TLVs can appear in this message:
oType (Access-Loop-Circuit-ID = 0x01) : defined in section 5.4.1 The extension field format is also defined above in section
Section 5.4.2. The extension value field can contain one or more
TLVs including the access-line identifier on the DSLAM and OAM test
characteristics desired by the NAS.
The TLV format is defined above in section Section 5.4.2. 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 including the
padding if present). If a TLV is not understood by the NAS, it is
silently ignored. Depending upon the deployment scenario, the NAS
may specify "Access Loop Circuit-ID" or the "Access Aggregation
Circuit-ID") as defined in section Section 5.4.1. Following TLVs can
appear in this message:
o Type (Access-Loop-Circuit-ID = 0x01) : defined in section
Section 5.4.1
oType (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in oType (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in
section 5.4.1. section Section 5.4.1
oType (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in section o Type (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in
5.4.1. section Section 5.4.1
oType (OAM-Loopback-Test-Parameters = 0x07): Parameters related to oType (OAM-Loopback-Test-Parameters = 0x07): Parameters related to
loopback test. This is an optional TLV. If this TLV is not present loopback test. This is an optional TLV. If this TLV is not
in the request message, the DSLAM SHOULD use locally determined present in the request message, the DSLAM SHOULD use locally
default values for the test parameters. determined default values for the test parameters.
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
of Count, followed by 1 byte of Timeout, followed by two pad bytes byte of Count, followed by 1 byte of Timeout, followed by two
of zero. pad bytes of zero.
o Count (1 byte) : Number of loopback cells/messages that should
be generated on the local loop as part of the loopback test.
The NAS SHOULD restrict the "count" to be greater than 0 and
less than or equal to 32. The DSLAM SHOULD discard the request
for a loopback test, if the received test parameters contain an
out of range value for the "count" field. The DSLAM MAY
optionally send a failure response to the NAS with the code
"invalid test parameter".
o Timeout (1 byte) : Upper bound on the time in seconds that the + Count (1 byte) : Number of loopback cells/messages that
NAS would wait for a response from the DSLAM. If the total time should be generated on the local loop as part of the
taken by the DSLAM to complete a test with requested loopback test. The NAS SHOULD restrict the "count" to be
parameters, exceeds the specified "timeout" value, it can greater than 0 and less than or equal to 32. The DSLAM
choose to omit the generation of a response to the NAS. DSLAM SHOULD discard the request for a loopback test, if the
SHOULD use a locally determined value for the "timeout", if the received test parameters contain an out of range value for
received value of the "timeout" parameter is 0. the "count" field. The DSLAM MAY optionally send a failure
response to the NAS with the code "invalid test parameter".
oType (Opaque-Data = 0x08) : This is an optional TLV. If present in + Timeout (1 byte) : Upper bound on the time in seconds that
the request message, the DSLAM SHOULD reflect it back in the the NAS would wait for a response from the DSLAM. If the
response unmodified. total time taken by the DSLAM to complete a test with
requested parameters, exceeds the specified "timeout" value,
it can choose to omit the generation of a response to the
NAS. DSLAM SHOULD use a locally determined value for the
"timeout", if the received value of the "timeout" parameter
is 0.
Length : 8 bytes o Type (Opaque-Data = 0x08) : This is an optional TLV. If present
in the request message, the DSLAM SHOULD reflect it back in the
response unmodified
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
is used. The result field SHOULD be set to success or failure. The 32) is used. The result field SHOULD be set to success or failure.
function type SHOULD be set to 0x09. The transaction ID SHOULD be The function type SHOULD be set to 0x09. The transaction ID SHOULD
copied from the sequence number contained in the corresponding be 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
0x501 : Loopback test timed out. 0x501 : Loopback test timed out
0x502 : Reserved 0x502 : Reserved
0x503 : DSL line status showtime. 0x503 : DSL line status showtime
0x504 : DSL line status idle. 0x504 : DSL line status idle
0x505 : DSL line status silent. 0x505 : DSL line status silent
0x506 : DSL line status training. 0x506 : DSL line status training
0x507 : DSL line integrity error. 0x507 : DSL line integrity error
0x508 : DSLAM resource not available. 0x508 : DSLAM resource not available
0x509 : Invalid test parameter. 0x509 : Invalid test parameter
The Extension value can contain one or more TLVs including the TLV to The Extension value can contain one or more TLVs including the TLV to
identify the access line on which the test was performed, and details identify the access line on which the test was performed, and details
from executing the test. The access line identifier SHOULD be identical from executing the test. The access line identifier SHOULD be
to what was contained in the request. The relevant TLVs are: identical to what was contained in the request. The relevant TLVs
are:
oType (Access-Loop-Circuit-ID = 0x01) : defined in section 5.4.1 o Type (Access-Loop-Circuit-ID = 0x01) : defined in section
Section 5.4.1
oType (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in oType (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in
section 5.4.1. section Section 5.4.1
o Type (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in
oType (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in section section Section 5.4.1
5.4.1.
oType (Opaque-Data = 0x08) : Data inserted by the NAS in the request o Type (Opaque-Data = 0x08) : Data inserted by the NAS in the
reflected back by the DSLAM. request reflected back by the DSLAM.
Length : 8 bytes Length : (up to 8 bytes)
Value : Two 32 bit integers as received in the request (opaque to Value : Two 32 bit integers as received in the request (opaque
the DSLAM). to the DSLAM).
oType (OAM-Loopback-Test-Response-String = 0x09) oType (OAM-Loopback-Test-Response-String = 0x09)
Length (upto 128 bytes) Length : (up to 128 bytes)
Value : Suitably formatted ASCII string containing useful details Value : Suitably formatted ASCII string containing useful
about the test that the NAS will display for the operator, exactly details about the test that the NAS will display for the
as received from the DSLAM (no manipulation/interpretation by the operator, exactly as received from the DSLAM (no manipulation/
NAS). This is an optional TLV, but it is strongly recommended, interpretation by the NAS). This is an optional TLV, but it is
that in case of ATM based local loop, the DSLAM at the very least strongly recommended, that in case of ATM based local loop, the
indicates via this TLV, the total loopback cells generated and the DSLAM at the very least indicates via this TLV, the total
total loopback cells successfully received as part of executing loopback cells generated and the total loopback cells
the requested loopback test. successfully received as part of executing the requested
loopback test.
5.5 ATM-specific considerations 5.4.5. Multicast Extensions
The format of the ANCP Multicast message starts with the common GSMP
header as in the case of the existing ANCP implementation. Following
is the format of this header:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | Message Type | Result| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Message Payload ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: ANCP Header
The Result field takes one of the values defined in Section 5.
The Transaction Identifier field is used to distinguish between
request messages and to associate a response message to a request.
Applications that require such response correlation MUST set the
Transaction Identifier to a value in the range (1, 2^24 - 1). When
used in this manner, the Transaction Identifier sequencing MUST be
maintained independently for each ANCP adjacency and per message
type. Furthermore, it SHOULD be incremented linearly for each new
message of the given type, cycling back to 1 after running the full
range. Message types not requiring response message correlation
SHOULD set the Transaction Id field to 0x0. In the event of an ANCP
transport protocol failure, all pending ANCP messages destined to the
disconnected recipient can be discarded until the transport is re-
established following which the Transaction Identifier is re-
initialized.
The value of the Transaction Identifier in a Response message MUST be
set to that of the respective Request message. This allows the
Requester to correlate the Response to the original Request. The
Transaction Identifier is not used in ANCP adjacency messages. Also,
other ANCP applications not requiring it SHOULD set the Transaction
Identifier to 0x0 in their messages.
All TLVs within the ANCP message have to be 32 bit aligned, and when
necessary padded with 0s to the 32 bit boundary. The padding is not
reflected in the message length field.
5.4.5.1. General well known TLVs
This section contains the definitions of three general well known
TLVs. These TLVs are intended to be re-usable across different
Multicast messages.
5.4.5.1.1. Target TLV
The Target TLV (TBD) is intended to be a general well known TLV
allowing the representation of different types of objects. Its use
is not restricted to any specific Message Type.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target | Target-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Target Info ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Target TLV:
TLV (0xTBD) indicating the type of target being addressed.
Numbers TBC. Tentative 0x1000 for single Access-Port.
Target TLV Length:
Length in bytes of Target Info. Excludes TLV header
Target Info:
Target information as defined for each the given target.
The field can consist of sub-TLVs.
In its simplest form, when targeting a single access line the Target-
TLV will be set to a value of (0xTBD), and carry in its payload one
or more sub-TLVs identifying the target. The following example
illustrates the message format for a single port identified by an
Access-Loop-Circuit-ID TLV (0x0001) that could be derived from a
Port-UP message:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target | Target-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.4.5.1.2. Command TLV
The Command TLV (TBD) is intended to be a general well known TLV
allowing the encapsulation of one or more command directives in a TLV
oriented message. The semantics of the command are allowed to be
specified for each message type, ie different message types that
choose to carry the Command TLV are expected to define the meaning of
the content of the payload, which could be re-used from those already
defined elsewhere if appropriate.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Command | Command-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Command Info ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional sub-TLV Type | Additional sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Additional sub-TLV data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Command TLV:
TLV (0xTBD) indicating the contents to be one or more
command directives.
Command TLV Length:
Combined length in bytes of the data in Command Info and
sub-TLV. Excludes the Command TLV header
Commad-Info:
Command information as defined for each message type. The
field can consist of sub-TLVs.
Additional sub-TLV:
Additional sub-TLVs can be present in a command TLV. Any
such sub-TLVs must directly follow each command.
Additional sub-TLV Length:
Number of actual bytes contained in the value portion of
each additional sub-TLV
5.4.5.1.3. Status-Info TLV
The Status-info-TLV is intended to be a general well known TLV used
to convey the status code regarding commands and/or requests. The
format of the Status-Info-TLV (TBD) is shown below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Status-info | Status TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Cmnd Nmbr | Error Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message (aligned to 4 bytes length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLVs... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Status-info TLV:
TLV (0xTBD) conveying the status or error response of a
command
Status TLV Length:
Specifies the length in bytes of the Status Info TLV
payload. Excludes the TLV header
Result Code:
Conveys the result code for the command or message, as
defined by the application.
Cmnd Nmbr:
Contains the command number copied from the Request
message. The value of 0 is used whenever the error is not
specific to a command.
Error Message Length:
Contains the length of an optional error message or 0 if
none.
TLVs:
This field is of indeterminate length, and contains zero or
more of the TLVs associated with the Status-info-TLV.
5.4.5.2. Multicast Replication Control Message
The Multicast Replication Control Message Type 0x90 (TBC) is sent by
the NAS to the AN with a directive to either add (join) or delete
(leave) one or more multicast flows on a target object identified in
the content of the message. An AN will use a Multicast Status
message when conveying the outcome of the directive, and this message
type is covered in Section 5.4.5.3.
The sender of a Multicast Replication Control message MUST set the
Result field to either "AckAll" or "NAck", and SHOULD use "NAck" by
default. Furthermore it SHOULD use the same Result field code for
all Multicast Replication Control Messages sent, i.e. Result field
changes SHOULD be avoided. The sender MUST populate the ANCP
Transaction Identifier field with a distinct non-zero, linearly
incrementing value for each Request per adjacency, as described in
Section 5.4.5 .
The ANCP Multicast Replication Control message payload contains the
following TLVs:
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 = Target TLV | Length of Target-Info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value = Target-Info ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Command TLV | Length of Command Info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value = Command Info ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Target:
See Section 5.4.5.1.1. The Target TLV (0xTBD) can only feature
once in a Multicast Replication Control Message. Only one such
TLV is allowed in this message type.
Length of Target-Info:
See Section 5.4.5.1.1
Target Info:
See Section 5.4.5.1.1
Command TLV:
The Command TLV (0xTBD) contains the multicast flow
directive(s) for the target and any additional parameters
passed via sub-TLVs. See Section 5.4.5.1.2
Length of Command Info:
Includes sub-TLVs. See Section 5.4.5.1.2
Command Info:
Command information as defined in section
Section 5.4.5.1.2.
The contents of the Command TLV for the Multicast Replication Control
Message are defined to be as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |R O M Flags | Command Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Multicast Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++++++|
| Addr Family | Encoding Type | Multicast Flow Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++++++-+
Command Code:
Command directive: 0x01 - Add; 0x02 - Delete; 0x03 - Delete
All.
Command Length:
Length in bytes of each Command including multicast flow
address, but excluding the Command Code header and flags.
Flags:
8 bit General purpose Flag field. Currently the following
flags are defined:
R -
Resource Admitted Flag. Set to 1 in an add
command to indicate that the flow resources have
been reserved by admission control, 0 otherwise.
Not used in delete command.
O -
Flow Accounting. When set in add command
indicates that byte accounting for the flow is to
commence.
M -
When set indicates that multicast flow is SSM and
the address-family-element set MUST specify the
source and group addresses. When not set
indicates that multicast flow is ASM and address-
family-element MUST specify the group address,
and the Source Address field is to be omitted.
Address Family:
The address family used
The unicast source address/mask follows the format defined in
[IANAAEA]
Encoded-Unicast-address: Takes the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Unicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++++++++
Encoded-Unicast-address: Takes the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Unicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++++++++
Encoding Type:
The type of encoding used within a specific Address Family.
The value `0' is reserved for this field, and represents
the native encoding of the Address Family.
The address as represented by the given Address Family and
Encoding Type.
Address:
The address as represented by the given Address Family and
Encoding Type.
The padding will be done after both addresses so that it is 32-bit
aligned. As an example for IPv4:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CmdCode=0x01 |0 0 1 Flags | Command Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 0x1| Enc Type 0x0 | Src Address first 2 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address last 2 bytes | AddrFamily 0x1| Enc Type 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the above example, no padding is required.
A received Multicast Replication Control Message containing an
unrecognized Target TLV MUST be communicated to the sender as an
error in a Multicast Status Message indicating the "Unrecognised port
Type - 0x04" error. The reception of a Multicast Replication Control
Message, or any ANCP message, that is found to have mandatory TLVs
missing is to be addressed as part of a ANCP base protocol mechanism
yet to be defined.
Each Multicast Replication Control Message may contain one or more
command directives, each encapsulated by their own Command TLVs. The
sender MUST use separate Command TLVs for each distinct multicast
flow. When successive commands relate to a given Target and flow,
the state of features controlled or affected by flags as well as by
optional attributes received in the Multicast Replication Control
message, are to be interpreted as replacing any such previous state
for that port and flow. As an example, successive Multicast
Replication Control messages containing add commands for a given port
and flow, but differing in the accounting flag setting should be
interpreted as affecting the state of the accounting feature.
The recipient of a Multicast Replication Control message is to run an
implicit directive numbering across the multiple directives in the
message. The numbering is to start from 0x01 for each directive in a
given ANCP Multicast Replication Control message, and be restarted
for subsequent messages. The recipient MUST process the directives
in the order of reception, and use the derived directive number in
any response messages, besides the Transaction ID.
The processing/execution of multiple directives contained in a single
Multicast Control message MUST be interrupted at the first error, and
the remaining commands in the Multicast Replication Control message
discarded. In such a case a Multicast Status message MUST be sent
indicating the command number that resulted in the error along with
the error code.
When the strict sequenced processing of the directives in a single
Multicast Control message is not required the directives MUST be
distributed across separate Multicast Replication Control messages.
Each command directive is equipped with an 8-bit Flags field that
allows specification of Multicast ASM or SSM modes of operation, and
an indication of other features or conditions attached to this
command (e.g. To enable accounting for the flow, etc). Unassigned
flags are reserved for future use, and could in the future be subject
of the capability negotiation. When receiving a Multicast
Replication Control Message containing an unrecognized Flag set (to
1), a recipient MUST interpret it as an error, and generate an
Multicast Status message indicating the error.
The multicast flow subject to the command is specified by means of
one or two well known Address Family designators ([IANAAEA]), the
IPv4-Address-Family (0x01) and the IPv6-Address-Family (0x02). When
the M flag is set the two Address-Family tuples MUST be present in
the strict order specifying the multicast flow source and group
respectively. When the M flag is cleared only one Address-Family is
allowed, specifying the multicast flow.
For future extensibility, each command may also have additional TLVs
appended following the command and multicast flow information
(referred to as "TLVs" in the message format above). Unrecognized
TLVs SHOULD be silently discarded. The figure below is an example of
a Multicast Replication Control message that would result in a swap
from multicast SSM flows 192.0.2.1, 233.252.0.2, to 192.0.2.2,
233.252.0.3 on the Target identified by the "Access Loop Circuit ID":
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 (0x88-0C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub |MessageType=90 | 0x02 | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier = 0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Command TLV | Command-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code=0x02 |0 0 1 | Command Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.0.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
| Type = Command-TLV | Command-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code=0x01 |0 0 1 | Command Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Flow: 233.252.0.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.4.5.3. Multicast Status Message
The Multicast Status Message (Message Type 0x91 - TBC) is sent by the
AN to the NAS in response to a Multicast Replication Control Message
and its command directives. A Multicast Status message MUST use the
same ANCP Transaction ID as that in the original Multicast
Replication Control Message. The Success or Failure status is
reported in the Result field of the ANCP header as described in
Section 5.4.5.
A Multicast Status Message indicating Success SHOULD simply consist
only of the base ANCP header with no body, however the message MAY
contain one or more TLVs that are meant to communicate any relevant
information to an application. The payload of a Multicast Status
Message indicating Failure MUST contain an Status-Info TLV (0xTBD),
as defined in Section 5.4.5.1.3, as its first TLV and SHOULD be
followed by the Target TLV and Port-info. Other TLVs MAY be present.
A Multicast Status message indicating Failure MUST be sent whenever a
Multicast Control message cannot be fulfilled or results in an
execution error. The Cmnd Nmbr parameter in the Status-Info TLV
contained by the Multicast Status Message is to indicate the number
of the command in the Multicast Replication Control Message that
resulted in an error.
0x00 - Success
0x01 - Malformed message
0x02 - Command not supported
0x03 - Flag set but not supported
0x04 - Unrecognized Target
0x05 - Unsupported Address Family
0x06 - Malformed flow address
0x07 - No resources
0x08 - Unknown Target
0x09 - Target down
0x0a - Configuration error (such as Port not enabled for
multicast)
0x0b - Multicast flow does not exist
0x0c - Unsupported address encoding
0x0d - Additional info needed to execute command (payload MAY
contain an indication of the expected info)
0x0e - Multicast flow count exceeded
0x0f - M Flag set, but no IP Source address provided
0x10 - Transaction-id out of sequence
An example of a failure message for an invalid address, including the
Target TLV for a 4 byte "Access Loop Circuit ID", followed by TLV
padding, is as follows:
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 (0x88-0C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub |MessageType=91 | 0x4 | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier = 0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status-info-TLV=TBD | Status-TLV-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Cmd Number | Error Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message (padded to 4) if Length > 0 |
+---------------------------------------------------------------+
| Target TLV=0x100 | Target-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop ID type | Access-Loop ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.5. ATM-specific considerations
The topology discovery and line configuration involve the DSL line The topology discovery and line configuration involve the DSL line
attributes. For ATM based access networks, the DSL line on the DSLAM attributes. For ATM based access networks, the DSL line on the DSLAM
is identified by the port and PVP/PVC corresponding to the is identified by the port and PVP/PVC corresponding to the
subscriber. The DSLAMs are connected to the NAS via an ATM access subscriber. The DSLAMs are connected to the NAS via an ATM access
aggregation network. Since, the DSLAM (access-node) is not directly aggregation network. Since, the DSLAM (access-node) is not directly
connected to the NAS, the NAS needs a mechanism to learn the DSL line connected to the NAS, the NAS needs a mechanism to learn the DSL line
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
ID" which has only local significance on the DSLAMs. Circuit-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
"virtual path" between a given DSLAM and a given NAS. And then use of "virtual path" between a given DSLAM and a given NAS. And then
"inner" VLAN tags to create a form of "virtual circuit" on a per DSL use "inner" VLAN tags to create a form of "virtual circuit" on a per
line basis. In this case, VLAN tags conveyed in topology discovery and DSL line basis. In this case, VLAN tags conveyed in topology
line configuration messages will allow to uniquely identify the DSL line discovery and line configuration messages will allow to uniquely
in a straightforward manner, assuming the VLAN tags are not translated identify the DSL line in a straightforward manner, assuming the VLAN
in some way by the aggregation network, and are unique across physical tags are not translated in some way by the aggregation network, and
ports. are unique across physical 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
network. This is the N:1 model. In this model, or in the case where user aggregation network. This is the N:1 model. In this model, or in
traffic is sent untagged, the access node needs to insert the exact the case where user traffic is sent untagged, the access node needs
identity of the DSL line in the topology discovery and line to insert the exact identity of the DSL line in the topology
configuration messages, and then have a mechanism by which this can be discovery and line configuration messages, and then hve a mechanism
correlated to the context of an "aggregation network" facing IP by which this can be correlated to the context of an "aggregation
interface (for the subscriber) on the NAS. This can either be based on network" facing IP interface (for the subscriber) on the NAS. This
local configuration on the NAS, or on the fact that such DSLAM (access can either be based on local configuration on the NAS, or on the fact
node) typically inserts the "Access Loop Circuit ID" in subscriber that such DSLAM (access node) typically inserts the "Access Loop
signaling messages relayed to the NAS (i.e. DHCP or PPPoE discovery Circuit ID" in subscriber signaling messages relayed to the NAS (i.e.
messages). DHCP or PPPoE discovery messages).
Section 5.4.1 defines "Access Loop Circuit ID". Section 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, TLVs, sub-TLV types related to
discovery and line configuration will need to be reserved. topology discovery, line configuration and Multicast will need to be
reserved.
7 Security Considerations 7. Security Considerations
The NAS and DSLAMs are implicitly in a trusted domain, so security Security of the ANCP protocol is discussed in [ANCP-SEC]
for ANCP is not a strong requirement. However, if needed security can
be provided using IP security as indicated in [RFC3293].
8 References 8. Acknowledgements
8.1 Normative References The authors would like to thank everyone that has provided comments
or inputs to this document. In particular, the authors acknowledge
the inputs provided by Peter Arberg, Josef Froehler, Derek Harkness,
Kim Hyldgaard, Sandy Ng, Robert Peschi, Michel Platnic and the work
done by Philippe Champagne, Wojciech Dec and Stefaan De Cnodder
regarding multicast extensions.
[RFC3292] Doria, A. et al, "General Switch Management Protocol- V3" 9. References
(GSMP v3), RFC 3292, June 2002.
[RFC3293] Worster, T., Doria, A. and J. Buerkle, "General Switch 9.1. Normative References
Management Protocol (GSMP) Packet Encapsulations for Asynchronous
Transfer Mode (ATM), Ethernet and Transmission Control Protocol
(TCP)", RFC 3293, June 2002.
[RFC3046] "DHCP Relay Agent Information Option", RFC 3046, January [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2001. Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2 Informative References [RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
January 2001.
[TR-059] DSL Forum TR-059, DSL Evolution - Architecture Requirements [RFC3292] Doria, A. and et all, "General Switch Management Protocol
for the Support of QoS-Enabled IP Services, Tom Anschutz (BellSouth (GSMP) V3", June 2002.
Telecommunications), 09/2003.
[TR-058] DSL Forum TR-058, Multi-Service Architecture & Framework [RFC3293] Worster, T., Doria, A., and and J. Buerkle, "General
Requirements, Mark Elias (SBC) and Sven Ooghe (Alcatel), 09/2003. Switch Management Protocol (GSMP) Packet Encapsulations
for Asynchronous Transfer Mode (ATM), Ethernet and
Transmission Control Protocol (TCP)", June 2002.
[TR-092] DSL Forum TR-092, Broadband Remote access server 9.2. Informative References
requirements document.
[TR-101] Architecture & Transport: "Migration to Ethernet Based DSL [ANCP-FRAMEWORK]
Aggregation", DSL Forum TR-101, Cohen et al. Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S.
Wadhwa, "Framework and Requirements for an Access Node
Control Mechanism in Broadband Multi-Service Networks",
draft-ietf-ancp-framework-06.txt, , May 2008.
[ANCP-FRAMEWORK] Framework for Access Node Control Mechanism in [ANCP-SEC]
Broadband Networks, draft-ietf-ancp-framework-00.txt. Moustafa, H., Tschofenig, T., and S. De Cnodder, "Security
Threats and Security Requirements for the Access Node
Control Protocol (ANCP)",
draft-ietf-ancp-security-threats-06.txt work in progress,
October 2008.
[G.998.1] ITU-T recommendation G.998.1, ATM-based multi-pair bonding, [G.988.1] "ITU-T recommendation G.998.1, ATM-based multi-pair
bonding,", 2005.
[G.988.2] "ITU-T recommendation G.998.2, Ethernet-based multi-pair
bonding,", 2005.
[IANAAEA] "http://www.iana.org/assignments/address-family-numbers",
2005. 2005.
[G.998.2] ITU-T recommendation G.998.2, Ethernet-based multi-pair [TR-058] Elias, M. and S. Ooghe, "DSL Forum TR-058, Multi-Service
bonding, 2005. Architecture & Framework Requirements", September 2003.
Author's Addresses [TR-059] Anschutz, T., "DSL Forum TR-059, DSL Evolution -
Architecture Requirements for the Support of QoS-Enabled
IP Services", September 2003.
[TR-092] "DSL Forum TR-092, Broadband Remote access server
requirements document", 2005.
[TR-101] Cohen et al, "Architecture & Transport: "Migration to
Ethernet Based DSL Aggregation", DSL Forum TR-101", 2005.
Authors' Addresses
Sanjay Wadhwa Sanjay Wadhwa
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
USA
Phone:
Fax:
Email: swadhwa@juniper.net Email: swadhwa@juniper.net
Jerome Moisand Jerome Moisand
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
USA
Phone:
Fax:
Email: jmoisand@juniper.net Email: jmoisand@juniper.net
Swami Subramanian Swami Subramanian
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
USA
Phone:
Fax:
Email: ssubramanian@juniper.net Email: ssubramanian@juniper.net
Thomas Haag Thomas Haag
T-systems T-systems
Phone:
Fax:
Email: thomas.haag@t-systems.com Email: thomas.haag@t-systems.com
Norber Voigt Norber Voigt
Siemens Siemens
Phone:
Fax:
Email: norbert.voigt@siemens.com Email: norbert.voigt@siemens.com
Roberta Maglione
Telecom Italia
via Reiss Romoli 274
Torino
Italy
Phone:
Email: roberta.maglione@telecomitalia.it
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). 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.
herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE
ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE This document and the information contained herein are provided on an
INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
OR FITNESS FOR A PARTICULAR PURPOSE. THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 43, line 33 skipping to change at page 59, line 43
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org ietf-ipr@ietf.org.
Acknowledgment
Thanks to Peter Arberg, Josef Froehler, Derek Harkness, Kim
Hyldgaard, Sandy Ng, Robert Peschi, Michel Platnic, Stefaan DE
Cnodder and Wojciech Dec for their input to this document.
 End of changes. 251 change blocks. 
712 lines changed or deleted 1528 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/