draft-ietf-ancp-protocol-10.txt   draft-ietf-ancp-protocol-11.txt 
Network Working Group S. Wadhwa Network Working Group S. Wadhwa
Internet-Draft J. Moisand Internet-Draft J. Moisand
Intended status: Standards Track Juniper Networks Intended status: Standards Track Juniper Networks
Expires: January 12, 2011 T. Haag Expires: February 24, 2011 T. Haag
Deutsche Telekom Deutsche Telekom
N. Voigt N. Voigt
Nokia Siemens Networks Nokia Siemens Networks
T. Taylor, Ed. T. Taylor, Ed.
Huawei Technologies Huawei Technologies
July 11, 2010 August 23, 2010
Protocol for Access Node Control Mechanism in Broadband Networks Protocol for Access Node Control Mechanism in Broadband Networks
draft-ietf-ancp-protocol-10 draft-ietf-ancp-protocol-11
Abstract Abstract
This document describes the Access Node Control Protocol (ANCP). This document describes the Access Node Control Protocol (ANCP).
ANCP operates between a Network Access Server (NAS) and an Access ANCP operates between a Network Access Server (NAS) and an Access
Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)) in a Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)) in a
multi-service reference architecture in order to perform QoS-related, multi-service reference architecture in order to perform QoS-related,
service-related and subscriber- related operations. Use cases for service-related and subscriber- related operations. Use cases for
ANCP are documented in RFC 5851. As well as describing the base ANCP ANCP are documented in RFC 5851. As well as describing the base ANCP
protocol, this document specifies capabilities for Digital Subscriber protocol, this document specifies capabilities for Digital Subscriber
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 12, 2011. This Internet-Draft will expire on February 24, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 14 skipping to change at page 3, line 14
Table of Contents Table of Contents
1. Specification Requirements . . . . . . . . . . . . . . . . . . 5 1. Specification Requirements . . . . . . . . . . . . . . . . . . 5
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
3. Broadband Access Aggregation . . . . . . . . . . . . . . . . . 7 3. Broadband Access Aggregation . . . . . . . . . . . . . . . . . 7
3.1. ATM-based broadband aggregation . . . . . . . . . . . . . 7 3.1. ATM-based broadband aggregation . . . . . . . . . . . . . 7
3.2. Ethernet-based broadband aggregation . . . . . . . . . . . 9 3.2. Ethernet-based broadband aggregation . . . . . . . . . . . 9
4. Access Node Control Protocol -- General Aspects . . . . . . . 9 4. Access Node Control Protocol -- General Aspects . . . . . . . 9
4.1. Protocol Version . . . . . . . . . . . . . . . . . . . . . 10 4.1. Protocol Version . . . . . . . . . . . . . . . . . . . . . 11
4.2. ANCP Transport . . . . . . . . . . . . . . . . . . . . . . 11 4.2. ANCP Transport . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Use of the GSMPv3 Adjacency Protocol . . . . . . . . . . . 12 4.3. Encoding of Text Fields . . . . . . . . . . . . . . . . . 12
4.3.1. ANCP Adjacency Message Format . . . . . . . . . . . . 12 4.4. Treatment of Reserved and Unused Fields . . . . . . . . . 12
4.3.2. ANCP Adjacency Procedures . . . . . . . . . . . . . . 15 4.5. Use of the GSMPv3 Adjacency Protocol . . . . . . . . . . . 12
4.4. ANCP General Message Formats . . . . . . . . . . . . . . . 16 4.5.1. ANCP Adjacency Message Format . . . . . . . . . . . . 13
4.4.1. The ANCP Message Header . . . . . . . . . . . . . . . 17 4.5.2. ANCP Adjacency Procedures . . . . . . . . . . . . . . 15
4.4.2. The ANCP Message Body . . . . . . . . . . . . . . . . 20 4.6. ANCP General Message Formats . . . . . . . . . . . . . . . 17
4.6.1. The ANCP Message Header . . . . . . . . . . . . . . . 17
4.6.2. The ANCP Message Body . . . . . . . . . . . . . . . . 20
5. ANCP Capabilities For Digital Subscriber Lines (DSL) . . . . . 22 5. ANCP Capabilities For Digital Subscriber Lines (DSL) . . . . . 22
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1.1. ATM-Specific Considerations . . . . . . . . . . . . . 22 5.1.1. ATM-Specific Considerations . . . . . . . . . . . . . 22
5.1.2. Ethernet-Specific Considerations . . . . . . . . . . . 23 5.1.2. Ethernet-Specific Considerations . . . . . . . . . . . 23
5.2. ANCP Based DSL Topology Discovery . . . . . . . . . . . . 23 5.2. ANCP Based DSL Topology Discovery . . . . . . . . . . . . 24
5.2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 24 5.2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 24
5.2.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 24 5.2.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 24
5.2.3. Specification of the ANCP DSL Topology Discovery 5.2.3. Specification of the ANCP DSL Topology Discovery
Capability . . . . . . . . . . . . . . . . . . . . . . 25 Capability . . . . . . . . . . . . . . . . . . . . . . 25
5.3. ANCP based DSL Line Configuration . . . . . . . . . . . . 39 5.3. ANCP based DSL Line Configuration . . . . . . . . . . . . 40
5.3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 39 5.3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 40 5.3.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 40
5.3.3. Specification of the ANCP DSL Line Configuration 5.3.3. Specification of the ANCP DSL Line Configuration
Capability . . . . . . . . . . . . . . . . . . . . . . 42 Capability . . . . . . . . . . . . . . . . . . . . . . 42
5.4. ANCP Based DSL Line Testing Capability . . . . . . . . . . 46 5.4. ANCP Based DSL Line Testing Capability . . . . . . . . . . 46
5.4.1. Message Flow . . . . . . . . . . . . . . . . . . . . . 46 5.4.1. Message Flow . . . . . . . . . . . . . . . . . . . . . 46
5.4.2. Specification of the ANCP DSL Line Testing 5.4.2. Specification of the ANCP DSL Line Testing
Capability . . . . . . . . . . . . . . . . . . . . . . 47 Capability . . . . . . . . . . . . . . . . . . . . . . 47
6. Additional ANCP Messages and TLVs . . . . . . . . . . . . . . 50 6. Additional ANCP Messages and TLVs . . . . . . . . . . . . . . 51
6.1. Additional Messages and General Messaging Principles . . . 51 6.1. Additional Messages and General Messaging Principles . . . 51
6.1.1. General Principles for the Design of ANCP Messages . 51 6.1.1. General Principles for the Design of ANCP Messages . 51
6.1.2. Provisioning Message . . . . . . . . . . . . . . . . . 51 6.1.2. Provisioning Message . . . . . . . . . . . . . . . . . 52
6.1.3. Generic Response Message . . . . . . . . . . . . . . . 52 6.1.3. Generic Response Message . . . . . . . . . . . . . . . 53
6.2. TLVs For General Use . . . . . . . . . . . . . . . . . . . 54 6.2. TLVs For General Use . . . . . . . . . . . . . . . . . . . 54
6.2.1. Target TLV . . . . . . . . . . . . . . . . . . . . . . 54 6.2.1. Target TLV . . . . . . . . . . . . . . . . . . . . . . 54
6.2.2. Command TLV . . . . . . . . . . . . . . . . . . . . . 55 6.2.2. Command TLV . . . . . . . . . . . . . . . . . . . . . 55
6.2.3. Status-Info TLV . . . . . . . . . . . . . . . . . . . 55 6.2.3. Status-Info TLV . . . . . . . . . . . . . . . . . . . 56
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 57 7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.2. IANA Actions . . . . . . . . . . . . . . . . . . . . . . . 57 7.2. IANA Actions . . . . . . . . . . . . . . . . . . . . . . . 58
8. Security Considerations . . . . . . . . . . . . . . . . . . . 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 62
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 62 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 62
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62
10.1. Normative References . . . . . . . . . . . . . . . . . . . 62 10.1. Normative References . . . . . . . . . . . . . . . . . . . 62
10.2. Informative References . . . . . . . . . . . . . . . . . . 63 10.2. Informative References . . . . . . . . . . . . . . . . . . 63
Appendix A. Changes from Version -09 to Version -10 . . . . . . . 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 65
1. Specification Requirements 1. Specification Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
This draft defines a new protocol, the Access Node Control Protocol This draft defines a new protocol, the Access Node Control Protocol
skipping to change at page 6, line 24 skipping to change at page 6, line 24
At the time of writing of this specification some implementations of At the time of writing of this specification some implementations of
the ANCP protocol based on pre-standards drafts are already the ANCP protocol based on pre-standards drafts are already
available. These early-draft implementations use protocol version/ available. These early-draft implementations use protocol version/
sub-version 3.1. The standard ANCP protocol will use version/ sub-version 3.1. The standard ANCP protocol will use version/
sub-version 3.2 Adopting a new sub-version value provides a way to sub-version 3.2 Adopting a new sub-version value provides a way to
disambiguate the two protocols and provides support for running a disambiguate the two protocols and provides support for running a
pre-standard and a standards compliant ANCP implementation on any pre-standard and a standards compliant ANCP implementation on any
given ANCP node. The mechanism used to identify the protocol given ANCP node. The mechanism used to identify the protocol
version/sub-version is part of the adjacency negotiation process and version/sub-version is part of the adjacency negotiation process and
it is described in detail in Section 4.3. NOTE: this mechanism does it is described in detail in Section 4.5. NOTE: this mechanism does
not guarantee backwards compatibility of the published ANCP not guarantee backwards compatibility of the published ANCP
specification with those early-draft implementations. specification with those early-draft implementations.
2.1. Terminology 2.1. Terminology
Access Node (AN): Network device, usually located at a service 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 (local) loop connections from subscribers. In case the access
loop is a Digital Subscriber Line (DSL), the Access Node provides loop is a Digital Subscriber Line (DSL), the Access Node provides
DSL signal termination, and is referred to as DSL Access DSL signal termination, and is referred to as a DSL Access
Multiplexer (DSLAM). Multiplexer (DSLAM).
Network Access Server (NAS): Network element which aggregates 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 network. It is also referred to as a Broadband Network Gateway
(BNG) or Broadband Remote Access Server (BRAS). (BNG) or Broadband Remote Access Server (BRAS).
Home Gateway (HGW): Network element that connects subscriber devices Home Gateway (HGW): Network element that connects subscriber devices
to the Access Node and the access network. In the case of DSL, to the Access Node and the access network. In the case of DSL,
the Home Gateway is a DSL network termination that could operate the Home Gateway is a DSL network termination that may operate
either as a layer 2 bridge or as a layer 3 router. In the latter either as a layer 2 bridge or as a layer 3 router. In the latter
case, such a device is also referred to as a Routing Gateway (RG). case, such a device is also referred to as a Routing Gateway (RG).
Net Data Rate: portion of the total data rate of the DSL line that 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 can be used to transmit actual user information (e.g. ATM cells
of 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.
DSL line (synch) rate: the total data rate of the DSL line, DSL line (synch) rate: the total data rate of the DSL line,
skipping to change at page 7, line 21 skipping to change at page 7, line 21
xDSL lines into a single bi-directional logical link, henceforth xDSL lines into a single bi-directional logical link, henceforth
referred to in this draft as "DSL bonded circuit". DSL "multi- referred to in this draft as "DSL bonded circuit". DSL "multi-
pair" bonding allows an operator to combine the data rates on two pair" bonding allows an operator to combine the data rates on two
or more copper pairs, and deliver the aggregate data rate to a or more copper pairs, and deliver the aggregate data rate to a
single customer. ITU-T recommendations G.998.1 and G.998.2 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.
Type-Length-Value (TLV): a data structure consisting of a sixteen- Type-Length-Value (TLV): a data structure consisting of a sixteen-
bit type field, a sixteen-bit length field, and a variable-length bit type field, a sixteen-bit length field, and a variable-length
value field padded to the nearest 32-bit word boundary, as value field padded to the nearest 32-bit word boundary, as
described in Section 4.4.2. The value field of a TLV can contain described in Section 4.6.2. The value field of a TLV can contain
other TLVs. An IANA registry is maintained for values of the ANCP other TLVs. An IANA registry is maintained for values of the ANCP
TLV Type field. TLV Type field.
ANCP Protocol Capability: A detailed specification of ANCP messages, ANCP Protocol Capability: A detailed specification of ANCP messages,
message content, and procedures required to implement a specific message content, and procedures required to implement a specific
use case or set of use cases. ANCP capabilities may be specific use case or set of use cases. ANCP capabilities may be specific
to one access technology or technology independent. The set of to one access technology or technology independent. The set of
capabilities applicable to a given ANCP session are negotiated capabilities applicable to a given ANCP session are negotiated
during session startup. during session startup.
ANCP session (adjacency): A session between a NAS and an Access ANCP session (also called an adjacency): A session between a NAS and
Node, beginning with the initiation of the transport connection by an Access Node, beginning with the initiation of the transport
the AN, passing through adjacency negotiation, discovery and connection by the AN, passing through adjacency negotiation,
provisioning stages, and continuing with service control and discovery and provisioning stages, and continuing with service
possible OAM operations until the transport connection is control and possible OAM operations until the transport connection
terminated. There may be more than one ANCP session active is terminated. There may be more than one ANCP session active
between the NAS and a given AN due to partitioning. between the NAS and a given AN due to partitioning.
3. Broadband Access Aggregation 3. Broadband Access Aggregation
3.1. ATM-based broadband aggregation 3.1. ATM-based broadband aggregation
The end to end DSL network consists of network and application The end to end DSL network consists of network service provider (NSP)
service provider networks (NSP and ASP networks), regional/access and application service provider (ASP) networks, regional/access
network, and customer premises network. Figure 1 shows ATM broadband network, and customer premises network. Figure 1 shows ATM broadband
access network components. access 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 shown in Figure 1. Its Access Server (NAS), and the access network as shown in Figure 1.
primary function is to provide end-to-end transport between the
customer premises and the NSP or ASP. The Access Node terminates the Its primary function is to provide end-to-end transport between the
DSL signal. It may be in the form of a DSLAM in the central office, customer premises and the NSP or ASP.
or a remote DSLAM, or a Remote Access Multiplexer (RAM). The access
node is the first point in the network where traffic on multiple DSL The Access Node terminates the DSL signal. It may be in the form of
lines will be aggregated onto a single network. a DSLAM in the central office, or a remote DSLAM, or a Remote Access
Multiplexer (RAM). The Access Node is the first point in the network
where traffic on multiple DSL lines will be aggregated onto a single
network.
The NAS performs multiple functions in the network. The NAS is the The NAS performs multiple functions in the network. The NAS is the
aggregation point for subscriber traffic. It provides aggregation aggregation point for subscriber traffic. It provides aggregation
capabilities (e.g. IP, PPP, ATM) between the Regional/Access Network capabilities (e.g. IP, PPP, ATM) between the Regional/Access Network
and the NSP or ASP. These include traditional ATM-based offerings and the NSP or ASP. These include traditional ATM-based offerings
and newer, more native IP-based services. This includes support for and newer, more native IP-based services. This includes support for
Point-to-Point Protocol over ATM (PPPoA) and PPP over Ethernet Point-to-Point Protocol over ATM (PPPoA) and PPP over Ethernet
(PPPoE), as well as direct IP services encapsulated over an (PPPoE), as well as direct IP services encapsulated over an
appropriate layer 2 transport. appropriate layer 2 transport.
Beyond aggregation, the NAS is also the injection point for policy Beyond aggregation, the NAS is also the injection point for policy
management and IP QoS in the Regional/Access Networks. To allow IP management and IP QoS in the regional/access networks. To allow IP
QoS support over an existing non-IP-aware layer 2 access network QoS support over an existing non-IP-aware layer 2 access network
without using multiple layer 2 QoS classes, a mechanism based on without using multiple layer 2 QoS classes, a mechanism based on
hierarchical scheduling is used. This mechanism, defined in hierarchical scheduling is used. This mechanism, defined in
[TR_059], preserves IP QoS over the ATM network between the NAS and [TR_059], preserves IP QoS over the ATM network between the NAS and
the routing gateway (RG) at the edge of the subscriber network, by the routing gateway (RG) at the edge of the subscriber network, by
carefully controlling downstream traffic in the NAS, so that carefully controlling downstream traffic in the NAS, so that
significant queuing and congestion does not occur further down the significant queuing and congestion does not occur further down the
ATM network. This is achieved by using a diffserv-aware hierarchical ATM network. This is achieved by using a diffserv-aware hierarchical
scheduler in the NAS that will account for downstream trunk scheduler in the NAS that will account for downstream trunk
bandwidths and DSL synch rates. bandwidths and DSL synch rates.
[RFC5851] provides detailed definition and functions of each network [RFC5851] provides detailed definition and functions of each network
element in the broadband reference architecture. element in the broadband reference architecture.
Access Customer Access Customer
<--- Aggregation --> <------- Premises -------> <--- Aggregation --> <------- Premises ------->
Network Network Network Network
+------------------+ +--------------------------+ +------------------+ +--------------------------+
+---------+ +---+ | +-----+ +------+ |-|+-----+ +---+ +---------+ | +---------+ +---+ | +-----+ +------+ | |+-----+ +---+ +---------+ |
NSP| | +-|NAS|-| |ATM |-|Access| | ||DSL |-|HGW|-|Subscriber|| NSP| | +-|NAS|-| |ATM |-|Access| --||DSL |-|HGW|-|Subscriber||
---+ Regional| | +---+ | +-----+ | Node | | ||Modem| +---+ |Devices || ---+ Regional| | +---+ | +-----+ | Node | | ||Modem| +---+ |Devices ||
|Broadband| | +---+ | +------+ | |+-----+ +----------+| |Broadband| | +---+ | +------+ | |+-----+ +----------+|
ASP|Network |-+-|NAS| +--------------|---+ +--------------------------+ ASP|Network |-+-|NAS| +--------------|---+ +--------------------------+
---+ | | +---+ | +--------------------------+ ---+ | | +---+ | +--------------------------+
| | | +---+ | |+-----+ +---+ +----------+| | | | +---+ | |+-----+ +---+ +----------+|
+---------+ +-|NAS| +-----|| DSL |-|HGW|-|Subscriber|| +---------+ +-|NAS| +-----|| DSL |-|HGW|-|Subscriber||
+---+ ||Modem| +---+ |Devices || +---+ ||Modem| +---+ |Devices ||
|+-----+ +----------+| |+-----+ +----------+|
+--------------------------+ +--------------------------+
HGW : Home Gateway HGW : Home Gateway
skipping to change at page 9, line 35 skipping to change at page 9, line 35
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 standard virtualization mechanism in the Ethernet aggregation
network. The aggregation devices are "provider edge bridges" defined network. The aggregation devices are "provider edge bridges" defined
in IEEE 802.ad. Stacked VLAN tags provide one possible way to create in IEEE 802.ad.
equivalent of "virtual paths" and "virtual circuits" in the
aggregation network. The "outer" vlan could be used to create a form Stacked VLAN tags provide one possible way to create equivalent of
of "virtual path" between a given DSLAM and a given NAS. And "inner" "virtual paths" and "virtual circuits" in the aggregation network.
VLAN tags to create a form of "virtual circuit" on a per DSL line The "outer" vlan can be used to create a form of "virtual path"
basis. This is 1:1 VLAN allocation model. An alternative model is between a given DSLAM and a given NAS. "Inner" VLAN tags create a
to bridge sessions from multiple subscribers behind a DSLAM into a form of "virtual circuit" on a per DSL line basis. This is the 1:1
single VLAN in the aggregation network. This is N:1 VLAN allocation VLAN allocation model. An alternative model is to bridge sessions
model. Architectural and topological models of an Ethernet from multiple subscribers behind a DSLAM into a single VLAN in the
aggregation network in context of DSL aggregation are defined in aggregation network. This is the N:1 VLAN allocation model.
[TR_101] Architectural and topological models of an Ethernet aggregation
network in context of DSL aggregation are defined in [TR_101].
4. Access Node Control Protocol -- General Aspects 4. Access Node Control Protocol -- General Aspects
This section specifies aspects of the Access Node Control Protocol This section specifies aspects of the Access Node Control Protocol
(ANCP) that are generally applicable. As indicated above, ANCP is (ANCP) that are generally applicable. As indicated above, ANCP is
derived from GSMPv3 [RFC3292]. Reference to [RFC3292] is made where derived from GSMPv3 [RFC3292]. Reference to [RFC3292] is made where
this is applicable, but ANCP introduces numerous modifications and this is applicable, but ANCP introduces numerous modifications and
extensions to the basic GSMPv3 protocol. Moreover, ANCP uses only a extensions to the basic GSMPv3 protocol. Moreover, ANCP uses only a
subset of the messages, message contents, and procedures defined for subset of the messages, message contents, and procedures defined for
GSMPv3. GSMPv3.
The following are the only GSMPv3 [RFC3292] messages that are The following are the only GSMPv3 [RFC3292] messages that are
currently used by ANCP. currently used by ANCP.
Event Messages Event Messages
* Port UP Message * Port UP Message
* Port DOWN Message * Port DOWN Message
These messages are used by the ANCP topology discovery capability. These messages are used by the ANCP "DSL topology discovery"
capability.
Port Management Messages These messages are used by the ANCP "line Port Management Messages These messages are used by the ANCP "DSL
configuration" and ANCP "line testing" capabilities. line configuration" and ANCP "DSL line testing" capabilities.
Adjacency Protocol Messages These messages are used to bring up a Adjacency Protocol Messages These messages are used to bring up a
protocol adjacency between a NAS and an AN. protocol adjacency between a NAS and an AN.
ANCP modifies and extends some basic GSMPv3 procedures. These ANCP modifies and extends some 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 are This mechanism and corresponding adjacency message extensions are
defined in section Section 4.3. defined in section Section 4.5.
o The TCP connection establishment procedure in ANCP deviates o The TCP connection establishment procedure in ANCP deviates
slightly from connection establishment in GSMPv3 as specified in slightly from connection establishment in GSMPv3 as specified in
[RFC3293]. This is described in section Section 4.2. [RFC3293]. This is described in section Section 4.2.
o ANCP adds content to GSMPv3 messages in the form of additional o ANCP adds content to GSMPv3 messages in the form of additional
fixed fields and Type-Length-Value (TLV) structures. TLVs also fixed fields and Type-Length-Value (TLV) structures. TLVs also
provide flexibility to both GSMPv3 and ANCP-specific messages provide flexibility to both GSMPv3 and ANCP-specific messages
because their order and whether or not specific TLVs are present because their order in the message and whether or not specific
can vary from one message instance to the next. TLVs are present can vary from one message instance to the next.
4.1. Protocol Version 4.1. Protocol Version
GSMPv3 messages contain an 8-bit protocol version field. As GSMPv3 messages contain an 8-bit protocol version field. As
described below, ANCP subdivides this into two 4-bit sub-fields, for described below, ANCP subdivides this into two 4-bit sub-fields, for
version and sub-version. Implementations of this version of the ANCP version and sub-version. Implementations of this version of the ANCP
specification MUST set the version sub-field to 3 and the sub-version specification MUST set the version sub-field to 3 and the sub-version
sub-field to 1. That is, the hexadecimal representation of the value sub-field to 1. That is, the hexadecimal representation of the value
of the complete protocol version field MUST be 0x31. of the complete protocol version field MUST be 0x31.
skipping to change at page 12, line 6 skipping to change at page 12, line 10
Figure 2: Encapsulation of ANCP Messages Over TCP/IP Figure 2: Encapsulation of ANCP Messages Over TCP/IP
The fields of the encapsulating header are as follows: The fields of the encapsulating header are as follows:
Identifier: This 2-byte field identifies a GSMP or ANCP message. Identifier: This 2-byte field identifies a GSMP or ANCP message.
The type code for GSMP and ANCP messages is 0x880C (i.e., the same The type code for GSMP and ANCP messages is 0x880C (i.e., the same
as GSMP's Ethertype). as GSMP's Ethertype).
Length: This 2-byte unsigned integer indicates the total length of Length: This 2-byte unsigned integer indicates the total length of
the ANCP message only. It does not include the 4-byte the ANCP message. It does not include the 4-byte encapsulating
encapsulating header. header.
The Access Node MUST initiate the TCP session to the NAS. This is The Access Node MUST initiate the TCP session to the NAS. This is a
necessary to avoid static provisioning on the NAS for all the ANs deviation from [RFC3293], which requires the controller to initiate
that are being served by the NAS. It is easier to configure a given the TCP connection to the switch.
AN with the single IP address of the NAS that serves the AN. This is
a deviation from [RFC3293], which indicates that the controller This is necessary to avoid static provisioning on the NAS for all
initiates the TCP connection to the switch. the ANs that are being served by the NAS. It is easier to
configure a given AN with the single IP address of the NAS that
serves the AN.
The NAS MUST listen for incoming connections from the Access Nodes. The NAS MUST listen for incoming connections from the Access Nodes.
Port 6068 is used for TCP connection. Port 6068 is used for TCP connection.
In the event of an ANCP transport protocol failure, all pending ANCP In the event of an ANCP transport protocol failure, all pending ANCP
messages destined to the disconnected recipient SHOULD be discarded messages destined to the disconnected recipient SHOULD be discarded
until the transport is re-established. until the transport connection is re-established.
4.3. Use of the GSMPv3 Adjacency Protocol 4.3. Encoding of Text Fields
In ANCP, all text fields use UTF-8 encoding [RFC3629]. Note that US
ASCII characters have the same representation when coded as UTF-8 as
they do when coded according to [US_ASCII].
4.4. Treatment of Reserved and Unused Fields
ANCP messages contain a number of fields that are unused or reserved.
Some fields are always unused (typically because they were inherited
from GSMPv3 but are not useful in the ANCP context. Others are
unused in the current specification, but are provided for flexibility
in future extensions to ANCP. Both reserved and unused fields MUST
be set to zeroes by the sender and MUST be ignored by the receiver.
Unused bits in a flag field are shown in figures as 'x'. The above
requirement (sender set to zero, receiver ignore) applies to such
unused bits.
4.5. Use of the GSMPv3 Adjacency Protocol
Section 11 of [RFC3292] defines the GSMPv3 adjacency protocol. ANCP Section 11 of [RFC3292] defines the GSMPv3 adjacency protocol. ANCP
reuses the GSMPv3 adjacency protocol to synchronize the NAS and reuses the GSMPv3 adjacency protocol to synchronize the NAS and
Access Nodes and maintain the ANCP session. After the TCP connection Access Nodes and maintain the ANCP session. After the TCP connection
is established, adjacency protocol messages MUST be exchanged as is established, adjacency protocol messages MUST be exchanged as
specified in Section 11 of [RFC3292], subject to the additional specified in Section 11 of [RFC3292], subject to the additional
specifications of this section. ANCP messages other than adjacency specifications of this section. ANCP messages other than adjacency
protocol messages MUST NOT be sent until the adjacency protocol has protocol messages MUST NOT be sent until the adjacency protocol has
achieved synchronization. achieved synchronization.
4.3.1. ANCP Adjacency Message Format 4.5.1. ANCP Adjacency Message Format
The GSMPv3 adjacency message format defined in Section 11 of The GSMPv3 adjacency message format defined in Section 11 of
[RFC3292] is modified and extended for ANCP as shown in Figure 3 [RFC3292] is modified and extended for ANCP as shown in Figure 3
below. The 8-bit "version" field in the GSMPv3 adjacency protocol below. The 8-bit "version" field in the GSMPv3 adjacency protocol
messages is modified to carry the ANCP version (four bits) and sub- messages is modified to carry the ANCP version (four bits) and sub-
version (four bits). See Section 4.1 for the values to set for version (four bits). See Section 4.1 for the values to set for
version and sub-version for the present version of this version and sub-version for the present version of this
specification. In addition to the modification of the version field, specification. In addition to the modification of the version field,
ANCP adds several new fields. These are described below the figure. ANCP adds several new fields. These are described below the figure.
skipping to change at page 13, line 24 skipping to change at page 13, line 40
| Receiver Name | | Receiver Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Port | | Sender Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Port | | Receiver Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PType | PFlag | Sender Instance | | PType | PFlag | Sender Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Receiver Instance | | Partition ID | Receiver Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tech Type | # of Caps | Total Length | | Reserved | # of Caps | Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Capability Fields ~ ~ Capability Fields ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 Figure 3
[Editor's Note: it seems likely this text and Section 4.3 will have
to be modified to provide for multiple capability sets (for different
Tech Type values).]
The fields added by ANCP are as follows: The fields added by ANCP are as follows:
Tech Type: indicates the technology to which the capability Reserved: reserved for use by a future version of this
extension applies. An IANA registry is maintained for possible specification.
values of the Tech Type field. This specification assigns the
Tech Type value 0x05 to DSL. Note: this was the Tech Type field in pre-standard versions of
ANCP, but was determined to be unnecessary.
# of Caps: indicates the number of capability fields that follow. # of Caps: indicates the number of capability fields that follow.
Total Length: indicates the total number of bytes occupied by the Total Length: indicates the total number of bytes occupied by the
capability fields that follow. capability fields that follow.
Capability Fields: Each capability field indicates one ANCP Capability Fields: Each capability field indicates one ANCP
capability supported by the sender of the adjacency message. capability supported by the sender of the adjacency message.
Negotiation of a common set of capabilities to be supported within Negotiation of a common set of capabilities to be supported within
the ANCP session is described in Section 4.3.2. The detailed the ANCP session is described in Section 4.5.2. The detailed
format of a capability field is described below. format of a capability field is described below.
The format of a capability field is shown in Figure 4: The format of a capability field is shown in Figure 4:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capability Type | Capability Length | | Capability Type | Capability Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 14, line 48 skipping to change at page 15, line 11
capability includes no capability data, the Capability Data sub- capability includes no capability data, the Capability Data sub-
field is absent (has zero length). Otherwise, the Capability Data field is absent (has zero length). Otherwise, the Capability Data
sub-field MUST be padded with zeroes as required to terminate on a sub-field MUST be padded with zeroes as required to terminate on a
4-byte word boundary. The possibility of specifying capability 4-byte word boundary. The possibility of specifying capability
data provides the flexibility to advertise more than the mere data provides the flexibility to advertise more than the mere
presence or absence of a capability if needed. presence or absence of a capability if needed.
The following capabilities are defined for ANCP as applied to DSL The following capabilities are defined for ANCP as applied to DSL
access: access:
1. Capability Type : DSL Topology Discovery = 0x01 o Capability Type : DSL Topology Discovery = 0x01
Length (in bytes) : 0
Capability Data : NULL Access technology: DSL
For the detailed protocol specification of this capability see Length (in bytes) : 0
Section 5.2.
2. Capability Type : DSL Line Configuration = 0x02 Capability Data : NULL
Length (in bytes) : 0 For the detailed protocol specification of this capability see
Section 5.2.
Capability Data : NULL o Capability Type : DSL Line Configuration = 0x02
For the detailed protocol specification of this capability see Access technology: DSL
Section 5.3.
3. Capability Type : DSL Line Testing = 0x04 Length (in bytes) : 0
Length (in bytes) : 0 Capability Data : NULL
Capability Data : NULL For the detailed protocol specification of this capability see
Section 5.3.
For the detailed protocol specification of this capability see o Capability Type : DSL Line Testing = 0x04
Section 5.4.
4.3.2. ANCP Adjacency Procedures Access technology: DSL
Length (in bytes) : 0
Capability Data : NULL
For the detailed protocol specification of this capability see
Section 5.4.
4.5.2. ANCP Adjacency Procedures
The NAS MUST set the M-flag in the SYN message (signifying it is the The NAS MUST 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) MUST be exchanged. The default for the ACK messages (type ACK) MUST be exchanged. The default for the ACK
interval to be advertised in the adjacency messages is 10 sec for interval to be advertised in the adjacency messages is 10 seconds for
ANCP. The actual value SHOULD be configurable and is an ANCP. The actual value SHOULD be configurable and is an
implementation choice. It is RECOMMENDED that both ends specify the implementation choice. It is RECOMMENDED that both ends specify the
same timer value; to achieve this, each end SHOULD compare the timer same timer value; to achieve this, each end SHOULD compare the timer
value in the first adjacency message it receives with its own value in the first adjacency message it receives with its own
preferred value and agree to use the higher of the two values. That preferred value and agree to use the higher of the two values. That
is, the node that receives a higher timer value than its own SHOULD is, the node that receives a higher timer value than its own SHOULD
reply in its subsequent adjacency messages (such as SYNACK, ACK) with reply in its subsequent adjacency messages (such as SYNACK, ACK) with
the higher timer value. the higher timer value.
In the adjacency protocol the version and the sub-version fields are In the adjacency protocol the version and sub-version fields are used
used for version negotiation. The version negotiation is performed for version negotiation. The version negotiation is performed before
before synchronisation is achieved. In a SYN message the version/ synchronisation is achieved. In a SYN message the version/
sub-version fields always contain the highest version understood by sub-version fields always contain the highest version understood by
the sender. A receiver receiving a SYN message with a version/ the sender. A receiver receiving a SYN message with a version/
sub-version higher than it understands MUST silently discard that sub-version higher than it understands MUST silently discard that
message. A receiver receiving a SYN message with a version/ message. A receiver receiving a SYN message with a version/
sub-version within the range of versions that it understands MUST sub-version within the range of versions that it understands MUST
reply with a SYNACK with the version/sub- version from the received reply with a SYNACK with the version/sub- version from the received
SYN in its ANCP version/sub-version fields. This defines the SYN in its ANCP version/sub-version fields. This defines the
version/sub-version of the ANCP protocol to be used while the version/sub-version of the ANCP protocol to be used while the
adjacency remains synchronised. All other ANCP messages within the adjacency remains synchronised. All other ANCP messages within the
session MUST use the agreed version in the version/sub-version session MUST use the agreed version in the version/sub-version
fields. fields.
The semantics and suggested values for Code, "Sender Name", "Receiver The semantics and suggested values for the Code, Sender Name,
Name", "Sender Instance", and "Receiver Instance" fields are as Receiver Name, Sender Instance, and Receiver Instance fields are as
defined in Section 11 of [RFC3292]. The "Sender Port", and "Receiver defined in Section 11 of [RFC3292]. The Sender Port, and Receiver
Port" SHOULD be set to 0 by both ends. The pType field SHOULD be set Port SHOULD be set to 0 by both ends. The pType field SHOULD be set
to 0 (No Partition). The pFlag SHOULD be set to 1 (New Adjacency). to 0 (No Partition). The pFlag SHOULD be set to 1 (New Adjacency).
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 MUST continue to listen for new connection SHOULD be closed. The NAS MUST continue to listen for new
connection requests. The AN MUST try to re-establish the TCP connection requests. The AN MUST try to re-establish the TCP
connection and both sides MUST attempt to re-establish the adjacency. connection and both sides MUST 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 document.
Both the NAS and the Access Node MUST advertise supported Both the NAS and the Access Node MUST advertise supported
capabilities in the adjacency messages they send. If a received capabilities in the adjacency messages they send. The same message
adjacency message indicates no support for a capability that is MAY advertise capabilities for any mixture of access technologies.
supported by the receiving device, it MUST turn off the capability If a received adjacency message indicates no support for a capability
locally and MUST send an updated adjacency message with the that is supported by the receiving device, it MUST turn off the
corresponding capability field omitted to match the received capability locally and MUST send an updated adjacency message with
the corresponding capability field omitted to match the received
capability set. This process will eventually result in both sides capability set. This process will eventually result in both sides
agreeing on the minimal set of supported capabilities. The adjacency agreeing on the maximal common set of supported capabilities. The
MUST NOT come up unless the capabilities advertised by the controller adjacency MUST NOT come up if that common set is empty.
and the controlled device match.
After initial synchronization, if at any time a capability mismatch After initial synchronization, if at any time a capability mismatch
is detected, the adjacency MUST be brought down (RSTACK MUST be is detected, the adjacency MUST be brought down (RSTACK MUST be
generated by the device detecting the mismatch), and synchronization generated by the device detecting the mismatch), and synchronization
MUST be re-attempted. MUST be re-attempted.
4.4. ANCP General Message Formats 4.6. ANCP General Message Formats
This section describes the general format of ANCP messages other than This section describes the general format of ANCP messages other than
the adjacency messages. the adjacency messages.
The GSMPv3 general message format, used by all GSMP messages other The GSMPv3 general message format, used by all GSMP messages other
than adjacency protocol messages, is defined in Section 3.1.1 of than adjacency protocol messages, is defined in Section 3.1.1 of
GSMPv3 [RFC3292]. ANCP modifies this base GSMPv3 message format as GSMPv3 [RFC3292]. ANCP modifies this base GSMPv3 message format as
shown in Figure 5. shown in Figure 5.
0 1 2 3 0 1 2 3
skipping to change at page 17, line 23 skipping to change at page 17, line 38
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length | |I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Message Payload ~ ~ Message Payload ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: ANCP General Message Format Figure 5: ANCP General Message Format
4.4.1. The ANCP Message Header 4.6.1. The ANCP Message Header
The immediately visible differences from GSMPv3 are the subdivision The immediately visible differences from GSMPv3 are the subdivision
of the Version field into version and sub-version, and the of the Version field into version and sub-version, and the
reallocation of space between Result and Code to enlarge the range reallocation of space between Result and Code to enlarge the range
for Code. The 8-bit version field in the base GSMPv3 message header for Code. 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- is split into two 4 bit fields for carrying the version and a sub-
version of the ANCP protocol. The Result field in the message header version of the ANCP protocol. The Result field in the message header
has been modified to be 4 bits long, and the Code field to be 12 bits has been modified to be 4 bits long, and the Code field to be 12 bits
long. long.
A complete explanation of the header fields is as follows: A complete explanation of the header fields is as follows:
Version and Sub-version: The version of the ANCP protocol that was Version and Sub-version: The version of the ANCP protocol that was
agreed for the session during adjacency negotiation. For the agreed for the session during adjacency negotiation. For the
values that must be placed into these fields, see Section 4.1. values that must be placed into these fields, see Section 4.1.
Message Type: The ANCP message type. Message type values are Message Type: The ANCP message type. Message type values are
registered in a common GSMPv3/ANCP IANA registry. registered in a common GSMPv3/ANCP IANA registry.
Result: The Result field derived from GSMPv3 [RFC3292]. Ignore Result: The Result field is derived from GSMPv3 [RFC3292]. Ignore
(0x0) is a new value added by ANCP. The remaining Result values (0x0) is a new value added by ANCP. The remaining Result values
below are a subset of those defined for GSMPv3. GSMPv3 expected below are a subset of those defined for GSMPv3. GSMPv3 expected
the sender of a request to choose between NAck (0x1) and AckAll the sender of a request to choose between NAck (0x1) and AckAll
(0x2) according to its needs. ANCP specifies what Result value (0x2) according to its needs. ANCP specifies what Result value
each request should have. Responses indicate either Success (0x3) each request should have. Responses indicate either Success (0x3)
or Failure (0x4) as the case may be. or Failure (0x4) as the case may be.
Ignore: Res = 0x0 - Ignore this field on receipt and follow the Ignore: Res = 0x0 - Ignore this field on receipt and follow the
procedures specified for the received message type. procedures specified for the received message type.
skipping to change at page 19, line 36 skipping to change at page 19, line 51
84 TLV or value not supported by negotiated capability set 84 TLV or value not supported by negotiated capability set
ANCP extensions defining new code values SHOULD use the range 256 ANCP extensions defining new code values SHOULD use the range 256
(0x100) through 511 (0x1FF) for this purpose. (0x100) through 511 (0x1FF) for this purpose.
The range of values from 256 to 4095 is reserved for IETF use. The range of values from 256 to 4095 is reserved for IETF use.
Partition ID: This field is a 8 bit number which signifies a Partition ID: This field is a 8 bit number which signifies a
partition on the AN. partition on the AN.
The AN and NAS MAY agree on the partition ID using one of the The AN and NAS may agree on the partition ID using one of the
following possible options: following possible options:
1 - The partition ID could be configured on the AN and learned by 1 - The partition ID may be configured on the AN and learned by
the NAS in the adjacency message; the NAS in the adjacency message;
2 - The partition ID could be statically configured on the NAS as 2 - The partition ID may be statically configured on the NAS as
part of configuring the neighbor information. part of configuring the neighbor information.
Transaction ID: 24-bit field set by the sender of a request message Transaction ID: 24-bit field set by the sender of a request message
to associate a response message with the original request message. to associate a response message with the original request message.
Unless otherwise specified for a given message type, the Unless otherwise specified for a given message type, the
Transaction ID in request messages MUST be set to a value in the Transaction ID in request messages MUST be set to a value in the
range (1, 2^24 - 1). When used in this manner, the Transaction ID range (1, 2^24 - 1). When used in this manner, the Transaction ID
sequencing MUST be maintained independently for each ANCP sequencing MUST be maintained independently for each ANCP
adjacency and per message type. Furthermore, it SHOULD be adjacency and per message type. Furthermore, it SHOULD be
incremented linearly for each new message of the given type, incremented linearly for each new message of the given type,
skipping to change at page 20, line 21 skipping to change at page 20, line 36
responses is that the value of the Transaction ID MUST be copied responses is that the value of the Transaction ID MUST be copied
from the corresponding request message. from the corresponding request message.
I flag and SubMessage Number: An ANCP implementation SHOULD set the I flag and SubMessage Number: An ANCP implementation SHOULD set the
I Flag and subMessage Number fields to 1 to signify no I Flag and subMessage Number fields to 1 to signify no
fragmentation. fragmentation.
Length: Length of the ANCP message including its header fields and Length: Length of the ANCP message including its header fields and
defined ANCP message body. defined ANCP message body.
4.4.2. The ANCP Message Body 4.6.2. The ANCP Message Body
The detailed contents of the message payload portion of a given ANCP The detailed contents of the message payload portion of a given ANCP
message may vary with the capability in the context of which it is message may vary with the capability in the context of which it is
being used. However, the general format consists of zero or more being used. However, the general format consists of zero or more
fixed fields, followed by a variable amount of data in the form of fixed fields, followed by a variable amount of data in the form of
Type-Length-Value (TLV) data structures. Type-Length-Value (TLV) data structures.
The general format of a TLV is shown in Figure 6: The general format of a TLV is shown in Figure 6:
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
skipping to change at page 21, line 5 skipping to change at page 21, line 23
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: General TLV Format Figure 6: General TLV Format
The fields of a TLV are defined as follows: The fields of a TLV are defined as follows:
Type: The TLV Type is a 16-bit unsigned value identifying the TLV Type: The TLV Type is a 16-bit unsigned value identifying the TLV
type and nature of its contents. An IANA registry has been type and nature of its contents. An IANA registry has been
established for ANCP TLV Type codes. established for ANCP TLV Type codes.
Length The number of bytes of data in the Value field of the TLV, Length: The number of bytes of data in the Value field of the TLV,
excluding any padding required to bring this TLV to a 4-byte word excluding any padding required to bring this TLV to a 4-byte word
boundary (see "Value" below). If a TLV contains other TLVs, any boundary (see "Value" below). If a TLV contains other TLVs, any
padding in the contained TLVs MUST be included in the value of padding in the contained TLVs MUST be included in the value of
Length. Length.
If the TLV contains another TLV followed by other data, the If the TLV contains another TLV followed by other data, the
outer TLV will not be properly parsable unless Length is set as outer TLV will not be properly parsable unless Length is set as
indicated; if the interior padding is omitted from Length, as indicated; if the interior padding is omitted from Length, as
many bytes of data at the end of the outer TLV will be missed. many bytes of data at the end of the outer TLV will be missed.
If the outer TLV contains another TLV as its final field it If the outer TLV contains another TLV as its final field it
skipping to change at page 21, line 37 skipping to change at page 22, line 7
in each TLV MUST be padded with zeroes as required to align with a in each TLV MUST be padded with zeroes as required to align with a
4-byte word boundary. The Value field of a TLV may include fixed 4-byte word boundary. The Value field of a TLV may include fixed
fields and/or other TLVs. fields and/or other TLVs.
Unless otherwise specified, TLVs MAY be added to a message in any Unless otherwise specified, TLVs MAY be added to a message in any
order. If the recipient of a message does not understand a order. If the recipient of a message does not understand a
particular TLV, it MUST silently ignore it. particular TLV, it MUST silently ignore it.
A number of TLVs are specified in the remainder of this document. A number of TLVs are specified in the remainder of this document.
4.4.2.1. Additional Conventions and General Requirements
Any field in a message that is inherited from GSMPv3 and is unused in
ANCP and any field that is explicitly shown as Reserved MUST be set
to all zeroes by the sender and MUST be ignored by the receiver.
Such fields could be assigned a specific purpose in a future
version of this specification.
Unused bits in a flag field are shown in figures as 'x'. The above
requirement (sender set to zero, receiver ignore) applies to such
unused bits.
5. ANCP Capabilities For Digital Subscriber Lines (DSL) 5. ANCP Capabilities For Digital Subscriber Lines (DSL)
5.1. Overview 5.1. Overview
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. Specifications such as [TR_059], [TR_058], Next Generation Networks. Specifications such as [TR_059], [TR_058],
and [TR_092] describe possible architectures for these access and [TR_092] describe possible architectures for these access
networks. The scope of these specifications includes the delivery of networks. The scope of these specifications includes the delivery of
voice, video, and data services. voice, video, and data services.
skipping to change at page 22, line 36 skipping to change at page 22, line 38
capabilities. These additional capabilities are not specified here, capabilities. These additional capabilities are not specified here,
but may be specified in other documents. but may be specified in other documents.
The DSL capabilities specified in this section are: The DSL capabilities specified in this section are:
DSL Topology Discovery: Dynamic discovery of access topology and DSL DSL Topology Discovery: Dynamic discovery of access topology and DSL
line attributes by the NAS, to support tight QOS control in the line attributes by the NAS, to support tight QOS control in the
access network. access network.
DSL Line Configuration: Pushing subscriber and service data DSL Line Configuration: Pushing subscriber and service data
retrieved by the NAS from an OSS system (e.g. RADIUS server) to retrieved by the NAS from an OSS system (e.g., RADIUS server) to
the Access Nodes, to simplify OSS infrastructure for service the Access Nodes, to simplify OSS infrastructure for service
management. management.
DSL Line Testing: NAS controlled, on-demand access- line test DSL Line Testing: NAS controlled, on-demand access- line test
capability (rudimentary end-to-end OAM). capability (rudimentary end-to-end OAM).
5.1.1. ATM-Specific Considerations 5.1.1. ATM-Specific Considerations
Topology discovery and line configuration involve the DSL line 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-ID discovery and line configuration carry opaque Access-Loop-Circuit-ID
values which have only local significance on the DSLAMs. values which have 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 a UTF-8-encoded
in the ANCP messages. This allows ANCP to be decoupled from the string in the ANCP messages. This allows ANCP to be decoupled from
specifics of the underlying access technology being controlled. On the specifics of the underlying access technology being controlled.
the other hand, this requires a NAS mechanism by which each such On the other hand, this requires a NAS mechanism by which each 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 will typically require local configuration of such IP NAS. This will typically require local configuration of such IP
interfaces, or of the underlying ATM interfaces. interfaces, or of the underlying ATM interfaces.
5.1.2. Ethernet-Specific Considerations 5.1.2. 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
skipping to change at page 23, line 41 skipping to change at page 23, line 44
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 multiple subscribers behind a DSLAM to a single VLAN in the
aggregation network. This is the N:1 model. In this model, or in aggregation network. This is the N:1 model. In this model, or in
the case where user traffic is sent untagged, the Access Node needs the case where user traffic is sent untagged, the Access Node needs
to insert the exact identity of the DSL line in the topology to insert the exact identity of the DSL line in the topology
discovery and line configuration messages, and then have a mechanism discovery and line configuration messages, and then have a mechanism
by which this can be correlated to the context of an aggregation- by which this can be correlated to the context of an aggregation-
network-facing IP interface (for the subscriber) on the NAS. This network-facing IP interface (for the subscriber) on the NAS. This
can either be based on local configuration on the NAS, or on the fact can either be based on local configuration on the NAS, or on the fact
that such DSLAM (Access Node) typically inserts the access loop that a DSLAM (Access Node) typically inserts the access loop circuit
circuit ID in subscriber signaling messages relayed to the NAS (i.e. ID in subscriber signaling messages relayed to the NAS (i.e. DHCP or
DHCP or PPPoE discovery messages). PPPoE discovery messages).
Section 5.2.3.3 defines TLVs to represent the "access loop circuit Section 5.2.3.3 defines TLVs to represent the "access loop circuit
ID". ID".
5.2. ANCP Based DSL Topology Discovery 5.2. ANCP Based DSL Topology Discovery
5.2.1. Goals 5.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
skipping to change at page 24, line 26 skipping to change at page 24, line 29
capacity of the uplink and the image the NAS has of it. capacity of the uplink and the image the NAS has of it.
The following section describes ANCP messages that allow the Access The following section describes ANCP messages that allow the Access
Node (e.g., DSLAM) to communicate access network topology information Node (e.g., DSLAM) to communicate access network topology information
and any corresponding updates to the NAS. and any corresponding updates to the NAS.
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 downstream net data rates, interleaving delay etc. Topology
discovery is specifically important in case the net data rate of the discovery is specifically important when the net data rate of the DSL
DSL line changes over time. The DSL net data rate may be different line changes over time. The DSL net data rate may be different every
every time the DSL modem is turned on. Additionally, during the time time the DSL modem is turned on. Additionally, during the time the
the DSL modem is active, data rate changes can occur due to DSL modem is active, data rate changes can occur due to environmental
environmental conditions (the DSL line can get "out of sync" and can conditions (the DSL line can get "out of sync" and can retrain to a
retrain to a lower value). lower value).
5.2.2. Message Flow 5.2.2. Message Flow
To provide expected service levels, the NAS needs to learn the To provide expected service levels, the NAS needs to learn the
initial attributes of the DSL line before the subscriber can log in initial attributes of the DSL line before the subscriber can log in
and access the services provisioned for the subscription. When a DSL and access the services provisioned for the subscription. When a DSL
line initially comes up or resynchronizes to a different rate, the line initially comes up or resynchronizes to a different rate, the
DSLAM generates and transmits an ANCP Port UP Event message to the DSLAM generates and transmits an ANCP Port UP Event message to the
NAS. The extension field in the message carries the TLVs containing NAS. The extension field in the message carries the TLVs containing
DSL line specific parameters. Upon loss of signal on the DSL line, DSL line specific parameters. Upon loss of signal on the DSL line,
skipping to change at page 25, line 49 skipping to change at page 25, line 49
GSMPv3 [RFC3292] messages of the same name but include capability- GSMPv3 [RFC3292] messages of the same name but include capability-
specific modifications and extensions (Section 5.2.3.2). specific modifications and extensions (Section 5.2.3.2).
o The procedures associated with these messages and their contents o The procedures associated with these messages and their contents
(Section 5.2.3.2.1). (Section 5.2.3.2.1).
o Access-Loop-Circuit-ID TLV; o Access-Loop-Circuit-ID TLV;
o Access-Loop-Remote-Id TLV; o Access-Loop-Remote-Id TLV;
o Access-Aggregation-Circuit-ID-Binary TLV;
o Access-Aggregation-Circuit-ID-ASCII TLV; o Access-Aggregation-Circuit-ID-ASCII TLV;
o Access-Aggregation-Circuit-ID-Binary TLV;
o DSL-Line-Attributes TLV; o DSL-Line-Attributes TLV;
o DSL-Type TLV; o DSL-Type TLV;
o Actual-Net-Data-Upstream TLV; o Actual-Net-Data-Upstream TLV;
o Actual-Net-Data-Rate-Downstream TLV; o Actual-Net-Data-Rate-Downstream TLV;
o Minimum-Net-Data-Rate-Upstream TLV; o Minimum-Net-Data-Rate-Upstream TLV;
skipping to change at page 27, line 37 skipping to change at page 27, line 37
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ TLVs ~ ~ TLVs ~
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Format Of the ANCP Port UP and Port DOWN Event Messages Figure 8: Format Of the ANCP Port UP and Port DOWN Event Messages
For DSL Topology Discovery For DSL Topology Discovery
See Section 4.4 for a description of the ANCP general message header. See Section 4.6 for a description of the ANCP general message header.
The Message Type field MUST be set to 80 for Port UP, 81 for Port The Message Type field MUST be set to 80 for Port UP, 81 for Port
DOWN. The 12 bit Code field MUST be set to 0. The 4 bit Result DOWN. The 12 bit Code field MUST be set to 0. The 4 bit Result
field MUST be set to 0 (signifying Ignore). The 24-bit Transaction field MUST be set to 0 (signifying Ignore). The 24-bit Transaction
Identifier field MUST be set to 0. Other fields in the general Identifier field MUST be set to 0. Other fields in the general
header MUST be set as described in Section 4.4. header MUST be set as described in Section 4.6.
The Port, Port Session Number, and Event Sequence Number fields are The Port, Port Session Number, and Event Sequence Number fields are
not used by the DSL Topology Discovery capability and MUST be not used by the DSL Topology Discovery capability. The Label field
considered reserved. The Label field (including the Stacked Label (including the Stacked Label Indicator and the unused flags at the
Indicator and the unused flags at the start of the Label field), is start of the Label field), is also unused, and MUST be treated as an
also unused, and MUST be treated as a reserved fixed 8-byte field. unused fixed 8-byte field. The handling of unused/reserved fields is
The handling of unused/reserved fields is described in described in Section 4.4.
Section 4.4.2.1.
The remaining message fields are described as follows: The remaining message fields are described as follows:
Extension Flags: The flag bits denoted by 'x' are currently Extension Flags: The flag bits denoted by 'x' are currently
unspecified and reserved. unspecified and reserved.
Message Type: Message Type has the same value as in the general Message Type: Message Type has the same value as in the general
header (i.e., 80 or 81). header (i.e., 80 or 81).
Tech Type: MUST be set to 0x05 (DSL). Tech Type: MUST be set to 0x05 (DSL).
Block Length: unused, reserved. Block Length: unused, see Section 4.4. This field was defined in
early implementations, but limits what follows to 255 bytes, which
is not sufficient.
# of TLVs: the number of TLVs that follow, not counting TLVs # of TLVs: the number of TLVs that follow, not counting TLVs
encapsulated within other TLVs. encapsulated within other TLVs.
Extension Block Length: the total length of the TLVs carried in the Extension Block Length: the total length of the TLVs carried in the
extension block in bytes, including any padding within individual extension block in bytes, including any padding within individual
TLVs. (The existing "Block Length" field inherited from the GSMP TLVs.
message is limited to 255 bytes and is not sufficient).
TLVs: two or more TLVs to identify a DSL line and define its TLVs: two or more TLVs to identify a DSL line and define its
characteristics. characteristics.
5.2.3.2.1. Procedures 5.2.3.2.1. Procedures
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 line change e.g. the line re-trains to a different rate or one or
skipping to change at page 29, line 5 skipping to change at page 29, line 6
the Port UP message received cannot be processed correctly by the NAS 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 (e.g. the message is malformed) the NAS MAY respond with an ANCP
Generic Response message (Section 6.1.3) containing the reason for Generic Response message (Section 6.1.3) containing the reason for
the failure. the failure.
In the case of bonded copper loops to the customer premise (as per In the case of bonded copper loops to the customer premise (as per
the DSL multi-pair bonding described by [G.988.1] and [G.988.2]), the the DSL multi-pair bonding described by [G.988.1] and [G.988.2]), the
DSLAM MUST report the aggregate net data rate and other attributes DSLAM MUST report the aggregate net data rate and other attributes
for the DSL bonded circuit (represented as a single logical port) to for the DSL bonded circuit (represented as a single logical port) to
the NAS in a Port UP message. Any change in the aggregate net data the NAS in a Port UP message. Any change in the aggregate net data
rate of the DSL bonded circuit (due to a change in net data rate of rate of the DSL bonded circuit (due to a change in net data rate or
individual constituent DSL lines or due to change in state of the state of individual constituent DSL lines) MUST be reported by the
individual constituent DSL lines) MUST be reported by the DSLAM to DSLAM to the NAS in a Port UP message. The DSLAM MUST also report
the NAS in a Port UP message. The DSLAM MUST also report the the aggregate state of the DSL bonded circuit to the NAS via Port UP
aggregate state of the DSL bonded circuit to the NAS via Port UP and and Port DOWN messages.
Port DOWN messages.
The definition of TLVs in the next section contains some additional The definition of TLVs in the next section contains some additional
procedural information. procedural information.
5.2.3.3. TLVs For DSL Topology Discovery 5.2.3.3. TLVs For DSL Topology Discovery
The following TLVs are currently defined for DSL Topology Discovery, The following TLVs are currently defined for DSL Topology Discovery,
but may be reused for other capabilities. but may be reused for other capabilities.
5.2.3.3.1. Access-Loop-Circuit-ID TLV 5.2.3.3.1. Access-Loop-Circuit-ID TLV
Name: Access-Loop-Circuit-ID Name: Access-Loop-Circuit-ID
Type: 0x0001 Type: 0x0001
Description: an identifier of the subscriber's connection to the Description: a locally administered human-readable string generated
Access Node (i.e. "local loop"). The local loop can be ATM based by or configured on the Access Node, identifying the corresponding
or Ethernet based. The access loop circuit ID has local access loop logical port. The access loop circuit ID has local
significance at the Access Node. The exact usage on the NAS is significance at the Access Node. The exact usage on the NAS is
beyond the scope of this document. The format used for local loop beyond the scope of this document. The format used for local loop
identification in ANCP messages MUST be identical to what is used identification in ANCP messages MUST be identical to what is used
by the Access Nodes in subscriber signaling messages when the by the Access Nodes in subscriber signaling messages when the
Access Nodes act as signaling relay agents as outlined in Access Nodes act as signaling relay agents as outlined in
[RFC3046] and [TR_101]. [RFC3046] and [TR_101].
For an ATM based local loop the string consists of slot/port and The local loop can be ATM based or Ethernet based. Section 3.9 of
VPI/VCI information corresponding to the subscriber's DSL [TR_101] recommends default formats for either case, with the
connection. Default ABNF [RFC5234] syntax for the string inserted intention that the Access Node automatically generates the
by the Access Node as per [TR_101] is: identifier for a given access line using the default format unless
an identifier has been configured by the operator. The
recommended default format begins with a locally-configured Access
Node identifier. For an ATM based local loop the remainder of the
string consists of slot/port and VPI/VCI information corresponding
to the subscriber's DSL connection. In ABNF notation [RFC5234],
the recommended syntax is:
Access-Node-Identifier " atm " slot "/" port ":" vpi "." vci Access-Node-Identifier SP "atm" SP slot "/" port ":" vpi "."
vci
where the meanings of the terms should be obvious from their where the meanings of the terms should be obvious from their
names. names.
The Access-Node-Identifier uniquely identifies the Access Node in For a local loop which is Ethernet based (and tagged), the
the access network. The slot/port and VPI/VCI uniquely identify remainder of the string consists of slot/port and incoming VLAN
the DSL line on the Access Node. Also, there is one to one tag (if any) describing the access line appearance on the Access
correspondence between DSL line and the VC between the Access Node Node. The syntax of the recommended default format in ABNF
and the NAS. notation is:
For a local loop which is Ethernet based (and tagged), the string
consists of slot/port and VLAN tag corresponding to the
subscriber. Default ABNF syntax for the string inserted by the
Access Node as per [TR_101] is:
Access-Node-Identifier " eth " slot "/" port [":" vlan-id] Access-Node-Identifier SP "eth" SP slot "/" port [":" vlan-id]
This is a mandatory TLV. This is a mandatory TLV.
Length: up to 63 bytes Length: up to 63 bytes
Value: ASCII string Value: ASCII string
5.2.3.3.2. Access-Loop-Remote-Id TLV 5.2.3.3.2. Access-Loop-Remote-Id TLV
Name: Access-Loop-Remote-Id Name: Access-Loop-Remote-Id
Type: 0x0002 Type: 0x0002
Description: This is an optional TLV and contains an identifier to Description: This is an optional TLV. This contains an operator-
uniquely identify a user on a local loop on the Access Node. The configured string that uniquely identifies the user on the
exact usage on the NAS is out of scope of this document. It is associated access line, as described in Section 3.9.2 of [TR_101].
desirable that the format used for the field be similar to what is The exact usage on the NAS is out of scope of this document. It
used by the Access Nodes in subscriber signaling messages when the is desirable that the format used for the field be similar to what
Access Nodes act as signaling relay agents as outlined in is used by the Access Nodes in subscriber signaling messages when
the Access Nodes act as signaling relay agents as outlined in
[RFC3046] and [TR_101]. [RFC3046] and [TR_101].
Length: up to 63 bytes Length: up to 63 bytes
Value: ASCII string Value: ASCII string
5.2.3.3.3. Access-Aggregation-Circuit-ID-Binary TLV 5.2.3.3.3. Access-Aggregation-Circuit-ID-Binary TLV
Name: Access-Aggregation-Circuit-ID-Binary Name: Access-Aggregation-Circuit-ID-Binary
skipping to change at page 31, line 5 skipping to change at page 31, line 6
Description: For ethernet access aggregation, where a per-subscriber Description: For ethernet access aggregation, where a per-subscriber
(stacked) VLAN can be applied (1:1 model defined in [TR_101]), the (stacked) VLAN can be applied (1:1 model defined in [TR_101]), the
VLAN stack provides a convenient way to uniquely identify the DSL VLAN stack provides a convenient way to uniquely identify the DSL
line. The outer VLAN is equivalent to virtual path between a line. The outer VLAN is equivalent to virtual path between a
DSLAM and the NAS and inner VLAN is equivalent to a virtual DSLAM and the NAS and inner VLAN is equivalent to a virtual
circuit on a per DSL line basis. In this scenario, any subscriber circuit on a per DSL line basis. In this scenario, any subscriber
data received by the Access Node and transmitted out the uplink to data received by the Access Node and transmitted out the uplink to
the aggregation network will be tagged with the VLAN stack the aggregation network will be tagged with the VLAN stack
assigned by the Access Node. assigned by the Access Node.
This TLV carries the VLAN tags assigned by the access node in the The Access-Aggregation-Circuit-ID-Binary is illustrated in
ANCP messages. The VLAN tags can uniquely identify the DSL line Figure 9 (below). This TLV carries the VLAN tags assigned by the
being referred to in the ANCP messages, assuming the VLAN tags are access node in the ANCP messages. The VLAN tags can uniquely
not in any way translated in the aggregation network and are identify the DSL line being referred to in the ANCP messages,
unique across physical ports. Each 32 bit unsigned integer (least assuming the VLAN tags are not in any way translated in the
significant bits) contains a 12 bit VLAN identifier (which is part aggregation network and are unique across physical ports. Each 32
of the VLAN tag defined by IEEE 802.1Q). bit unsigned integer contains a 12 bit VLAN identifier (which is
part of the VLAN tag defined by IEEE 802.1Q).
[Editor's Note: should we specify that the upper 20 bits are set
to zero? Which one is inner, which one is outer?]
Also, in case of an ATM aggregation network, where the DSLAM is Also, in case of an ATM aggregation network, where the DSLAM is
directly connected to the NAS (without an intermediate ATM directly connected to the NAS (without an intermediate ATM
switch), the two values can contain VPI and VCI on the DSLAM switch), the two values can contain VPI and VCI on the DSLAM
uplink (and can uniquely identify the DSL line on the DSLAM). uplink (and correspond uniquely to the DSL line on the DSLAM).
This TLV is optional. This TLV is optional.
Length: 8 bytes Length: 8 bytes
Value: two 32 bit unsigned integers Value: two 32 bit unsigned integers
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x0006 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner VLAN tag or VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer VLAN tag or VPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: The Access-Aggregation-Circuit-ID-Binary TLV
5.2.3.3.4. Access-Aggregation-Circuit-ID-ASCII TLV 5.2.3.3.4. Access-Aggregation-Circuit-ID-ASCII TLV
Name: Access-Aggregation-Circuit-ID-ASCII Name: Access-Aggregation-Circuit-ID-ASCII
Type: 0x0003 Type: 0x0003
Description: This field contains information pertaining to an uplink Description: This field contains information pertaining to an uplink
on the Access Node. For Ethernet access aggregation, assuming the on the Access Node. For Ethernet access aggregation, assuming the
Access Node assigns VLAN tags (1:1 model), typical ABNF format for Access Node assigns VLAN tags (1:1 model), typical ABNF format for
the string is: the string is:
Access-Node-Identifier " eth " slot "/" port [":" Access-Node-Identifier SP "eth" SP slot "/" port [":" inner-
inner-vlan-id] [":" outer-vlan-id] vlan-id] [":" outer-vlan-id]
The slot/port corresponds to the ethernet uplink on the Access The slot/port corresponds to the ethernet uplink on the Access
Node towards the NAS. Node towards the NAS.
For an ATM aggregation network, the typical format for the string For an ATM aggregation network, the typical format for the string
is: is:
Access-Node-Identifier " atm " slot "/" port ":" vpi "." vci Access-Node-Identifier SP "atm" SP slot "/" port ":" vpi "."
vci
This TLV allows the NAS to associate the information contained in This TLV allows the NAS to associate the information contained in
the ANCP messages to the DSL line on the Access Node. the ANCP messages to the DSL line on the Access Node.
If the Access Node inserts this string in the ANCP messages, when If the Access Node inserts this string in the ANCP messages, when
referring to local loop characteristics (e.g. DSL line in case of referring to local loop characteristics (e.g. DSL line in case of
a DSLAM), then it should be able to map the information contained a DSLAM), then it should be able to map the information contained
in the string uniquely to the local loop (e.g. DSL line). in the string uniquely to the local loop (e.g. DSL line).
On the NAS, the information contained in this string can be used On the NAS, the information contained in this string can be used
skipping to change at page 39, line 20 skipping to change at page 39, line 36
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
The Access-Loop-Encapsulation TLV is illustrated in Figure 9. The Access-Loop-Encapsulation TLV is illustrated in Figure 10.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x0090 | Length = 3 | | TLV Type = 0x0090 | Length = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data link | Encaps 1 | Encaps 2 | Padding (=0) | | Data link | Encaps 1 | Encaps 2 | Padding (=0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: The Access-Loop-Encapsulation TLV Figure 10: The Access-Loop-Encapsulation TLV
5.3. ANCP based DSL Line Configuration 5.3. ANCP based DSL Line Configuration
5.3.1. Goals 5.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 may query a the previous section (topology discovery), the NAS may 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). Most of such subscriber authorization data (service profiles). Most of such
skipping to change at page 40, line 33 skipping to change at page 41, line 5
profile via ANCP. Alternatively, discrete DSL parameters can also be profile via ANCP. Alternatively, discrete DSL parameters can also be
conveyed by the NAS in ANCP. conveyed by the NAS in ANCP.
5.3.2. Message Flow 5.3.2. Message Flow
Triggered by topology information reporting a new DSL line or Triggered by topology information reporting a new DSL line or
triggered by a subsequent user session establishment (PPP or DHCP), triggered by a subsequent user session establishment (PPP or DHCP),
the NAS may send line configuration information (e.g. reference to a the NAS may send line configuration information (e.g. reference to a
DSL profile) to the DSLAM using ANCP Port Management messages. The DSL profile) to the DSLAM using ANCP Port Management messages. The
NAS may get such line configuration data from a policy server (e.g., NAS may get such line configuration data from a policy server (e.g.,
RADIUS). Figure 10 summarizes the interaction. RADIUS). Figure 11 summarizes the interaction.
+----------+ +-----+ +-----+ +-------+ +-----------+ +----------+ +-----+ +-----+ +-------+ +-----------+
|Radius/AAA|---| NAS |-----| AN |----| Home |----|Subscriber | |Radius/AAA|---| NAS |-----| AN |----| Home |----|Subscriber |
|Policy | +-----+ +-----+ |Gateway| +-----------+ |Policy | +-----+ +-----+ |Gateway| +-----------+
|Server | +-------+ |Server | +-------+
+----------+ +----------+
1.DSL Signal 1.DSL Signal
<----------- <-----------
2. Port UP (Event Message) 2. Port UP (Event Message)
skipping to change at page 41, line 25 skipping to change at page 41, line 27
<---------------- <----------------
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. -------->
Figure 10: Message Flow - ANCP Mapping For Initial Line Configuration Figure 11: 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 11 summarizes change (e.g. triggered by the policy server). Figure 12 summarizes
the interaction. the interaction.
+------+ +-------+ +---------+ +----------+ +------+ +-------+ +---------+ +----------+
| NAS |-----| AN |---| Home |--|Subscriber| | NAS |-----| AN |---| Home |--|Subscriber|
+------+ +-------+ | Gateway | +----------+ +------+ +-------+ | Gateway | +----------+
+---------+ +---------+
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 | OSS etc | 3.Change of
| | Authorization | | Authorization
|Radius AAA | --------> 4.Port Management |Radius AAA | --------> 4.Port Management
| Policy | Message | Policy | Message
| | -------------> | | ------------->
+-----------+ (Updated Line Config - New Profile) +-----------+ (Updated Line Config - New Profile)
Figure 11: Message flow - ANCP Mapping For Updated Line Configuration Figure 12: 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 Section 5.3.3. The line configuration models defined in section Section 5.3.3. The line configuration models
could be viewed as a form of delegation of authorization from the NAS could be viewed as a form of delegation of authorization from the NAS
to the DSLAM. to the DSLAM.
5.3.3. Specification of the ANCP DSL Line Configuration Capability 5.3.3. Specification of the ANCP DSL Line Configuration Capability
5.3.3.1. Protocol Requirements 5.3.3.1. Protocol Requirements
The DSL line configuration capability is assigned capability type The DSL line configuration capability is assigned capability type
skipping to change at page 42, line 38 skipping to change at page 43, line 13
Section 5.2.3.3); Section 5.2.3.3);
o Access-Aggregation-Circuit-ID-ASCII TLV (as defined in o Access-Aggregation-Circuit-ID-ASCII TLV (as defined in
Section 5.2.3.3); Section 5.2.3.3);
o Service-Profile-Name TLV (as defined in Section 5.3.3.4). o Service-Profile-Name TLV (as defined in Section 5.3.3.4).
5.3.3.2. ANCP Port Management Message Format For DSL Line Configuration 5.3.3.2. ANCP Port Management Message Format For DSL Line Configuration
The ANCP Port Management message for DSL line configuration has the The ANCP Port Management message for DSL line configuration has the
format shown in Figure 12. format shown in Figure 13.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP/IP Encapsulating Header (Section 4.2) | | TCP/IP Encapsulating Header (Section 4.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header | | ANCP General Message Header |
+ (Section 4.4) + + (Section 4.4) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 43, line 33 skipping to change at page 43, line 43
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs | Extension Block length (bytes) | | # of TLVs | Extension Block length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ TLVs ~ ~ TLVs ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12 Figure 13
See Section 4.4 for a description of the ANCP general message header. See Section 4.6 for a description of the ANCP general message header.
The Message Type field MUST be set to 32. The 12 bit Code field MUST The Message Type field MUST be set to 32. The 12 bit Code field MUST
be set to 0. The 4 bit Result field MUST be set to either 1 (NAck) be set to 0. The 4 bit Result field MUST be set to either 1 (NAck)
or 2 (AckAll), as determined by policy on the NAS. The 24-bit or 2 (AckAll), as determined by policy on the NAS. The 24-bit
Transaction Identifier field MUST be set to a positive value. Other Transaction Identifier field MUST be set to a positive value. Other
fields in the general header MUST be set as described in Section 4.4. fields in the general header MUST be set as described in Section 4.6.
The Port Management message format defined in [RFC3292] has been The Port Management message format defined in [RFC3292] has been
modified to contain additional data at the end of the message. Also, modified to contain additional data at the end of the message. Also,
the original two byte Function field has been modified to contain one the original two byte Function field has been modified to contain one
byte for the Function field indicating a specific action to be taken byte for the Function field indicating a specific action to be taken
by the recipient of the message, and one byte for X-Function field, by the recipient of the message, and one byte for X-Function field,
which further qualifies the action specified in the Function field. which further qualifies the action specified in the Function field.
Any Function specific data MUST be carried in TLVs in the extension Any Function specific data MUST be carried in TLVs in the extension
block. block.
The Port, Port Session Number, and Event Sequence Number fields are The Port, Port Session Number, and Event Sequence Number fields are
not used by the DSL Line Configuration capability and MUST be not used by the DSL Line Configuration capability and MUST be
considered reserved. The handling of unused/reserved fields is considered reserved. The handling of unused/reserved fields is
described in Section 4.4.2.1. described in Section 4.4.
The remaining message fields are described as follows: The remaining message fields are described as follows:
R Flag: not used by ANCP. R Flag: not used by ANCP.
Additional Port Management flags: the flag bits marked 'x' following Additional Port Management flags: the flag bits marked 'x' following
the R flag are not used by ANCP. the R flag are not used by ANCP.
Duration: not used for DSL line configuration. Duration: not used for DSL line configuration.
skipping to change at page 44, line 38 skipping to change at page 44, line 48
Flow Control Flags: not used by ANCP. Flow Control Flags: not used by ANCP.
Extension Flags: the flag bits denoted by 'x' before the Message Extension Flags: the flag bits denoted by 'x' before the Message
Type field are reserved for future use. Type field are reserved for future use.
Message Type: Message Type has the same value as in the general Message Type: Message Type has the same value as in the general
header (i.e., 32). header (i.e., 32).
Tech Type: MUST be set to 0x05 (DSL). Tech Type: MUST be set to 0x05 (DSL).
Block Length: unused, reserved. Block Length: unused.
# of TLVs: the number of TLVs that follow, not counting TLVs # of TLVs: the number of TLVs that follow, not counting TLVs
encapsulated within other TLVs. encapsulated within other TLVs.
Extension Block Length: the total length of the TLVs carried in the Extension Block Length: the total length of the TLVs carried in the
extension block in bytes, including any padding within individual extension block in bytes, including any padding within individual
TLVs. (The existing "Block Length" field inherited from the GSMP TLVs.
message is limited to 255 bytes and is not sufficient).
TLVs: two or more TLVs to identify a DSL line and configure its TLVs: two or more TLVs to identify a DSL line and configure its
service data. service data.
5.3.3.3. Procedures 5.3.3.3. Procedures
Section 5.3.2 Describes the circumstances under which the NAS sends a Section 5.3.2 Describes the circumstances under which the NAS sends a
Port Management message to the AN to configure DSL service parameters Port Management message to the AN to configure DSL service parameters
for a specific subscriber line. To identify the line, the NAS MUST for a specific subscriber line. To identify the line, the NAS MUST
include one of Access-Loop-Circuit-ID TLV, Access-Aggregation- include one of Access-Loop-Circuit-ID TLV, Access-Aggregation-
skipping to change at page 46, line 34 skipping to change at page 46, line 44
local loop. In the case of Ethernet, the Access Node can trigger an local loop. In the case of Ethernet, the Access Node can trigger an
Ethernet loopback message(per EFM OAM) on the local loop. Ethernet loopback message(per EFM OAM) on the local loop.
5.4.1. Message Flow 5.4.1. Message Flow
The Port Management message can be used by the NAS to request Access The Port Management message can be used by the NAS to request Access
Node to trigger a remote loopback test on the local loop. The result Node to trigger a remote loopback test on the local loop. The result
of the loopback test can be asynchronously conveyed by the Access of the loopback test can be asynchronously conveyed by the Access
Node to the NAS in a Port Management response message. The formats Node to the NAS in a Port Management response message. The formats
of the relevant extensions to the Port Management message are defined of the relevant extensions to the Port Management message are defined
in Section 5.4.2.2. Figure 13 summarizes the interaction. in Section 5.4.2.2. Figure 14 summarizes the interaction.
+-------------+ +-----+ +-------+ +----------------+ +-------------+ +-----+ +-------+ +----------------+
|Radius/AAA |----|NAS |-------| DSLAM |-----------| CPE | |Radius/AAA |----|NAS |-------| DSLAM |-----------| CPE |
|Policy Server| +-----+ +-------+ | (DSL Modem + | |Policy Server| +-----+ +-------+ | (DSL Modem + |
+-------------+ |Routing Gateway)| +-------------+ |Routing Gateway)|
+----------------+ +----------------+
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. --------->
<--------+ <--------+
3. <--------------- 3. <---------------
Port Management Message Port Management Message
(Remote Loopback Test Response) (Remote Loopback Test Response)
Figure 13: Message Flow For ANCP based OAM Figure 14: Message Flow For ANCP based OAM
5.4.2. Specification of the ANCP DSL Line Testing Capability 5.4.2. Specification of the ANCP DSL Line Testing Capability
5.4.2.1. Protocol Requirements 5.4.2.1. Protocol Requirements
The DSL line testing capability is assigned capability type 0x04. No The DSL line testing capability is assigned capability type 0x04. No
capability data is associated with this capability. Implementations capability data is associated with this capability. Implementations
of the DSL line testing capability MUST support the following ANCP of the DSL line testing capability MUST support the following ANCP
protocol elements: protocol elements:
skipping to change at page 48, line 11 skipping to change at page 48, line 28
o The appended TLVs in the extension value field include testing- o The appended TLVs in the extension value field include testing-
related TLVs rather than subcriber service information. related TLVs rather than subcriber service information.
5.4.2.3. Procedures 5.4.2.3. Procedures
The ANCP Port Management message as described in Section 5.4.2.2 MAY The ANCP Port Management message as described in Section 5.4.2.2 MAY
be used by the NAS to trigger the Access Node to run a loopback test be used by the NAS to trigger the Access Node to run a loopback test
on the local loop. To identify the line to be tested, the NAS MUST on the local loop. To identify the line to be tested, the NAS MUST
include one of Access-Loop-Circuit-ID TLV, Access-Aggregation- include one of Access-Loop-Circuit-ID TLV, Access-Aggregation-
Circuit-ID-Binary TLV, or Access-Aggregation-Circuit-ID-ASCII TLV in Circuit-ID-Binary TLV, or Access- Aggregation-Circuit-ID-ASCII TLV in
the Port Management message, depending upon the deployment scenario. the Port Management message, depending upon the deployment scenario.
The NAS MAY include the OAM-Loopback-Test-Parameters and/or Opaque- The NAS MAY include the OAM-Loopback-Test-Parameters and/or Opaque-
Data TLVs (defined in Section 5.4.2.4) to configure the loopback test Data TLVs (defined in Section 5.4.2.4) to configure the loopback test
for that line. for that line.
The Access Node SHOULD generate a Port Management response when it The Access Node SHOULD generate a Port Management response when it
deems the loopback test to be complete. (The exception is described deems the loopback test to be complete. (The exception is described
with reference to the Timeout field in the OAM-Loopback-Test- with reference to the Timeout field in the OAM-Loopback-Test-
Parameters TLV in Section 5.4.2.4.) The Result field MUST be set to Parameters TLV in Section 5.4.2.4.) The Result field MUST be set to
Success (0x3) or Failure (0x4) as applicable. The Code field SHOULD Success (0x3) or Failure (0x4) as applicable. The Code field SHOULD
skipping to change at page 49, line 43 skipping to change at page 50, line 14
failure response to the NAS. failure response to the NAS.
Byte 2: Timeout. Upper bound on the time in seconds that the Byte 2: Timeout. Upper bound on the time in seconds that the
NAS will wait for a response from the DSLAM. If the total time NAS will wait for a response from the DSLAM. If the total time
taken by the DSLAM to complete a test with requested taken by the DSLAM to complete a test with requested
parameters, exceeds the specified "timeout" value, it MAY parameters, exceeds the specified "timeout" value, it MAY
choose to omit the generation of a response to the NAS. The choose to omit the generation of a response to the NAS. The
DSLAM SHOULD use a locally determined value for Timeout, if the DSLAM SHOULD use a locally determined value for Timeout, if the
received value of the Timeout parameter is 0. received value of the Timeout parameter is 0.
The OAM-Loopback-Test-Parameters TLV is illustrated in Figure 14 The OAM-Loopback-Test-Parameters TLV is illustrated in Figure 15
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x0007 | Length = 2 | | TLV Type = 0x0007 | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count | Timeout | Padding (=0) | | Count | Timeout | Padding (=0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: The OAM-Loopback-Test-Parameters TLV
Figure 15: The OAM-Loopback-Test-Parameters TLV
5.4.2.4.2. Opaque-Data TLV 5.4.2.4.2. Opaque-Data TLV
Name: Opaque-Data Name: Opaque-Data
Type: 0x0008 Type: 0x0008
Description: This is an optional TLV. If it is present in the Description: This is an optional TLV. If it is present in the
request message, the DSLAM SHOULD reflect it back in the response request message, the DSLAM SHOULD reflect it back in the response
unmodified. unmodified.
skipping to change at page 50, line 28 skipping to change at page 50, line 48
Value: Two 32 bit unsigned integers inserted by the NAS (not to be Value: Two 32 bit unsigned 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).
5.4.2.4.3. OAM-Loopback-Test-Response-String TLV 5.4.2.4.3. OAM-Loopback-Test-Response-String TLV
Name: OAM-Loopback-Test-Response-String Name: OAM-Loopback-Test-Response-String
Type: 0x0009 Type: 0x0009
Description: Suitably formatted ASCII string containing useful Description: Suitably formatted string containing useful details
details about the test that the NAS will display for the operator, about the test that the NAS will display for the operator, exactly
exactly as received from the DSLAM (no manipulation/interpretation as received from the DSLAM (no manipulation/interpretation by the
by the NAS). This is an optional TLV, but it is strongly NAS). This is an optional TLV, but it is strongly RECOMMENDED
RECOMMENDED that in case of ATM based local loop, the DSLAM at the that in case of ATM based local loop, the DSLAM at the very least
very least indicates, via this TLV, the total loopback cells indicates, via this TLV, the total loopback cells generated and
generated and the total loopback cells successfully received as the total loopback cells successfully received as part of
part of executing the requested loopback test. executing the requested loopback test.
Length: up to 128 bytes Length: up to 128 bytes
Value: ASCII string. Value: UTF-8 encoded string of text.
6. Additional ANCP Messages and TLVs 6. Additional ANCP Messages and TLVs
This section defines two messages and a number of TLVs that may be This section defines two messages and a number of TLVs that may be
useful in multiple capabilities. Typically the content is under- useful in multiple capabilities. Typically the content is under-
specified, with the intention that particular capabilities spell out specified, with the intention that particular capabilities spell out
the remaining details. the remaining details.
6.1. Additional Messages and General Messaging Principles 6.1. Additional Messages and General Messaging Principles
skipping to change at page 51, line 24 skipping to change at page 51, line 39
used to differentiate between request and response messages. used to differentiate between request and response messages.
b. The request and response messages use two different message b. The request and response messages use two different message
types. types.
The first approach is illustrated by the protocol specifications in The first approach is illustrated by the protocol specifications in
Section 5. The purpose of this section is to provide more details Section 5. The purpose of this section is to provide more details
about the second approach in order to allow the use of this messaging about the second approach in order to allow the use of this messaging
construct for the development of additional ANCP extensions. construct for the development of additional ANCP extensions.
As Section 4.4 indicated, all ANCP messages other than adjacency As Section 4.6 indicated, all ANCP messages other than adjacency
messages share a common header format. When the response message messages share a common header format. When the response message
type is different from that of the request, the specification of the type is different from that of the request, the specification of the
request message will typically indicate that the Result field is set request message will typically indicate that the Result field is set
to Ignore (0x0) and provide procedures indicating explicitly when the to Ignore (0x0) and provide procedures indicating explicitly when the
receiver should generate a response and what message type it should receiver should generate a response and what message type it should
use. use.
The Transaction ID field is used to distinguish between request The Transaction ID field is used to distinguish between request
messages and to associate a response message to a request. messages and to associate a response message to a request.
Specifications of ANCP messages for applications not requiring Specifications of ANCP messages for applications not requiring
response correlation should indicate that the Transaction ID must be response correlation should indicate that the Transaction ID must be
set to zero in requests. Applications that require response set to zero in requests. Applications that require response
correlation should refer to the Transaction ID behaviour described in correlation should refer to the Transaction ID behaviour described in
Section 4.4.1. Section 4.6.1.
The specification for a response message should indicate in all cases The specification for a response message should indicate in all cases
that value of the Transaction Identifier must be set to that of the that value of the Transaction Identifier must be set to that of the
corresponding request message. This allows the requester to corresponding request message. This allows the requester to
establish whether or not correlation is needed (by setting a non-zero establish whether or not correlation is needed (by setting a non-zero
or zero value for the Transaction ID). or zero value for the Transaction ID).
6.1.2. Provisioning Message 6.1.2. Provisioning Message
The Provisioning message is sent by the NAS to the AN to provision The Provisioning message is sent by the NAS to the AN to provision
information of global scope on the AN. The Provisioning message has information of global scope on the AN. The Provisioning message has
the format shown in Figure 15. the format shown in Figure 16.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP/IP Encapsulating Header (Section 4.2) | | TCP/IP Encapsulating Header (Section 4.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header | | ANCP General Message Header |
+ (Section 4.4) + + (Section 4.4) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ TLVs ~ ~ TLVs ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Format of the Provisioning Message Figure 16: Format of the Provisioning Message
This document specifies the following fields. The remaining fields This document specifies the following fields. The remaining fields
in the ANCP general message header MUST be set as specified in in the ANCP general message header MUST be set as specified in
Section 4.4.1. The TLVs are specified elsewhere on a per-capability Section 4.6.1. The TLVs are specified elsewhere on a per-capability
basis. The Provisioning message MAY be used to carry data relating basis. The Provisioning message MAY be used to carry data relating
to more than one capability at once, assuming that the capabilities to more than one capability at once, assuming that the capabilities
concerned can co-exist and have all been negotiated during adjacency concerned can co-exist and have all been negotiated during adjacency
establishment. establishment.
Message Type: MUST be set to 93. Message Type: MUST be set to 93.
Result: MUST be set to 0x0 (Ignore). Result: MUST be set to 0x0 (Ignore).
Code: MUST be set to zero. Code: MUST be set to zero.
Transaction ID: MUST be populated with a non-zero value chosen in Transaction ID: MUST be populated with a non-zero value chosen in
the manner described in Section 4.4.1. the manner described in Section 4.6.1.
If the AN can process the message successfully and accept all the If the AN can process the message successfully and accept all the
provisioning directives contained in it, the AN MUST NOT send any provisioning directives contained in it, the AN MUST NOT send any
response. response.
If not otherwise specified, if the AN fails to process the message If not otherwise specified, if the AN fails to process the message
successfully it MUST send a Generic Response message (Section 6.1.3) successfully it MUST send a Generic Response message (Section 6.1.3)
indicating failure and providing appropriate diagnostic information. indicating failure and providing appropriate diagnostic information.
6.1.3. Generic Response Message 6.1.3. Generic Response Message
skipping to change at page 53, line 19 skipping to change at page 53, line 39
MAY be sent by either the NAS or the AN. MAY be sent by either the NAS or the AN.
The AN or NAS MAY send a Generic Response message indicating a The AN or NAS MAY send a Generic Response message indicating a
failure condition independently of a specific request before closing failure condition independently of a specific request before closing
the adjacency as a consequence of that failure condition. In this the adjacency as a consequence of that failure condition. In this
case, the sender MUST set the Transaction ID field in the header and case, the sender MUST set the Transaction ID field in the header and
the Message Type field within the Status-Info TLV to zeroes. The the Message Type field within the Status-Info TLV to zeroes. The
receiver MAY record the information contained in the Status-info TLV receiver MAY record the information contained in the Status-info TLV
for management use. for management use.
The format of the Generic Response message is shown in Figure 16 The format of the Generic Response message is shown in Figure 17
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP/IP Encapsulating Header (Section 4.2) | | TCP/IP Encapsulating Header (Section 4.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header | | ANCP General Message Header |
+ (Section 4.4) + + (Section 4.4) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status-Info TLV | | Status-Info TLV |
~ (Section 6.2.3) ~ ~ (Section 6.2.3) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Structure of the Generic Response Message Figure 17: Structure of the Generic Response Message
This document specifies the following fields. The remaining fields This document specifies the following fields. The remaining fields
in the ANCP general message header MUST be set as specified in in the ANCP general message header MUST be set as specified in
Section 4.4.1. Section 4.6.1.
Message Type: MUST be set to 91. Message Type: MUST be set to 91.
Result: MUST be set to 0x3 (Success) or 0x4 (Failure). Result: MUST be set to 0x3 (Success) or 0x4 (Failure).
Code: MUST be set to zero for success or an appropriate non-zero Code: MUST be set to zero for success or an appropriate non-zero
value for failure. value for failure.
Transaction ID: MUST be copied from the message to which this Transaction ID: MUST be copied from the message to which this
message is a response. message is a response.
skipping to change at page 54, line 33 skipping to change at page 55, line 17
Description: The Target TLV (0x1000 - 0x1020) is intended to be a Description: The Target TLV (0x1000 - 0x1020) is intended to be a
general means to represent different types of objects. general means to represent different types of objects.
Length: Variable, depending on the specific object type. Length: Variable, depending on the specific object type.
Value: Target information as defined for each object type. The Value: Target information as defined for each object type. The
field can consist of sub-TLVs. field can consist of sub-TLVs.
TLV Type 0x1000 is assigned to a variant of the Target TLV TLV Type 0x1000 is assigned to a variant of the Target TLV
representing a single access line and encapsulating one or more sub- representing a single access line and encapsulating one or more sub-
TLVs identifying the target. Figure 17 illustrates the message TLVs identifying the target. Figure 18 illustrates the message
format for a single port identified by an Access-Loop-Circuit-ID TLV format for a single port identified by an Access-Loop-Circuit-ID TLV
(0x0001) that could be derived from a Port-UP message: (0x0001) that could be derived from a Port-UP message:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x1000 |Length = Circuit-ID Length + 4 | | TLV Type = 0x1000 |Length = Circuit-ID Length + 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length | | Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Access Loop Circuit ID ~ ~ Access Loop Circuit ID ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Example of Target TLV For Single Access Line Figure 18: Example of Target TLV For Single Access Line
6.2.2. Command TLV 6.2.2. Command TLV
Name: Command Name: Command
Type: 0x0011 Type: 0x0011
Description: The Command TLV (0x0011) is intended to be a general Description: The Command TLV (0x0011) is intended to be a general
means of encapsulating one or more command directives in a TLV means of encapsulating one or more command directives in a TLV
oriented message. The semantics of the command can be specified oriented message. The semantics of the command can be specified
skipping to change at page 56, line 5 skipping to change at page 56, line 36
may indicate the use of this TLV as part of responses, may indicate the use of this TLV as part of responses,
particularly for failures. As mentioned above, the Generic particularly for failures. As mentioned above, the Generic
Response message will usually include an instance of the Status- Response message will usually include an instance of the Status-
Info TLV. Info TLV.
Length: Variable, depending on the specific contents. Length: Variable, depending on the specific contents.
Value: The following fixed fields. In addition, sub-TLVs may be Value: The following fixed fields. In addition, sub-TLVs may be
appended to provide further diagnostic information. appended to provide further diagnostic information.
Reserved: see Section 4.4.2.1 for handling of reserved fields. Reserved: see Section 4.4 for handling of reserved fields.
Msg Type: Message Type of the request for which this TLV is Msg Type: Message Type of the request for which this TLV is
providing diagnostics. providing diagnostics.
Error Message Length: Number of bytes in the error message, Error Message Length: Number of bytes in the error message,
excluding padding. This MAY be zero if no error message is excluding padding. This MAY be zero if no error message is
provided. provided.
Error Message: Human-readable string providing information about Error Message: Human-readable string providing information about
the warning or error condition. Padded with zeroes as the warning or error condition. Padded with zeroes as
skipping to change at page 56, line 28 skipping to change at page 57, line 11
The following TLVs are RECOMMENDED to be appended if the indicated The following TLVs are RECOMMENDED to be appended if the indicated
Code values are given in the header of the message containing the Code values are given in the header of the message containing the
Status-info TLV: Status-info TLV:
* Code value 4 or 5: the Target or other TLV identifying the * Code value 4 or 5: the Target or other TLV identifying the
unknown or unavailable port. unknown or unavailable port.
* Code value 84: the TLV that is unsupported or contains the * Code value 84: the TLV that is unsupported or contains the
unsupported value. unsupported value.
Figure 18 illustrates the Status-Info TLV. Figure 19 illustrates the Status-Info TLV.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x0106 | Length | | TLV Type = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Msg Type | Error Message Length | | Reserved | Msg Type | Error Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message (padded to 4 byte boundary) | | Error Message (padded to 4 byte boundary) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional sub-TLVs... | | optional sub-TLVs... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: The Status-Info TLV Figure 19: The Status-Info TLV
7. IANA Considerations 7. IANA Considerations
RFC EDITOR'S NOTE: please replace "RFCXXXX" with the number of this RFC EDITOR'S NOTE: please replace "RFCXXXX" with the number of this
specification. specification.
7.1. Summary 7.1. Summary
This section requests the following IANA actions: This section requests the following IANA actions:
skipping to change at page 57, line 23 skipping to change at page 57, line 50
registry; [Editor's Note: may need an ANCP registry instead. registry; [Editor's Note: may need an ANCP registry instead.
Coordination between the two protocols is unnecessary because of Coordination between the two protocols is unnecessary because of
ANCP's reorganization of the Result field.] ANCP's reorganization of the Result field.]
o extension of limits [Editor's Note: assuming we are allowed to do o extension of limits [Editor's Note: assuming we are allowed to do
this!] and addition of failure codes to the GSMPv3 Failure this!] and addition of failure codes to the GSMPv3 Failure
Response Message Name Space registry; Response Message Name Space registry;
o establishment of the following new ANCP registries: o establishment of the following new ANCP registries:
ANCP Function Codes; [Editor's Note: GSMPv3 has no function ANCP Function Codes;
code registry, so this one might as well belong to ANCP.
Coordination between the two protocols is unnecessary because
of ANCP's reorganization of the Function field.]
ANCP Technology Types; ANCP Technology Types;
ANCP Command Codes; ANCP Command Codes;
ANCP TLV Types; ANCP TLV Types;
ANCP Capabilities. ANCP Capabilities.
7.2. IANA Actions 7.2. IANA Actions
skipping to change at page 59, line 40 skipping to change at page 59, line 49
| 47-59 | Unassigned | | | 47-59 | Unassigned | |
| 86-127 | Unassigned | | | 86-127 | Unassigned | |
| 160-255 | Unassigned | | | 160-255 | Unassigned | |
| 256-1279 | Unassigned (ANCP use only) | | | 256-1279 | Unassigned (ANCP use only) | |
| 1290-4095 | Unassigned (ANCP use only) | | | 1290-4095 | Unassigned (ANCP use only) | |
+-----------+-------------------------------+-----------+ +-----------+-------------------------------+-----------+
IANA is requested to create a new ANCP Port Management Function Name IANA is requested to create a new ANCP Port Management Function Name
registry, with the following initial entries. Additions to this registry, with the following initial entries. Additions to this
registry will be by IETF Consensus. Values may range from 0 to 255. registry will be by IETF Consensus. Values may range from 0 to 255.
[Editor's Note: what about X-Function? Probably has to be a sub-
registry of Function.] NOTE: future extensions of ANCP may need to establish sub-
registries of permitted X-Function values for specific values of
Function.
+----------------+-----------------------------------+-----------+ +----------------+-----------------------------------+-----------+
| Function Value | Function Name | Reference | | Function Value | Function Name | Reference |
+----------------+-----------------------------------+-----------+ +----------------+-----------------------------------+-----------+
| 0 | Reserved | RFCXXXX | | 0 | Reserved | RFCXXXX |
| 1-7 | Unassigned | | | 1-7 | Unassigned | |
| 8 | Configure Connection Service Data | RFCXXXX | | 8 | Configure Connection Service Data | RFCXXXX |
| 9 | Remote Loopback | RFCXXXX | | 9 | Remote Loopback | RFCXXXX |
| 10-255 | Unassigned | | | 10-255 | Unassigned | |
+----------------+-----------------------------------+-----------+ +----------------+-----------------------------------+-----------+
IANA is requested to create a new ANCP Version registry, with IANA is requested to create a new ANCP Version registry, with
additions by IETF consensus. The initial entries are as follows: additions by IETF consensus. The initial entries are as follows:
[Editor's Note: assumes that proposal to combine version and sub-
version into a single registry is accepted.]
+---------+-------------+--------------+----------------------------+ +---------+-------------+--------------+-----------+
| Version | Sub-Version | Name | Reference | | Version | Sub-Version | Name | Reference |
+---------+-------------+--------------+----------------------------+ +---------+-------------+--------------+-----------+
| 3 | 1 | Pre-standard | [Could identify a draft | | 3 | 1 | Pre-standard | |
| | | | version] | | 3 | 2 | ANCPv1 | RFCXXXX |
| 3 | 2 | ANCPv1 | RFCXXXX | +---------+-------------+--------------+-----------+
+---------+-------------+--------------+----------------------------+
IANA is requested to create a new ANCP Technology Type registry, with IANA is requested to create a new ANCP Technology Type registry, with
additions by IETF Consensus. Values may range from 0 to 255. The additions by IETF Consensus. Values may range from 0 to 255. The
initial entries are as follows: initial entries are as follows:
[Editor's Note: probably need text in the main body of the document +-----------------+----------------+-----------+
explaining 0x00 and 0xFF. Latter probably has to be Reserved and | Tech Type Value | Tech Type Name | Reference |
remaining values simply Unassigned.] +-----------------+----------------+-----------+
| 0 | Any technology | RFCXXXX |
+-----------------+----------------------------+-----------+ | 1 | PON | RFCXXXX |
| Tech Type Value | Tech Type Name | Reference | | 2-4 | Unassigned | |
+-----------------+----------------------------+-----------+ | 5 | DSL | RFCXXXX |
| 0 | Extension block not in use | RFCXXXX | | 6-254 | Unassigned | |
| 1 | PON | RFCXXXX | | 255 | Reserved | RFCXXXX |
| 2-4 | Unassigned | | +-----------------+----------------+-----------+
| 5 | DSL | RFCXXXX |
| 6-254 | Unassigned | |
| 255 | Reserved | RFCXXXX |
+-----------------+----------------------------+-----------+
IANA is requested to create a new ANCP Command Code registry, with IANA is requested to create a new ANCP Command Code registry, with
additions by IETF Consensus. The initial entry is as follows: additions by IETF Consensus. The initial entry is as follows:
+--------------------+-----------------------------+-----------+ +--------------------+-----------------------------+-----------+
| Command Code Value | Command Code Directive Name | Reference | | Command Code Value | Command Code Directive Name | Reference |
+--------------------+-----------------------------+-----------+ +--------------------+-----------------------------+-----------+
| 0 | Reserved | RFCXXXX | | 0 | Reserved | RFCXXXX |
+--------------------+-----------------------------+-----------+ +--------------------+-----------------------------+-----------+
skipping to change at page 62, line 6 skipping to change at page 62, line 6
| 0x0107-0x0FF | Unassigned | | | 0x0107-0x0FF | Unassigned | |
| F | | | | F | | |
| 0x1000 | Target (single access line variant) | RFCXXXX | | 0x1000 | Target (single access line variant) | RFCXXXX |
| 0x1001 - | Reserved for Target variants | RFCXXXX | | 0x1001 - | Reserved for Target variants | RFCXXXX |
| 0x1020 | | | | 0x1020 | | |
| 0x1021-0xFFF | Unassigned | | | 0x1021-0xFFF | Unassigned | |
| F | | | | F | | |
+--------------+----------------------------------------+-----------+ +--------------+----------------------------------------+-----------+
IANA is requested to create a new ANCP Capability registry, with IANA is requested to create a new ANCP Capability registry, with
additions by IETF Consensus. Values may range from 0 to 255. The additions by IETF Consensus. Values may range from 0 to 255. The
initial entries are as follows: specification for a given capability MUST indicate whether it applies
to a specific access technology or applies to all access
technologies. The specification MUST further indicate whether the
capability is associated with any capability data. The initial
entries in the ANCP capability registry are as follows:
+-------+------------------------+-----------+ +-------+-------------------+------------+--------------+-----------+
| Value | Capability Type Name | Reference | | Value | Capability Type | Technology | Capability | Reference |
+-------+------------------------+-----------+ | | Name | | Data | |
| 0 | Reserved | RFCXXXX | +-------+-------------------+------------+--------------+-----------+
| 1 | DSL Topology Discovery | RFCXXXX | | 0 | Reserved | | | RFCXXXX |
| 2 | DSL Line Configuration | RFCXXXX | | 1 | DSL Topology | DSL | None | RFCXXXX |
| 3 | Reserved | RFCXXXX | | | Discovery | | | |
| 4 | DSL Line Testing | RFCXXXX | | 2 | DSL Line | DSL | None | RFCXXXX |
| 5-255 | Unassigned | | | | Configuration | | | |
+-------+------------------------+-----------+ | 3 | Reserved | | | RFCXXXX |
| 4 | DSL Line Testing | DSL | None | RFCXXXX |
| 5-255 | Unassigned | | | |
+-------+-------------------+------------+--------------+-----------+
8. Security Considerations 8. Security Considerations
Security of the ANCP protocol is discussed in [RFC5713] Security of the ANCP protocol is discussed in [RFC5713]
9. Acknowledgements 9. Acknowledgements
The authors would like to thank everyone that has provided comments The authors would like to thank everyone who provided comments or
or inputs to this document. Swami Subramanian was an early member of inputs to this document. Swami Subramanian was an early member of
the authors' team. The ANCP Working Group is grateful to Roberta the authors' team. The ANCP Working Group is grateful to Roberta
Maglione, who served as design team member and primary editor of this Maglione, who served as design team member and primary editor of this
document for two years before stepping down. The authors acknowledge document for two years before stepping down. The authors acknowledge
the inputs provided by Wojciech Dec, Peter Arberg, Josef Froehler, the inputs provided by Wojciech Dec, Peter Arberg, Josef Froehler,
Derek Harkness, Kim Hyldgaard, Sandy Ng, Robert Peschi, and Michel Derek Harkness, Kim Hyldgaard, Sandy Ng, Robert Peschi, and Michel
Platnic. Platnic.
10. References 10. References
10.1. Normative References 10.1. Normative References
skipping to change at page 63, line 8 skipping to change at page 63, line 15
[RFC3292] Doria, A., Hellstrand, F., Sundell, K., and T. Worster, [RFC3292] Doria, A., Hellstrand, F., Sundell, K., and T. Worster,
"General Switch Management Protocol (GSMP) V3", RFC 3292, "General Switch Management Protocol (GSMP) V3", RFC 3292,
June 2002. June 2002.
[RFC3293] Worster, T., Doria, A., and J. Buerkle, "General Switch [RFC3293] Worster, T., Doria, A., and J. Buerkle, "General Switch
Management Protocol (GSMP) Packet Encapsulations for Management Protocol (GSMP) Packet Encapsulations for
Asynchronous Transfer Mode (ATM), Ethernet and Asynchronous Transfer Mode (ATM), Ethernet and
Transmission Control Protocol (TCP)", RFC 3293, June 2002. Transmission Control Protocol (TCP)", RFC 3293, June 2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
10.2. Informative References 10.2. Informative References
[G.988.1] "ITU-T recommendation G.998.1, ATM-based multi-pair [G.988.1] "ITU-T recommendation G.998.1, ATM-based multi-pair
bonding", 2005. bonding", 2005.
[G.988.2] "ITU-T recommendation G.998.2, Ethernet-based multi-pair [G.988.2] "ITU-T recommendation G.998.2, Ethernet-based multi-pair
bonding,", 2005. bonding,", 2005.
skipping to change at page 63, line 41 skipping to change at page 63, line 51
[TR_059] Anschutz, T., "DSL Forum TR-059, DSL Evolution - [TR_059] Anschutz, T., "DSL Forum TR-059, DSL Evolution -
Architecture Requirements for the Support of QoS-Enabled Architecture Requirements for the Support of QoS-Enabled
IP Services", September 2003. IP Services", September 2003.
[TR_092] "DSL Forum TR-092, Broadband Remote access server [TR_092] "DSL Forum TR-092, Broadband Remote access server
requirements document", 2005. requirements document", 2005.
[TR_101] Cohen et al, "Architecture & Transport: "Migration to [TR_101] Cohen et al, "Architecture & Transport: "Migration to
Ethernet Based DSL Aggregation", DSL Forum TR-101", 2005. Ethernet Based DSL Aggregation", DSL Forum TR-101", 2005.
Appendix A. Changes from Version -09 to Version -10 [US_ASCII]
American National Standards Institute, "Coded Character
The changes to this document are editorial, although clarifications Set - 7-bit American Standard Code for Information
may have inadvertently introduced some small technical differences. Interchange", ANSI X.34, 1986.
The biggest change was a rearrangement of text to provide a clear
separation between generally applicable protocol aspects and the
three DSL capabilities documented here. The following table provides
a mapping between section numbers in the -09 version and section
numbers in the -10 version, with comments where text was modified
significantly.
+--------------+--------------+-------------------------------------+
| -09 Section | -10 Section | Comments |
+--------------+--------------+-------------------------------------+
| Abstract | Abstract | Rewritten to better reflect |
| | | contents. |
| - | - | - |
| 1 | 1 | |
| - | - | - |
| 2 | 5.2 | First two paragraphs moved. |
| | | Remainder smoothed a bit. Added |
| | | document outline. |
| - | - | - |
| 2.1 | 2.1 | Added definitions for TLV, ANCP |
| | | capability, ANCP session |
| | | (adjacency). |
| - | - | - |
| 3, 3.1, 3.2 | Same | |
| - | - | - |
| 4.1 | 5.1 | First paragraph dropped. |
| - | - | - |
| 4.2.1, 4.2.2 | 5.2.1, 5.2.2 | |
| - | - | - |
| 4.3.1, 4.3.2 | 5.3.1, 5.3.2 | |
| - | - | - |
| 4.4, 4.4.1 | 5.4, 5.4.1 | |
| - | - | - |
| 5 | 4.4, 4.4.1, | In 4.4.1, added normative text for |
| | 4.4.2.1, 4 | Transaction ID taken from old |
| | | 5.4.5. Did not include "Extension |
| | | Block" as generally usable |
| | | structure, but this decision is |
| | | subject to WG review. |
| - | - | - |
| 5.1 | 4.2 | Added normative text from old |
| | | 5.4.5. This text need review. |
| - | - | - |
| 5.2, 5.3 | 4.3 and | Capabilities were renamed to |
| | sub-sections | explicitly include "DSL" as part of |
| | | the name. OAM was renamed to line |
| | | testing, since that is all that is |
| | | included. |
| - | - | - |
| 5.4.1.1 | 5.2.3.2, | Merged into message format |
| | 5.3.3.2 | descriptions. |
| - | - | - |
| 5.4.2 | 5.2.3.2, | Contents scattered due to |
| | 5.2.3.3, and | separation of message format, |
| | sub-sections | procedures, TLV definitions. |
| - | - | - |
| 5.4.3 | 5.3.3.2 | |
| - | - | - |
| 5.4.3.1 | 6.1.2 | Provisioning message was not really |
| | | related to line provisioning. |
| - | - | - |
| 5.4.4 | Sub-sections | Contents scattered due to |
| | of 5.4.2 | separation of message format, |
| | | procedures, TLV definitions. |
| - | - | - |
| 5.4.5 | 6.1.1 | Normative text on Transaction ID, |
| | | discarding of messages removed to |
| | | 4.4 and 4.2 respectively. |
| - | - | - |
| 5.4.5.1 and | 6.2 and | |
| sub-sections | sub-sections | |
| - | - | - |
| 5.4.5.2 | 6.1.3 | |
| - | - | - |
| 5.5, 5.6 | 5.1.1, 5.1.2 | |
| - | - | - |
| 6, 7, 8, 9 | 7, 8, 9, 10 | |
+--------------+--------------+-------------------------------------+
Authors' Addresses 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 USA
Phone: Phone:
 End of changes. 133 change blocks. 
378 lines changed or deleted 333 lines changed or added

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