draft-ietf-ancp-protocol-12.txt   draft-ietf-ancp-protocol-13.txt 
Network Working Group S. Wadhwa Network Working Group S. Wadhwa
Internet-Draft J. Moisand Internet-Draft Alcatel-Lucent
Intended status: Standards Track Juniper Networks Intended status: Standards Track J. Moisand
Expires: February 25, 2011 T. Haag Expires: July 8, 2011 Juniper Networks
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
August 24, 2010 January 4, 2011
Protocol for Access Node Control Mechanism in Broadband Networks Protocol for Access Node Control Mechanism in Broadband Networks
draft-ietf-ancp-protocol-12 draft-ietf-ancp-protocol-13
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
multi-service reference architecture in order to perform QoS-related, a multi-service reference architecture in order to perform QoS-
service-related and subscriber- related operations. Use cases for related, service-related and subscriber-related operations. Use
ANCP are documented in RFC 5851. As well as describing the base ANCP cases for ANCP are documented in RFC 5851. As well as describing the
protocol, this document specifies capabilities for Digital Subscriber base ANCP protocol, this document specifies capabilities for Digital
Line (DSL) topology discovery, line configuration, and line testing. Subscriber Line (DSL) topology discovery, line configuration, and
The design of ANCP anticipates the specification in other documents remote line connectivity testing. The design of ANCP allows for
of extensions to the protocol to support additional ANCP protocol protocol extensions in other documents if they are needed to support
capabilities covering other use cases and other technologies. other use cases and other access technologies.
ANCP is based on GSMPv3 (RFC 3292), but with many modifications and ANCP is based on GSMPv3 (RFC 3292), but with many modifications and
extensions, to the point that the two protocols are not extensions, to the point that the two protocols are not
interoperable. interoperable.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 February 25, 2011. This Internet-Draft will expire on July 8, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 7 skipping to change at page 3, line 7
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Specification Requirements . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 6
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
3. Broadband Access Aggregation . . . . . . . . . . . . . . . . . 7 2. Broadband Access Aggregation . . . . . . . . . . . . . . . . . 8
3.1. ATM-based broadband aggregation . . . . . . . . . . . . . 7 2.1. ATM-based Broadband Aggregation . . . . . . . . . . . . . 8
3.2. Ethernet-based broadband aggregation . . . . . . . . . . . 9 2.2. Ethernet-Based Broadband Aggregation . . . . . . . . . . . 10
4. Access Node Control Protocol -- General Aspects . . . . . . . 9 3. Access Node Control Protocol -- General Aspects . . . . . . . 10
4.1. Protocol Version . . . . . . . . . . . . . . . . . . . . . 11 3.1. Protocol Version . . . . . . . . . . . . . . . . . . . . . 10
4.2. ANCP Transport . . . . . . . . . . . . . . . . . . . . . . 11 3.2. ANCP Transport . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Encoding of Text Fields . . . . . . . . . . . . . . . . . 12 3.3. Encoding of Text Fields . . . . . . . . . . . . . . . . . 12
4.4. Treatment of Reserved and Unused Fields . . . . . . . . . 12 3.4. Treatment of Reserved and Unused Fields . . . . . . . . . 12
4.5. Use of the GSMPv3 Adjacency Protocol . . . . . . . . . . . 12 3.5. Use of the GSMPv3 Adjacency Protocol . . . . . . . . . . . 12
4.5.1. ANCP Adjacency Message Format . . . . . . . . . . . . 13 3.5.1. ANCP Adjacency Message Format . . . . . . . . . . . . 12
4.5.2. ANCP Adjacency Procedures . . . . . . . . . . . . . . 15 3.5.2. ANCP Adjacency Procedures . . . . . . . . . . . . . . 15
4.6. ANCP General Message Formats . . . . . . . . . . . . . . . 17 3.6. ANCP General Message Formats . . . . . . . . . . . . . . . 17
4.6.1. The ANCP Message Header . . . . . . . . . . . . . . . 17 3.6.1. The ANCP Message Header . . . . . . . . . . . . . . . 17
4.6.2. The ANCP Message Body . . . . . . . . . . . . . . . . 20 3.6.2. The ANCP Message Body . . . . . . . . . . . . . . . . 25
5. ANCP Capabilities For Digital Subscriber Lines (DSL) . . . . . 22 3.7. General Principles for the Design of ANCP Messages . . . . 26
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 22 4. Generally Useful ANCP Messages and TLVs . . . . . . . . . . . 27
5.1.1. ATM-Specific Considerations . . . . . . . . . . . . . 22 4.1. Provisioning Message . . . . . . . . . . . . . . . . . . . 27
5.1.2. Ethernet-Specific Considerations . . . . . . . . . . . 23 4.2. Generic Response Message . . . . . . . . . . . . . . . . . 28
5.2. ANCP Based DSL Topology Discovery . . . . . . . . . . . . 24 4.3. Target TLV . . . . . . . . . . . . . . . . . . . . . . . . 30
5.2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 24 4.4. Command TLV . . . . . . . . . . . . . . . . . . . . . . . 30
5.2.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 24 4.5. Status-Info TLV . . . . . . . . . . . . . . . . . . . . . 31
5.2.3. Specification of the ANCP DSL Topology Discovery 5. Introduction To ANCP Capabilities For Digital Subscriber
Capability . . . . . . . . . . . . . . . . . . . . . . 25 Lines (DSL) . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.3. ANCP based DSL Line Configuration . . . . . . . . . . . . 40 5.1. DSL Access Line Identification . . . . . . . . . . . . . . 33
5.3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 40 5.1.1. Control Context (Informative) . . . . . . . . . . . . 33
5.3.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 40 5.1.2. TLVs For DSL Access Line Identification . . . . . . . 34
5.3.3. Specification of the ANCP DSL Line Configuration 6. ANCP Based DSL Topology Discovery . . . . . . . . . . . . . . 37
Capability . . . . . . . . . . . . . . . . . . . . . . 42 6.1. Control Context (Informative) . . . . . . . . . . . . . . 37
5.4. ANCP Based DSL Line Testing Capability . . . . . . . . . . 46 6.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 39
5.4.1. Message Flow . . . . . . . . . . . . . . . . . . . . . 46 6.2.1. Protocol Requirements On the AN Side . . . . . . . . . 39
5.4.2. Specification of the ANCP DSL Line Testing 6.2.2. Protocol Requirements On the NAS Side . . . . . . . . 40
Capability . . . . . . . . . . . . . . . . . . . . . . 47 6.3. ANCP Port UP and Port DOWN Event Message Descriptions . . 40
6. Additional ANCP Messages and TLVs . . . . . . . . . . . . . . 51 6.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 42
6.1. Additional Messages and General Messaging Principles . . . 51 6.4.1. Procedures On the AN Side . . . . . . . . . . . . . . 42
6.1.1. General Principles for the Design of ANCP Messages . 51 6.4.2. Procedures On the NAS Side . . . . . . . . . . . . . . 43
6.1.2. Provisioning Message . . . . . . . . . . . . . . . . . 52 6.5. TLVs For DSL Line Attributes . . . . . . . . . . . . . . . 43
6.1.3. Generic Response Message . . . . . . . . . . . . . . . 53 6.5.1. DSL-Line-Attributes TLV . . . . . . . . . . . . . . . 43
6.2. TLVs For General Use . . . . . . . . . . . . . . . . . . . 54 6.5.2. DSL-Type TLV . . . . . . . . . . . . . . . . . . . . . 44
6.2.1. Target TLV . . . . . . . . . . . . . . . . . . . . . . 54 6.5.3. Actual-Net-Data-Rate-Upstream TLV . . . . . . . . . . 44
6.2.2. Command TLV . . . . . . . . . . . . . . . . . . . . . 55 6.5.4. Actual-Net-Data-Rate-Downstream TLV . . . . . . . . . 44
6.2.3. Status-Info TLV . . . . . . . . . . . . . . . . . . . 56 6.5.5. Minimum-Net-Data-Rate-Upstream TLV . . . . . . . . . . 45
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 6.5.6. Minimum-Net-Data-Rate-Downstream TLV . . . . . . . . . 45
7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 57 6.5.7. Attainable-Net-Data-Rate-Upstream TLV . . . . . . . . 45
7.2. IANA Actions . . . . . . . . . . . . . . . . . . . . . . . 58 6.5.8. Attainable-Net-Data-Rate-Downstream TLV . . . . . . . 45
8. Security Considerations . . . . . . . . . . . . . . . . . . . 62 6.5.9. Maximum-Net-Data-Rate-Upstream TLV . . . . . . . . . . 46
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 62 6.5.10. Maximum-Net-Data-Rate-Downstream TLV . . . . . . . . . 46
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62 6.5.11. Minimum-Net-Low-Power-Data-Rate-Upstream TLV . . . . . 46
10.1. Normative References . . . . . . . . . . . . . . . . . . . 62 6.5.12. Minimum-Net-Low-Power-Data-Rate-Downstream TLV . . . . 46
10.2. Informative References . . . . . . . . . . . . . . . . . . 63 6.5.13. Maximum-Interleaving-Delay-Upstream TLV . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64 6.5.14. Actual-Interleaving-Delay-Upstream TLV . . . . . . . . 47
6.5.15. Maximum-Interleaving-Delay-Downstream TLV . . . . . . 47
1. Specification Requirements 6.5.16. Actual-Interleaving-Delay-Downstream . . . . . . . . . 47
6.5.17. DSL-Line-State TLV . . . . . . . . . . . . . . . . . . 47
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 6.5.18. Access-Loop-Encapsulation TLV . . . . . . . . . . . . 48
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 7. ANCP based DSL Line Configuration . . . . . . . . . . . . . . 49
document are to be interpreted as described in [RFC2119]. 7.1. Control Context (Informative) . . . . . . . . . . . . . . 49
7.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 50
7.2.1. Protocol Requirements On the NAS Side . . . . . . . . 51
7.2.2. Protocol Requirements On the AN Side . . . . . . . . . 51
7.3. ANCP Port Management (Line Configuration) Message
Format . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 54
7.4.1. Procedures On the NAS Side . . . . . . . . . . . . . . 54
7.4.2. Procedures On the AN Side . . . . . . . . . . . . . . 54
7.5. TLVs For DSL Line Configuration . . . . . . . . . . . . . 55
7.5.1. Service-Profile-Name TLV . . . . . . . . . . . . . . . 55
8. ANCP-Based DSL Remote Line Connectivity Testing . . . . . . . 55
8.1. Control Context (Informative) . . . . . . . . . . . . . . 55
8.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 56
8.2.1. Protocol Requirements On the NAS Side . . . . . . . . 56
8.2.2. Protocol Requirements On the AN Side . . . . . . . . . 57
8.3. Port Management (OAM) Message Format . . . . . . . . . . . 57
8.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 58
8.4.1. NAS-Side Procedures . . . . . . . . . . . . . . . . . 58
8.4.2. AN-Side Procedures . . . . . . . . . . . . . . . . . . 59
8.5. TLVs For the DSL Line Remote Connectivity Testing
Capability . . . . . . . . . . . . . . . . . . . . . . . . 60
8.5.1. OAM-Loopback-Test-Parameters TLV . . . . . . . . . . . 60
8.5.2. Opaque-Data TLV . . . . . . . . . . . . . . . . . . . 61
8.5.3. OAM-Loopback-Test-Response-String TLV . . . . . . . . 61
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61
9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 61
9.2. IANA Actions . . . . . . . . . . . . . . . . . . . . . . . 62
10. Security Considerations . . . . . . . . . . . . . . . . . . . 67
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 69
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69
12.1. Normative References . . . . . . . . . . . . . . . . . . . 69
12.2. Informative References . . . . . . . . . . . . . . . . . . 69
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70
2. Introduction 1. Introduction
This draft defines a new protocol, the Access Node Control Protocol This draft defines a new protocol, the Access Node Control Protocol
(ANCP), to realize a control plane between a service-oriented layer 3 (ANCP), to realize a control plane between a service-oriented layer 3
edge device (the Network Access Server, NAS) and a layer 2 Access edge device (the Network Access Server, NAS) and a layer 2 Access
Node (e.g., Digital Subscriber Line Access Module, DSLAM) in order to Node (e.g., Digital Subscriber Line Access Module, DSLAM) in order to
perform QoS-related, service- related and subscriber-related perform QoS-related, service-related and subscriber-related
operations. The protocol specification takes GSMPv3 [RFC3292] as a operations. The requirements for ANCP and the context within which
starting point and specifies modifications and extensions to GSMPv3 it operates are described in [RFC5851].
to achieve ANCP requirements. Although ANCP is based on GSMPv3, the
The protocol specification takes GSMPv3 [RFC3292] as a starting
point, and the implementor is directed to parts of [RFC3292] for the
specification of some aspects of the protocol. However, ANCP
introduces so many extensions and modifications to GSMPv3 that the
two protocols are not interoperable. two protocols are not interoperable.
This specification assumes ANCP transport over TCP/IP. TCP ANCP provides its services to control applications operating in the
encapsulation for ANCP is as defined for GSMPv3 in [RFC3293]. ANCP AN and NAS respectively. This relationship is shown in Figure 1.
encapsulation directly over Ethernet and ATM as defined for GSMPv3 in Specification of the control applications is beyond the scope of this
[RFC3293] is not considered. document, but informative partial descriptions are provided as
necessary to give a context for the operation of the protocol.
ANCP uses a subset of GSMPv3 messages, message content, and Access Node Network Access Server
procedures to implement currently defined use cases. Additional ANCP +--------------------+ +--------------------+
messages, message content, and procedures are specified in this | +----------------+ | | +----------------+ |
document and may also be specified in other documents extending ANCP. | | AN Control | | | | NAS Control | |
| | Application | | | | Application | |
| +----------------+ | | +----------------+ |
| +----------------+ | | +----------------+ |
| | ANCP Agent | | ANCP Messages | | ANCP Agent | |
| | (AN side) |<----------------------->| (NAS side) | |
| +----------------+ | | +----------------+ |
+--------------------+ +--------------------+
Figure 1: Architectural Context For the Access Node Control Protocol
At various points in this document, information flows between the
control applications and ANCP are described. The purpose of such
descriptions is to clarify the boundary between this specification
and, for example, [TR-147]. There is no intention to place limits on
the degree to which the control application and the protocol
implementation are integrated.
This specification specifies ANCP transport over TLS/TCP/IP. TCP
encapsulation for ANCP is as defined for GSMPv3 in [RFC3293]. The
alternative GSMPv3 encapsulation directly over Ethernet and ATM as
defined in [RFC3293] is not considered for ANCP.
The organization of this document is as follows: The organization of this document is as follows:
o The next sub-section introduces some terminology that will be o The next two sub-sections introduce some terminology that will be
useful in understanding the rest of the document. useful in understanding the rest of the document.
o Section 3 provides a description of the access networks within o Section 2 provides a description of the access networks within
which ANCP will typically be deployed. which ANCP will typically be deployed.
o Section 4 specifies generally applicable aspects of the ANCP o Section 3 specifies generally applicable aspects of the ANCP
protocol. protocol.
o Section 5 describes and specifies the ANCP implementation of three o Section 4 specifies some messages and TLVs intended for use by
capabilities applicable to the control of DSL access technology: multiple capabilities spanning multiple technologies.
topology discovery, line configuration, and line testing (OAM).
o Section 6 provides a set of specifications expected to be useful o Section 5 and the three following sections describe and specify
when defining extensions to the base protocol. the ANCP implementation of three capabilities applicable to the
control of DSL access technology: topology discovery, line
configuration, and remote line connectivity testing.
o Section 7 is the IANA Considerations section. Some codepoints are o Section 9 is the IANA Considerations section. Some codepoints are
added to existing GSMPv3 registries set up by [RFC3292], but a added to existing GSMPv3 registries set up by [RFC3292], but a
number of new ANCP-specific registries are also defined. number of new ANCP-specific registries are also defined.
o Section 8 addresses security considerations relating to ANCP, with o Section 10 addresses security considerations relating to ANCP,
heavy reliance on [RFC5713]. beginning with the requirements stated in [RFC5713].
RFC Editor's Note: the following paragraph should be deleted upon RFC EDITOR'S NOTE: the following paragraph should be deleted upon
publication. publication.
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.5. NOTE: this mechanism does it is described in detail in Section 3.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 1.1. Requirements Language
Access Node (AN): Network device, usually located at a service The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
provider central office or street cabinet that terminates access "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
(local) loop connections from subscribers. In case the access document are to be interpreted as described in [RFC2119].
loop is a Digital Subscriber Line (DSL), the Access Node provides
DSL signal termination, and is referred to as a DSL Access
Multiplexer (DSLAM).
Network Access Server (NAS): Network element which aggregates This specification uses requirements language in lower case and
subscriber traffic from a number of Access Nodes. The NAS is an between quotation marks (e.g., "must") to denote requirements on the
injection point for policy management and IP QoS in the access interface between ANCP and the control application. Such
network. It is also referred to as a Broadband Network Gateway requirements are inherently untestable but need to be taken into
(BNG) or Broadband Remote Access Server (BRAS). account by the implementor.
1.2. Terminology
This section repeats some definitions from [RFC5851], but also adds
definitions for terms used only in this document.
Access Node (AN): [RFC5851] Network device, usually located at a
service provider central office or street cabinet that terminates
access (local) loop connections from subscribers. In case the
access loop is a Digital Subscriber Line (DSL), the Access Node
provides DSL signal termination, and is referred to as a DSL
Access Multiplexer (DSLAM).
Network Access Server (NAS): [RFC5851] Network element which
aggregates subscriber traffic from a number of Access Nodes. The
NAS is an enforcement point for policy management and IP QoS in
the access network. It is also referred to as a Broadband Network
Gateway (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 may 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 ANCP agent: A logical entity that implements the ANCP protocol in
can be used to transmit actual user information (e.g. ATM cells the Access Node (AN-side) or NAS (NAS-side).
of Ethernet frames). It excludes overhead that pertains to the
physical transmission mechanism (e.g. trellis coding in case of
DSL). This is defined in section 3.39 of ITU-T G.993.2.
DSL line (synch) rate: the total data rate of the DSL line, Access Node control adjacency: (modified from [RFC5851]) the
including the overhead attributable to the physical transmission relationship between the AN-side ANCP agent and the NAS-side ANCP
mechanism. agent for the purpose of exchanging Access Node Control Protocol
messages. The adjacency may either be up or down, depending on
the result of the Access Node Control adjacency protocol
operation.
DSL multi-pair bonding: method for bonding (or aggregating) multiple ANCP capability: A specific set of ANCP messages, message content,
xDSL lines into a single bi-directional logical link, henceforth and procedures required to implement a specific use case or set of
referred to in this draft as "DSL bonded circuit". DSL "multi- use cases. Some ANCP capabilities are applicable to just one
pair" bonding allows an operator to combine the data rates on two access technology while others are technology independent. The
or more copper pairs, and deliver the aggregate data rate to a capabilities applicable to a given ANCP adjacency are negotiated
single customer. ITU-T recommendations G.998.1 and G.998.2 during adjacency startup.
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.6.2. The value field of a TLV can contain described in Section 3.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, Net data rate: [RFC5851] defined by ITU-T G.993.2 [G.993.2], Section
message content, and procedures required to implement a specific 3.39, i.e., the portion of the total data rate that can be used to
use case or set of use cases. ANCP capabilities may be specific transmit user information (e.g., ATM cells or Ethernet frames).
to one access technology or technology independent. The set of It excludes overhead that pertains to the physical transmission
capabilities applicable to a given ANCP session are negotiated mechanism (e.g., trellis coding in the case of DSL). It includes
during session startup. TPS-TC (Transport Protocol Specific - Transmission Convergence)
encapsulation; this is zero for ATM encapsulation, and non-zero
for 64/65 encapsulation.
ANCP session (also called an adjacency): A session between a NAS and Line rate: [RFC5851] defined by ITU-T G.993.2. It contains the
an Access Node, beginning with the initiation of the transport complete overhead including Reed-Solomon and trellis coding.
connection by the AN, passing through adjacency negotiation,
discovery and provisioning stages, and continuing with service
control and possible OAM operations until the transport connection
is terminated. There may be more than one ANCP session active
between the NAS and a given AN due to partitioning.
3. Broadband Access Aggregation DSL multi-pair bonding: method for bonding (or aggregating) multiple
xDSL lines into a single bi-directional logical link, henceforth
referred to in this draft as "DSL bonded circuit". DSL "multi-
pair" bonding allows an operator to combine the data rates on two
or more copper pairs, and deliver the aggregate data rate to a
single customer. ITU-T recommendations G.998.1 and G.998.2
respectively describe ATM and Ethernet based multi-pair bonding.
3.1. ATM-based broadband aggregation 2. Broadband Access Aggregation
2.1. ATM-based Broadband Aggregation
The end to end DSL network consists of network service provider (NSP) The end to end DSL network consists of network service provider (NSP)
and application service provider (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 2 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 (NAS), and the access network as shown in Figure 1. Access Server (NAS), and the access network as shown in Figure 2.
Its primary function is to provide end-to-end transport between the Its primary function is to provide end-to-end transport between the
customer premises and the NSP or ASP. customer premises and the NSP or ASP.
The Access Node terminates the DSL signal. It may be in the form of The Access Node terminates the DSL signal. It may be in the form of
a DSLAM in the central office, or a remote DSLAM, or a Remote Access 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 Multiplexer (RAM). The Access Node is the first point in the network
where traffic on multiple DSL lines will be aggregated onto a single where traffic on multiple DSL lines will be aggregated onto a single
network. 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 enforcement 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 synchronization rates.
[RFC5851] provides detailed definition and functions of each network [RFC5851] provides detailed definitions of the functions of each
element in the broadband reference architecture. network element in the broadband reference architecture.
Access Customer Access Customer
<--- Aggregation --> <------- Premises -------> <--- Aggregation --> <------- Premises ------->
Network Network Network Network
+------------------+ +--------------------------+ +------------------+ +--------------------------+
+---------+ +---+ | +-----+ +------+ | |+-----+ +---+ +---------+ | +---------+ +---+ | +-----+ +------+ | |+-----+ +---+ +---------+ |
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
NAS : Network Access Server NAS : Network Access Server
Figure 1: ATM Broadband Aggregation Topology Figure 2: ATM Broadband Aggregation Topology
3.2. Ethernet-based broadband aggregation 2.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. in IEEE 802.ad.
Stacked VLAN tags provide one possible way to create equivalent of Stacked VLAN tags provide one possible way to create equivalent of
"virtual paths" and "virtual circuits" in the aggregation network. "virtual paths" and "virtual circuits" in the aggregation network.
The "outer" vlan can be used to create a form of "virtual path" The "outer" vlan can be used to create a form of "virtual path"
between a given DSLAM and a given NAS. "Inner" VLAN tags create a between a given DSLAM and a given NAS. "Inner" VLAN tags create a
form of "virtual circuit" on a per DSL line basis. This is the 1:1 form of "virtual circuit" on a per DSL line basis. This is the 1:1
VLAN allocation model. An alternative model is to bridge sessions VLAN allocation model. An alternative model is to bridge sessions
from multiple subscribers behind a DSLAM into a single VLAN in the from multiple subscribers behind a DSLAM into a single VLAN in the
aggregation network. This is the N:1 VLAN allocation model. aggregation network. This is the N:1 VLAN allocation model. Section
Architectural and topological models of an Ethernet aggregation 1.6 of [TR-101] provides brief definitions of these two models, while
network in context of DSL aggregation are defined in [TR_101]. section 2.5.1 describes them in more detail.
4. Access Node Control Protocol -- General Aspects 3. 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, and defines additional messages, message contents, and
procedures that are specific to ANCP.
The following are the only GSMPv3 [RFC3292] messages that are
currently used by ANCP.
Event Messages
* Port UP Message
* Port DOWN Message
These messages are used by the ANCP "DSL topology discovery"
capability.
Port Management Messages These messages are used by the ANCP "DSL
line configuration" and ANCP "DSL line testing" capabilities.
Adjacency Protocol Messages These messages are used to bring up a
protocol adjacency between a NAS and an AN.
ANCP modifies and extends some basic GSMPv3 procedures. These
modifications and extensions are summarized below, and described in
more detail in the succeeding sections.
o ANCP provides support for a capability negotiation mechanism
between ANCP peers by extending the GSMPv3 adjacency protocol.
This mechanism and corresponding adjacency message extensions are
defined in section Section 4.5.
o The TCP connection establishment procedure in ANCP deviates
slightly from connection establishment in GSMPv3 as specified in
[RFC3293]. This is described in section Section 4.2.
o ANCP adds content to GSMPv3 messages in the form of additional
fixed fields and Type-Length-Value (TLV) structures. TLVs also
provide flexibility to both GSMPv3 and ANCP-specific messages
because their order in the message and whether or not specific
TLVs are present can vary from one message instance to the next.
4.1. Protocol Version 3.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.
RFC EDITOR'S NOTE: please change the value of sub-version in the RFC EDITOR'S NOTE: please change the value of sub-version in the
above paragraph to 2 (respectively a version field value of 0x32) in above paragraph to 2 (respectively a version field value of 0x32) in
the published specification. For an explanation see the Introduction the published specification. For an explanation see the Introduction
above. above.
4.2. ANCP Transport 3.2. ANCP Transport
This document specifies the use of TCP/IP for transport of ANCP This document specifies the use of TCP/IP for transport of ANCP
messages. Other specifications may introduce additional transports messages. Other specifications may introduce additional transports
in the future. in the future.
In the case of ATM access, a separate PVC (control channel) In the case of ATM access, a separate PVC (control channel)
capable of transporting IP may be configured between NAS and the capable of transporting IP MAY be configured between NAS and the
AN for ANCP messages. AN for ANCP messages.
In the case of an Ethernet access/aggregation network, a typical In the case of an Ethernet access/aggregation network, a typical
practice is to send the Access Node Control Protocol messages over practice is to send the Access Node Control Protocol messages over
a dedicated Ethernet virtual LAN (VLAN) using a separate VLAN a dedicated Ethernet virtual LAN (VLAN) using a separate VLAN
identifier (VLAN ID). identifier (VLAN ID).
When transported over TCP, ANCP messages MUST use the encapsulation When transported over TCP, ANCP messages MUST use the encapsulation
specified for GSMPv3 messages carried over TCP in [RFC3293]. This specified for GSMPv3 messages carried over TCP in [RFC3293]. This
encapsulation consists of a four-byte header field prepended to the encapsulation consists of a four-byte header field prepended to the
ANCP message as shown in Figure 2. ANCP message as shown in Figure 3.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier (0x880C) | Length | | Identifier (0x880C) | Length |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ ANCP Message ~ ~ ANCP Message ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Encapsulation of ANCP Messages Over TCP/IP Figure 3: 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. It does not include the 4-byte encapsulating the ANCP message, not including the 4-byte encapsulating header.
header.
The Access Node MUST initiate the TCP session to the NAS. This is a The Access Node MUST initiate the TCP session to the NAS. This is a
deviation from [RFC3293], which requires the controller to initiate deviation from [RFC3293], which requires the controller to initiate
the TCP connection to the switch. the TCP connection to the switch.
This is necessary to avoid static provisioning on the NAS for all This is necessary to avoid static address provisioning on the NAS
the ANs that are being served by the NAS. It is easier to for all 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 configure a given AN with the single IP address of the NAS that
serves the AN. 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 connection is re-established. until the transport connection is re-established.
4.3. Encoding of Text Fields 3.3. Encoding of Text Fields
In ANCP, all text fields use UTF-8 encoding [RFC3629]. Note that US 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 ASCII characters have the same representation when coded as UTF-8 as
they do when coded according to [US_ASCII]. they do when coded according to [US_ASCII].
4.4. Treatment of Reserved and Unused Fields When extracting text fields from a message, the ANCP agent MUST NOT
assume that the fields are zero-terminated.
3.4. Treatment of Reserved and Unused Fields
ANCP messages contain a number of fields that are unused or reserved. ANCP messages contain a number of fields that are unused or reserved.
Some fields are always unused (typically because they were inherited Some fields are always unused (typically because they were inherited
from GSMPv3 but are not useful in the ANCP context. Others are from GSMPv3 but are not useful in the ANCP context). Others are
unused in the current specification, but are provided for flexibility reserved in the current specification, but are provided for
in future extensions to ANCP. Both reserved and unused fields MUST flexibility in future extensions to ANCP. Both reserved and unused
be set to zeroes by the sender and MUST be ignored by the receiver. 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 Unused bits in a flag field are shown in figures as 'x'. The above
requirement (sender set to zero, receiver ignore) applies to such requirement (sender set to zero, receiver ignore) applies to such
unused bits. unused bits.
4.5. Use of the GSMPv3 Adjacency Protocol 3.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.5.1. ANCP Adjacency Message Format 3.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 4
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 3.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.
ANCP adds several new fields. These are described below the figure.
The semantics and suggested values for the Code, Sender Name,
Receiver Name, Sender Instance, and Receiver Instance fields are as
defined in Section 11 of [RFC3292]. The Sender Port, and Receiver
Port SHOULD be set to 0 by both ends. The pType field MAY be set to
0 (No Partition) or another value depending on local configuration.
The pFlag SHOULD be set to 1 (New Adjacency).
In addition to the modification of the version field, ANCP adds
several new fields. These are described below the figure.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Sub | Message Type | Timer |M| Code | | Ver | Sub | Message Type | Timer |M| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Name | | Sender Name |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
skipping to change at page 13, line 47 skipping to change at page 13, line 45
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Receiver Instance | | Partition ID | Receiver Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | # of Caps | Total Length | | Reserved | # of Caps | Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Capability Fields ~ ~ Capability Fields ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 Figure 4: ANCP Adjacency Message Format
The fields added by ANCP are as follows: The fields added by ANCP are as follows:
Reserved: reserved for use by a future version of this Reserved (8 bits): reserved for use by a future version of this
specification. specification.
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.5.2. The detailed the ANCP session is described in Section 3.5.2. The detailed
format of a capability field is described below. format of a capability field is shown in Figure 5 and described
below.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ ~ ~ ~
~ Capability Data ~ ~ Capability Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Capability Field Figure 5: Capability Field
The sub-fields of this structure are as follows: The sub-fields of this structure are as follows:
Capability Type: indicates the specific capability supported. An Capability Type: indicates the specific capability supported. An
IANA registry exists for values of this sub-field. The values IANA registry exists for values of this sub-field. The values
specified by this document are listed below. specified by this document are listed below.
Capability Length: the number of bytes of data contained in the Capability Length: the number of bytes of data contained in the
Capability Data sub-field, excluding padding. If the definition Capability Data sub-field, excluding padding. If the definition
of a particular capability includes no capability data, the value of a particular capability includes no capability data, the value
skipping to change at page 15, line 20 skipping to change at page 15, line 17
o Capability Type : DSL Topology Discovery = 0x01 o Capability Type : DSL Topology Discovery = 0x01
Access technology: DSL Access technology: DSL
Length (in bytes) : 0 Length (in bytes) : 0
Capability Data : NULL Capability Data : NULL
For the detailed protocol specification of this capability see For the detailed protocol specification of this capability see
Section 5.2. Section 6.
o Capability Type : DSL Line Configuration = 0x02 o Capability Type : DSL Line Configuration = 0x02
Access technology: DSL Access technology: DSL
Length (in bytes) : 0 Length (in bytes) : 0
Capability Data : NULL Capability Data : NULL
For the detailed protocol specification of this capability see For the detailed protocol specification of this capability see
Section 5.3. Section 7.
o Capability Type : DSL Line Testing = 0x04 o Capability Type : DSL Remote Line Connectivity Testing = 0x04
Access technology: DSL Access technology: DSL
Length (in bytes) : 0 Length (in bytes) : 0
Capability Data : NULL Capability Data : NULL
For the detailed protocol specification of this capability see For the detailed protocol specification of this capability see
Section 5.4. Section 8.
4.5.2. ANCP Adjacency Procedures 3.5.2. ANCP Adjacency Procedures
Before beginning adjacency negotiation, the ANCP agent and the
control application "must" agree on the set of capabilities that they
support. This agreement "must" include the transfer of any
application-level information required to build the Capability Data
fields within the Capability structures. Note that none of the
capabilities specified in this document require any such information.
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 25 seconds for interval to be advertised in the adjacency messages is 25 seconds for
ANCP. The actual value SHOULD be configurable and is an ANCP. The actual value SHOULD be configurable and is a deployment
implementation choice. It is RECOMMENDED that both ends specify the choice. It is RECOMMENDED that both ends specify the same timer
same timer value; to achieve this, each end SHOULD compare the timer value; to achieve this, each end SHOULD compare the timer value in
value in the first adjacency message it receives with its own the first adjacency message it receives with its own preferred value
preferred value and agree to use the higher of the two values. That and agree to use the higher of the two values. That is, the node
is, the node that receives a higher timer value than its own SHOULD that receives a higher timer value than its own SHOULD reply in its
reply in its subsequent adjacency messages (such as SYNACK, ACK) with subsequent adjacency messages (such as SYNACK, ACK) with the higher
the higher timer value. timer value.
In the adjacency protocol the version and sub-version fields are used In the adjacency protocol the version and sub-version fields are used
for version negotiation. The version negotiation is performed before for version negotiation. The version negotiation MUST be completed
synchronisation is achieved. In a SYN message the version/ before 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 synchronized. 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 the Code, Sender Name,
Receiver Name, Sender Instance, and Receiver Instance fields are as
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
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
adjacency message for a duration of (3 * Timer value), where the
timer value is specified in the adjacency message, all the state
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 requests. The AN MUST try to re-establish the TCP
connection and both sides MUST attempt to re-establish the adjacency.
The handling defined above will need some modifications when ANCP
graceful restart procedures are defined. These procedures will be
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. The same message capabilities in the adjacency messages they send. The same message
MAY advertise capabilities for any mixture of access technologies. MAY advertise capabilities for any mixture of access technologies.
If a received adjacency message indicates no support for a capability If a received adjacency message indicates no support for a capability
that is supported by the receiving device, it MUST turn off the that is supported by the receiving device, it MUST disable the
capability locally and MUST send an updated adjacency message with capability locally and MUST send an updated adjacency message with
the corresponding capability field omitted to match the received 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 maximal common set of supported capabilities. The agreeing on the maximal common set of supported capabilities. The
adjacency MUST NOT come up if that common set is empty. adjacency MUST NOT come up if that common set is empty.
Subsequent to adjacency startup, if the adjacency times out on either
end, due to not receiving an adjacency message for a duration of (3 *
Timer value), where the timer value is negotiated as described above,
all the state received from the ANCP peer SHOULD be cleaned up, and
the TCP connection SHOULD be closed. The NAS MUST continue to listen
for new connection requests. The AN MUST try to re-establish the TCP
connection and both sides MUST attempt to re-establish the adjacency.
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.6. ANCP General Message Formats The ANCP agent "must" notify the control application whenever an
adjacency is either synchronized or lost. When an adjacency is
synchronized, the notification "must" include the set of capabilities
negotiated with the peer along with any application-level information
conveyed in Capability Data fields.
3.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 6.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | Message Type | Result| Code | | Vers | Sub | Message Type | Result| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier | | Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length | |I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Message Payload ~ ~ Message Payload ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: ANCP General Message Format Figure 6: ANCP General Message Format
4.6.1. The ANCP Message Header 3.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 follows.
Version and Sub-version: The version of the ANCP protocol that was 3.6.1.1. Version and Sub-Version Fields
agreed for the session during adjacency negotiation. For the
values that must be placed into these fields, see Section 4.1.
Message Type: The ANCP message type. Message type values are Together these fields reproduce the version of the ANCP protocol that
registered in a common GSMPv3/ANCP IANA registry. was agreed for the session during adjacency negotiation. See
Section 3.1 for the values to set for version and sub-version for the
present version of this specification.
Result: The Result field is derived from GSMPv3 [RFC3292]. Ignore 3.6.1.2. Message Type Field
(0x0) is a new value added by ANCP. The remaining Result values
below are a subset of those defined for GSMPv3. GSMPv3 expected
the sender of a request to choose between NAck (0x1) and AckAll
(0x2) according to its needs. ANCP specifies what Result value
each request should have. Responses indicate either Success (0x3)
or Failure (0x4) as the case may be.
Ignore: Res = 0x0 - Ignore this field on receipt and follow the This field indicates the ANCP message type. Message type values are
procedures specified for the received message type. registered in a common GSMPv3/ANCP IANA registry.
Nack: Res = 0x1 - Result code indicating that no response is 3.6.1.3. Result Field
expected to the message other than in cases of failure caused
during the processing of the message contents or of the
contained directive(s).
AckAll: Res = 0x2 - Result code indicating that a response to the The Result field is derived from GSMPv3 [RFC3292]. Ignore (0x0) is a
message is requested in all cases. new value added by ANCP. The remaining Result values listed below
are a subset of those defined for GSMPv3. GSMPv3 expected the sender
of a request to choose between NAck (0x1) and AckAll (0x2) according
to its needs. ANCP specifies what Result value each request should
have. Responses indicate either Success (0x3) or Failure (0x4) as
the case may be.
Success: Res = 0x3 - Set in a response message by the receiver of Ignore: Res = 0x0 - Treat this field as a "no operation" and follow
a request to indicate successful execution of all directives in the response procedures specified for the received message type.
the corresponding request message.
Failure: Res = 0x4 - Set in a response message by the receiver of Nack: Res = 0x1 - Result value indicating that a response is
a request to indicate either that there was an error in the expected to the request only in cases of failure caused during the
content of the request message or that one or more directives processing of the message contents or of the contained
in the corresponding request could not be executed directive(s).
successfully.
Code: This field gives further information concerning the result in AckAll: Res = 0x2 - Result value indicating that a response to the
a response message. It is mostly used to pass an error code in a message is requested in all cases.
failure response but can also be used to give further information
in a success response message or an event message. In a request
message, the Code field is not used and MUST be set to zero.
ANCP implementations MAY use any of the Code values specified in Success: Res = 0x3 - Result value indicating that this is a response
the IANA registry "Global Switch Management Protocol version 3 and that the request was executed successfully. The Code field
(GSMPv3) Failure Response Message Name Space" if they appear for a successful result is typically 0, but MAY take on other
applicable. In particular, the values: values as specified for particular message types.
2 Invalid request message (i.e., a properly formed message which Failure: Res = 0x4 - Result value indicating that this is a response
violates the protocol through its timing or direction of and that the request was not executed successfully. The receiver
transmission) of the response SHOULD take further action as indicated by the
Code value and any diagnostic data contained in a Status-Info TLV
included in the response.
4 One or more of the specified ports do not exist 3.6.1.4. Code Field
6 One or more of the specified ports are down This field gives further information concerning the result in a
response message. It is mostly used to pass an error code in a
failure response but can also be used to give further information in
a success response message or an event message. In a request
message, the Code field is not used and MUST be set to zero.
7 Invalid Partition ID A number of code values are specified below. Specification of
additional Code values in extensions or updates to this document MUST
include the following information:
19 Out of resources (e.g. memory exhausted, etc.) o Code value;
30 The limit on the maximum number of point-to-multipoint o One-line description;
connections that the switch can support has been reached
31 The limit on the maximum number of branches that the specified o Where condition detected: (control application or ANCP agent);
point-to-multipoint connection can support has been reached
may unfortunately apply to ANCP usage, where "Port" is interpreted o Further description (if any);
to mean an access line or a Target as defined in Section 6.2.1.
Instead of the value: o Required additional information in the response message;
3 The specified request is not implemented on this switch o Target (control application or ANCP agent at the peer that sent
the original request);
specified by [RFC3292], this specification defines a new value: o Action RECOMMENDED for the receiving ANCP agent
81 Request message type not implemented In addition to any suggested action in the text which follows, the
Code value SHOULD be logged in a MIB. Where an action includes
resending of a request, a given request SHOULD NOT be re-sent more
than once.
This value MAY be sent in a failure response from either the AN or ANCP agents MAY use any of the Code values specified in the IANA
the NAS. This specification also defines the additional values: registry "Global Switch Management Protocol version 3 (GSMPv3)
Failure Response Message Name Space" if they appear applicable. In
particular, the values 2, 3, 4, 6, 7, and 19 appear to be reusable
and are therefore documented below along with a few new ANCP-specific
values. Values 30 and 31 are also reusable, but are more
appropriately documented in a multicast extension document.
82 Transaction identifier out of sequence Code value: 2
83 Malformed message * One-line description: Invalid request message
84 TLV or value not supported by negotiated capability set * Where condition detected: ANCP agent
ANCP extensions defining new code values SHOULD use the range 256 * Further description: The request was a properly formed message
(0x100) through 511 (0x1FF) for this purpose. which violates the protocol through its timing or direction of
transmission. The most likely reason for this outcome in the
field will be a race condition.
The range of values from 256 to 4095 is reserved for IETF use. * Required additional information in the response message: none,
if the response message is of the same type as the request. As
specified in Section 4.2 if the response message is a Generic
Response message.
Partition ID: This field is a 8 bit number which signifies a * Target: ANCP agent at the peer that sent the original request
partition on the AN.
The AN and NAS may agree on the partition ID using one of the * Action RECOMMENDED for the receiving ANCP agent: The original
following possible options: request MAY be re-sent once only after a short delay. Inform
the control application with appropriate identification of the
failed transaction if the second attempt fails or no second
attempt is made.
1 - The partition ID may be configured on the AN and learned by Code value: 6
the NAS in the adjacency message;
2 - The partition ID may be statically configured on the NAS as * One-line description: One or more of the specified ports are
part of configuring the neighbor information. down
Transaction ID: 24-bit field set by the sender of a request message * Where condition detected: control application
to associate a response message with the original request message.
Unless otherwise specified for a given message type, 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
sequencing MUST be maintained independently for each ANCP
adjacency and per message type. Furthermore, it SHOULD be
incremented linearly for each new message of the given type,
cycling back to 1 after running the full range. Each Transaction
ID sequence SHOULD be reinitialized to a random non-zero value
when an adjacency is negotiated. For event messages, the
Transaction ID SHOULD be set to zero.
Unless otherwise specified, the default behaviour for all ANCP * Further description (if any): This Code value indicates a state
responses is that the value of the Transaction ID MUST be copied mismatch between the NAS and AN control applications, possibly
from the corresponding request message. due to a race condition.
I flag and SubMessage Number: An ANCP implementation SHOULD set the * Required additional information in the response message: if the
I Flag and subMessage Number fields to 1 to signify no request identified multiple access lines or the response is a
fragmentation. Generic Response message, then the response MUST contain a
Status-Info TLV encapsulating TLV(s) containing the line
identifier(s) of the access lines that are not operational.
Length: Length of the ANCP message including its header fields and * Target: control application at the peer that sent the original
defined ANCP message body. request
4.6.2. The ANCP Message Body * Action RECOMMENDED for the receiving ANCP agent: indicate the
error and forward the line identifier(s) to the control
application.
Code value: 7
* One-line description: Invalid Partition ID
* Where condition detected: ANCP agent
* Further description: This indicates that the request used a
Partition ID value different from what was determined for this
partition during adjacency negotiation, implying a state
mismatch between the ANCP agents.
* Required additional information in the response message: none,
if the response message is of the same type as the request. As
specified in Section 4.2 if the response message is a Generic
Response message.
* Target: ANCP agent at the peer that sent the original request
* Action RECOMMENDED for the receiving ANCP agent: If multiple
instances of this error occur, the requestor SHOULD cause the
adjacency for the partition to be reset and renegotiated by
sending an adjacency message with pType = 0 and Code = RSTACK
as described in Section 11.3 of [RFC3292].
NOTE: This specification provides no way for the NAS to do a
complete audit of the current state stored on the AN. Hence
renegotiation of the adjacency with pFlag = 2 (connection state
retained at the AN) MAY be attempted, but entails some risk of
state mismatch.
Code value: 19
* One-line description: Out of resources
* Where condition detected: ANCP protocol layer or control
application
* Further description: (e.g., memory exhausted, etc.). This Code
value MUST be reported only by the AN, and indicates a
condition that is probably unrelated to specific access lines
(although it may be related to the specific request).
* Required additional information in the response message: none,
if the response message is of the same type as the request. As
specified in Section 4.2 if the response message is a Generic
Response message.
* Target: ANCP agent at the peer that sent the original request
* Action RECOMMENDED for the receiving ANCP agent: If the NAS
receives this Code value from multiple requests for the same AN
in a short interval, it SHOULD reduce the rate at which it
sends requests in proportion to the rate at which requests are
failing with Code = 19. It MAY retry individual requests. If
only a specific request is failing with Code = 19, the ANCP
agent in the NAS MAY request the control application to
decompose the request into simpler components if this is
possible.
Code value: 81
* One-line description: Request message type not implemented
* Where condition detected: ANCP agent
* Further description: This could indicate a mismatch in protocol
version or capability state. It is also possible that support
of a specific message is optional within some ANCP capability.
* Required additional information in the response message: none,
if the response message is of the same type as the request. As
specified in Section 4.2 if the response message is a Generic
Response message.
* Target: ANCP agent at the peer that sent the original request
* Action RECOMMENDED for the receiving ANCP agent: If the
receiver of this Code value expects that support of the message
type concerned is mandatory according to the capabilities
negotiated for the session, it SHOULD cause the adjacency for
the partition to be reset and renegotiated by sending an
adjacency message with pType = 0 and Code = RSTACK as described
in Section 11.3 of [RFC3292].
Code value: 83
* One-line description: Malformed message
* Where condition detected: ANCP agent
* Further description: This could be the result of corruption in
transit, or an error in implementation at one end or the other.
* Required additional information in the response message: none,
if the response message is of the same type as the request. As
specified in Section 4.2 if the response message is a Generic
Response message.
* Target: ANCP agent at the peer that sent the original request
* Action RECOMMENDED for the receiving ANCP agent: The request
SHOULD be re-sent once to eliminate the possibility of in-
transit corruption.
Code value: 84
* One-line description: Mandatory TLV missing
* Where condition detected: ANCP agent
* Further description: none.
* Required additional information in the response message: the
response message MUST contain a Status-Info message that
encapsulates an instance of each missing mandatory TLV, where
the length is set to zero and the value field is empty (i.e.,
only the four-byte TLV header is present).
* Target: ANCP agent at the peer that sent the original request
* Action RECOMMENDED for the receiving ANCP agent: resend the
message with the missing TLV(s), if possible. Otherwise,
report the error to the control application with an indication
of the missing information required to construct the missing
TLV(s).
Code value: 85
* One-line description: Invalid TLV contents
* Where condition detected: ANCP agent
* Further description: the contents of one or more TLVs in the
request do not match the specifications provided for the those
TLVs.
* Required additional information in the response message: the
response MUST contain a Status-Info TLV encapsulating the
erroneous TLVs copied from the original request.
* Target: ANCP agent at the peer that sent the original request
* Action RECOMMENDED for the receiving ANCP agent: correct the
error and resend the request, if possible. Otherwise, report
the error to the control application with an indication of the
erroneous information associated with the invalid TLV(s).
Code value: 1280
* One-line description: One or more of the specified ports do not
exist
* Where condition detected: control application
* Further description (if any): this may indicate a configuration
mismatch between the AN and the NAS or AAA.
* Required additional information in the response message: if the
request identified multiple access lines or the response is a
Generic Response message, then the response MUST contain a
Status-Info TLV encapsulating TLV(s) containing the rejected
line identifier(s).
* Target: control application at the peer that sent the original
request
* Action RECOMMENDED for the receiving ANCP agent: indicate the
error and forward the line identifiers to the control
application.
ANCP extensions defining new code values SHOULD use the range 256
(0x100) through 511 (0x1FF) for this purpose. The range of values
from 256 to 4095 is reserved for allocation by IETF consensus.
3.6.1.5. Partition ID
The Partition ID field is a 8 bit number which signifies a partition
on the AN. The AN and NAS MAY agree on the partition ID using one of
the following possible options:
o The partition ID MAY be configured on the AN and learned by the
NAS in the adjacency message; or
o The partition ID MAY be statically configured on the NAS as part
of configuring the neighbor information.
3.6.1.6. Transaction ID
The Transaction ID is a 24-bit field set by the sender of a request
message to associate a response message with the original request
message. Unless otherwise specified for a given message type, 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
sequencing MUST be maintained independently for each message type
within each ANCP adjacency. Furthermore, it SHOULD be incremented
linearly for each new message of the given type, cycling back to 1
after running the full range. For event messages, the Transaction ID
SHOULD be set to zero.
Unless otherwise specified, the default behaviour for all ANCP
responses is that the value of the Transaction ID MUST be copied from
the corresponding request message.
3.6.1.7. I flag and SubMessage Number
In GSMPv3 these provide a mechanism for message fragmentation.
Because ANCP uses TCP transport, this mechanism is unnecessary. An
ANCP agent SHOULD set the I Flag and subMessage Number fields to 1 to
signify "no fragmentation".
3.6.1.8. Length
This field MUST be set to the length of the ANCP message in bytes,
including its header fields and message body but excluding the four-
byte encapsulating header defined in Section 3.2.
3.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 can 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 7:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| Type (IANA registered) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (IANA registered) | Length |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~ | |
~ ~ ~ Value ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: General TLV Format Figure 7: 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. Depending on the specification of the TLV, the value of
Length can be zero, a constant for all instances of the TLV, or a
If the TLV contains another TLV followed by other data, the varying quantity.
outer TLV will not be properly parsable unless Length is set 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.
If the outer TLV contains another TLV as its final field it
requires no padding of its own (since the contained TLV
including padding ends on a 4-byte boundary). In this case the
issue is one of consistency rather than parsability, since the
padding of that final TLV could be omitted from Length without
loss of data.
Depending on the specification of the TLV, the value of Length may
be zero, a constant for all instances of the TLV, or a varying
quantity.
Value The actual data carried by the TLV, if any. The value field Value The actual data carried by the TLV, if any. The value field
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.
5. ANCP Capabilities For Digital Subscriber Lines (DSL) 3.7. General Principles for the Design of ANCP Messages
5.1. Overview The GSMPv3 protocol [RFC3292] allows for two messaging constructs to
support request/response interaction:
DSL is a widely deployed access technology for Broadband Access for a. The same message type is used for both the request message and
Next Generation Networks. Specifications such as [TR_059], [TR_058], the response message. The Result and Code field settings are
and [TR_092] describe possible architectures for these access used to differentiate between request and response messages.
networks. The scope of these specifications includes the delivery of
voice, video, and data services.
When deploying value-added services across DSL access networks, b. The request and response messages use two different message
special attention is required to assure quality of service and types.
service control, which implies a tighter coordination between network
elements in the broadband access network without burdening the OSS
layer.
This document specifies basic ANCP capabilities for use specifically The first approach is illustrated by the protocol specifications in
in controlling Access Nodes serving DSL access (Tech Type = 0x05). Section 8.4, the second by specifications in Section 6.4. The
The same ANs could be serving other access technologies (e.g. Metro- purpose of this section is to provide more details about the second
Ethernet, Passive Optical Networking, WiMax), in which case the AN approach in order to allow the use of this messaging construct for
will also have to support the corresponding other-technology-specific the development of additional ANCP extensions.
capabilities. These additional capabilities are not specified here,
but may be specified in other documents.
The DSL capabilities specified in this section are: As Section 3.6 indicated, all ANCP messages other than adjacency
messages share a common header format. When the response message
type is different from that of the request, the specification of the
request message will typically indicate that the Result field is set
to Ignore (0x0) and provide procedures indicating explicitly when the
receiver should generate a response and what message type it should
use.
DSL Topology Discovery: Dynamic discovery of access topology and DSL The Transaction ID field is used to distinguish between multiple
line attributes by the NAS, to support tight QOS control in the request messages of the same type and to associate a response message
access network. to a request. Specifications of ANCP messages for applications not
requiring response correlation SHOULD indicate that the Transaction
ID MUST be set to zero in requests. Applications that require
response correlation SHOULD refer to the Transaction ID behaviour
described in Section 3.6.1.
DSL Line Configuration: Pushing subscriber and service data The specification for a response message SHOULD indicate in all cases
retrieved by the NAS from an OSS system (e.g., RADIUS server) to that value of the Transaction Identifier MUST be set to that of the
the Access Nodes, to simplify OSS infrastructure for service corresponding request message. This allows the requester to
management. establish whether or not correlation is needed (by setting a non-zero
or zero value for the Transaction ID).
DSL Line Testing: NAS controlled, on-demand access- line test 4. Generally Useful ANCP Messages and TLVs
capability (rudimentary end-to-end OAM).
5.1.1. ATM-Specific Considerations This section defines two messages and a number of TLVs that could be
useful in multiple capabilities. In some cases the content is under-
specified, with the intention that particular capabilities spell out
the remaining details.
Topology discovery and line configuration involve the DSL line 4.1. Provisioning Message
attributes. For ATM based access networks, the DSL line on the DSLAM
is identified by the port and PVP/PVC corresponding to the
subscriber. The DSLAMs are connected to the NAS via an ATM access
aggregation network. Since, the DSLAM (Access Node) is not directly
connected to the NAS, the NAS needs a mechanism to learn the DSL line
identifier (more generally referred to as "access loop circuit ID")
corresponding to a subscriber. The access loop circuit ID has no
local significance on the NAS. The ANCP messages for topology
discovery and line configuration carry opaque Access-Loop-Circuit-ID
values which have only local significance on the DSLAMs.
The access loop circuit identifier can be carried as a UTF-8-encoded The Provisioning message is sent by the NAS to the AN to provision
string in the ANCP messages. This allows ANCP to be decoupled from information of global scope (i.e., not associated with specific
the specifics of the underlying access technology being controlled. access lines) on the AN. The Provisioning message has the format
On the other hand, this requires a NAS mechanism by which each such shown in Figure 8. Support of the Provisioning message is OPTIONAL
identifier can be correlated to the context of an aggregation- unless the ANCP agent claims support for a capability that requires
network-facing IP interface (corresponding to the subscriber) on the its use.
NAS. This will typically require local configuration of such IP
interfaces, or of the underlying ATM interfaces.
5.1.2. Ethernet-Specific Considerations 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP/IP Encapsulating Header (Section 3.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header |
+ (Section 3.6.1) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
One possible way of approaching the use of Ethernet technology in the Figure 8: Format of the Provisioning Message
access aggregation network is to recreate the equivalent of Virtual
Paths (VPs) and Virtual Circuits (VCs) by using stacked Virtual LAN
tags. As an example, one can use an "outer" VLAN to create a form of
"virtual path" between a given DSLAM and a given NAS, and then use
"inner" VLAN tags to create a form of "virtual circuit" on a per DSL
line basis. In this case, VLAN tags conveyed in topology discovery
and line configuration messages will allow unique identification of
the DSL line in a straightforward manner, assuming the VLAN tags are
not translated in some way by the aggregation network, and are unique
across physical ports.
However, some carriers do not wish to use this "connection oriented" The message header field settings given below are REQUIRED in the
approach. Therefore, an alternative model is to bridge sessions from Provisioning message. The remaining message header fields MUST be
multiple subscribers behind a DSLAM to a single VLAN in the set as specified in Section 3.6.1. Which TLVs to carry in the
aggregation network. This is the N:1 model. In this model, or in Provisioning message is specified as part of the specification of the
the case where user traffic is sent untagged, the Access Node needs capabilities that use that message. The Provisioning message MAY be
to insert the exact identity of the DSL line in the topology used to carry data relating to more than one capability at once,
discovery and line configuration messages, and then have a mechanism assuming that the capabilities concerned can co-exist and have all
by which this can be correlated to the context of an aggregation- been negotiated during adjacency establishment.
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
that a DSLAM (Access Node) typically inserts the access loop circuit
ID in subscriber signaling messages relayed to the NAS (i.e. DHCP or
PPPoE discovery messages).
Section 5.2.3.3 defines TLVs to represent the "access loop circuit Message Type: MUST be set to 93.
ID".
5.2. ANCP Based DSL Topology Discovery Result: MUST be set to 0x0 (Ignore).
5.2.1. Goals Code: MUST be set to zero.
[TR_059] discusses various queuing/scheduling mechanisms to avoid Transaction ID: MUST be populated with a non-zero value chosen in
congestion in the access network while dealing with multiple flows the manner described in Section 3.6.1.6.
with distinct QoS requirements. Such mechanisms require that the NAS
gains knowledge about the topology of the access network, the various
links being used and their respective net data rates. Some of the
information required is somewhat dynamic in nature (e.g. DSL sync
rate, and therefore also the net data rate), hence cannot come from a
provisioning and/or inventory management OSS system. Some of the
information varies less frequently (e.g. capacity of a DSLAM uplink),
but nevertheless needs to be kept strictly in sync between the actual
capacity of the uplink and the image the NAS has of it.
The following section describes ANCP messages that allow the Access If the AN can process the message successfully and accept all the
Node (e.g., DSLAM) to communicate access network topology information provisioning directives contained in it, the AN MUST NOT send any
and any corresponding updates to the NAS. response.
Some of the parameters that can be communicated from the DSLAM to the Unless otherwise specified for a particular capability, if the AN
NAS include DSL line state, actual upstream and downstream net data fails to process the message successfully it MUST send a Generic
rates of a synchronized DSL link, maximum attainable upstream and Response message (Section 4.2) indicating failure and providing
downstream net data rates, interleaving delay etc. Topology appropriate diagnostic information.
discovery is specifically important when the net data rate of the DSL
line changes over time. The DSL net data rate may be different every
time the DSL modem is turned on. Additionally, during the time the
DSL modem is active, data rate changes can occur due to environmental
conditions (the DSL line can get "out of sync" and can retrain to a
lower value).
5.2.2. Message Flow 4.2. Generic Response Message
To provide expected service levels, the NAS needs to learn the This section defines the Generic Response message. The Generic
initial attributes of the DSL line before the subscriber can log in Response message MAY be specified as the appropriate response to a
and access the services provisioned for the subscription. When a DSL message defined in an extension to ANCP, instead of a more specific
line initially comes up or resynchronizes to a different rate, the response message. As a general guideline, specification of the
DSLAM generates and transmits an ANCP Port UP Event message to the Generic Response message as a response is appropriate where no data
NAS. The extension field in the message carries the TLVs containing needs to be returned to the peer other than a result (success or
DSL line specific parameters. Upon loss of signal on the DSL line, failure), plus, in the case of a failure, a code indicating the
an ANCP Port DOWN message is generated by the DSLAM and sent to the reason for failure and a limited amount of diagnostic data.
NAS. Figure 7 summarizes the interaction. Depending on the particular use case, the Generic Response message
MAY be sent by either the NAS or the AN.
1. NAS ------------------------ Access ----- Home ----- Subscriber Support of the Generic Response message, both as sender and as
Node Gateway receiver, is REQUIRED for all ANCP agents, regardless of what
capabilities they support.
<----- Port UP(Event Message) <----- DSL The AN or NAS MAY send a Generic Response message indicating a
(default line parameters) Signal failure condition independently of a specific request before closing
the adjacency as a consequence of that failure condition. In this
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
receiver MAY record the information contained in the Status-Info TLV
for management use.
2. NAS ------------------------ Access ----- Home ----- Subscriber The format of the Generic Response message is shown in Figure 9
Node Gateway 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP/IP Encapsulating Header (Section 3.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header |
+ (Section 3.6.1) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access line identifying TLV(s) |
+ (copied from original request) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status-Info TLV |
~ (Section 6.2.3) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<----- Port UP (Event Message) <----- DSL NOTE: TLVs MAY be in a different order from what is shown in this
(updated line parameters) Resynch figure.
3. NAS ------------------------ Access ----- Home ----- Subscriber Figure 9: Structure of the Generic Response Message
Node Gateway
<--- Port DOWN (Event Message) <---- DSL This document specifies the following header fields. The remaining
Loss of Signal fields in the ANCP general message header MUST be set as specified in
Section 3.6.1.
Figure 7: ANCP Message Flow For DSL Topology Discovery Message Type: MUST be set to 91.
The Event message with Port UP message type (80) is used for Result: MUST be set to 0x3 (Success) or 0x4 (Failure).
conveying DSL line attributes to the NAS. This message with relevant
extensions is defined in the next section.
5.2.3. Specification of the ANCP DSL Topology Discovery Capability Code: MUST be set to zero for success or an appropriate non-zero
value for failure.
5.2.3.1. Protocol Requirements Transaction ID: MUST be copied from the message to which this
message is a response.
The DSL topology discovery capability is assigned capability type If the original request applied to a specific access line or set of
0x01. No capability data is associated with this capability. lines, the TLVs identifying the line(s) and possibly the user MUST be
Implementations of the DSL topology discovery capability MUST support copied into the Generic Response message at the top level.
the following ANCP protocol elements:
o ANCP Port UP and Port DOWN Event messages, which are based on the The Status-Info TLV MAY be present in a success response, to provide
GSMPv3 [RFC3292] messages of the same name but include capability- a warning as defined for a specific request message type. It MUST be
specific modifications and extensions (Section 5.2.3.2). present in a failure response. See Section 4.5 for a detailed
description of the Status-Info TLV. The actual contents will depend
on the request message type this message is responding to and the
value of the Code field.
o The procedures associated with these messages and their contents To prevent an infinite loop of error responses, if the Generic
(Section 5.2.3.2.1). Response message is itself in error, the receiver MUST NOT generate
an error response in return.
o Access-Loop-Circuit-ID TLV; 4.3. Target TLV
o Access-Loop-Remote-Id TLV; Type: 0x1000 to 0x1020 depending on the specific content. Only
0x1000 has been assigned in this specification (see below).
Support of any specific variant of the Target TLV is OPTIONAL
unless the ANCP agent claims support for a capability that
requires its use.
o Access-Aggregation-Circuit-ID-ASCII TLV; Description: The Target TLV (0x1000 - 0x1020) is intended to be a
o Access-Aggregation-Circuit-ID-Binary TLV; general means to represent different types of objects.
o DSL-Line-Attributes TLV; Length: Variable, depending on the specific object type.
o DSL-Type TLV; Value: Target information as defined for each object type. The
Value field MAY consist of sub-TLVs.
o Actual-Net-Data-Upstream TLV; TLV Type 0x1000 is assigned to a variant of the Target TLV
representing a single access line and encapsulating one or more sub-
TLVs identifying the target. Figure 10 is an example illustrating
the TLV format for a single port identified by an Access-Loop-
Circuit-ID TLV (0x0001) (Section 5.1.2.1).
o Actual-Net-Data-Rate-Downstream TLV; 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 = 0x1000 |Length = Circuit-ID Length + 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Minimum-Net-Data-Rate-Upstream TLV; Figure 10: Example of Target TLV For Single Access Line
o Minimum-Net-Data-Rate-Downstream TLV; 4.4. Command TLV
o Attainable-Net-Data-Rate-Upstream TLV; Type: 0x0011
o Attainable-Net-Data-Rate-Downstream TLV; Description: The Command TLV (0x0011) is intended to be a general
means of encapsulating one or more command directives in a TLV
oriented message. The semantics of the command can be specified
for each message type using it. I.e., the specification of each
message type that can carry the Command TLV is expected to define
the meaning of the content of the payload, although re-use of
specifications is, of course, permissible when appropriate.
Support of any specific variant of the Command TLV is OPTIONAL
unless the ANCP agent claims support for a capability that
requires its use.
o Maximum-Net-Data-Rate-Upstream TLV; Length: Variable, depending on the specific contents.
o Maximum-Net-Data-Rate-Downstream TLV; Value: Command information as defined for each message type. The
field MAY include sub-TLVs. The contents of this TLV MUST be
specified as one "command" or alternatively a sequence of one or
more "commands", each beginning with a one-byte Command Code and
possibly including other data following the Command Code. An IANA
registry has been established for Command Code values. This
document reserves the Command Code value 0 as an initial entry in
the registry.
o Minimum-Net-Low-Power-Data-Rate-Upstream TLV; 4.5. Status-Info TLV
o Minimum-Net-Low-Power-Data-Rate-Downstream TLV; Name: Status-Info
o Maximum-Interleaving-Delay-Upstream TLV; Type: 0x0106
o Maximum-Interleaving-Delay-Downstream TLV; Description: The Status-Info-TLV is intended to be a general
container for warning or error diagnostics relating to commands
and/or requests. It is a supplement to the Code field in the ANCP
general header. The specifications for individual message types
MAY indicate the use of this TLV as part of responses,
particularly for failures. As mentioned above, the Generic
Response message will usually include an instance of the Status-
Info TLV. Support of the Status-Info TLV, both as sender and as
receiver, is REQUIRED for all ANCP agents, regardless of what
capabilities they support.
o Actual-Interleaving-Delay-Upstream TLV; Length: Variable, depending on the specific contents.
o Actual-Interleaving-Delay-Downstream TLV; Value: The following fixed fields. In addition, sub-TLVs MAY be
appended to provide further diagnostic information.
o DSL-line-state TLV; Reserved (one byte): see Section 3.4 for handling of reserved
fields.
o Access Loop Encapsulation TLV. Msg Type: Message Type of the request for which this TLV is
providing diagnostics.
The TLVs listed above are specified in Section 5.2.3.3. Error Message Length: Number of bytes in the error message,
excluding padding. This MAY be zero if no error message is
provided.
5.2.3.2. ANCP Port UP and Port DOWN Event Message Descriptions Error Message: Human-readable string providing information about
the warning or error condition. Padded with zeroes as
necessary to extend to a four-byte word boundary.
The ANCP Port UP and Port DOWN Event messages are derived from the Section 3.6.1.4 provides recommendations for what TLVs to add in
GSMPv3 Event message shown in Section 9 of [RFC3292]. The modified the Status-Info TLV for particular values of the message header
format used for DSL topology discovery is shown in Figure 8. Code field.
Figure 11 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP/IP Encapsulating Header (Section 4.2) | | TLV Type = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header |
+ (Section 4.4) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Label +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length | | Reserved | Msg Type | Error Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs | Extension Block length (bytes)| | Error Message (padded to 4 byte boundary) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | optional sub-TLVs... |
~ TLVs ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Format Of the ANCP Port UP and Port DOWN Event Messages Figure 11: The Status-Info TLV
For DSL Topology Discovery
See Section 4.6 for a description of the ANCP general message header. 5. Introduction To ANCP Capabilities For Digital Subscriber Lines (DSL)
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
field MUST be set to 0 (signifying Ignore). The 24-bit Transaction
Identifier field MUST be set to 0. Other fields in the general
header MUST be set as described in Section 4.6.
The Port, Port Session Number, and Event Sequence Number fields are DSL is a widely deployed access technology for Broadband Access for
not used by the DSL Topology Discovery capability. The Label field Next Generation Networks. Specifications such as [TR-059], [TR-058],
(including the Stacked Label Indicator and the unused flags at the and [TR-092] describe possible architectures for these access
start of the Label field), is also unused, and MUST be treated as an networks. The scope of these specifications includes the delivery of
unused fixed 8-byte field. The handling of unused/reserved fields is voice, video, and data services.
described in Section 4.4.
The remaining message fields are described as follows: The next three sections of this document specify basic ANCP
capabilities for use specifically in controlling Access Nodes serving
DSL access (Tech Type = 0x05). The same ANs could be serving other
access technologies (e.g. Metro-Ethernet, Passive Optical
Networking, WiMax), in which case the AN will also have to support
the corresponding other-technology-specific capabilities. Those
additional capabilities are outside the scope of the present
document.
Extension Flags: The flag bits denoted by 'x' are currently 5.1. DSL Access Line Identification
unspecified and reserved.
Message Type: Message Type has the same value as in the general Most ANCP messages involve actions relating to a specific access
header (i.e., 80 or 81). line. Thus it is necessary to describe how access lines are
identified within those messages. This section defines four TLVs for
that purpose and provides an informative description of how they are
used.
Tech Type: MUST be set to 0x05 (DSL). 5.1.1. Control Context (Informative)
Block Length: unused, see Section 4.4. This field was defined in Three types of identification are described in [TR-101] and provided
early implementations, but limits what follows to 255 bytes, which for in the TLVs defined in this section:
is not sufficient.
# of TLVs: the number of TLVs that follow, not counting TLVs o identification of an access line by its logical appearance on the
encapsulated within other TLVs. user side of the Access Node;
Extension Block Length: the total length of the TLVs carried in the o identification of an access line by its logical appearance on the
extension block in bytes, including any padding within individual NAS side of the Access Node; and
TLVs.
TLVs: two or more TLVs to identify a DSL line and define its o identification down to the user or host level as a supplement to
characteristics. access line identification in one of the other two forms.
5.2.3.2.1. Procedures All of these identifiers originate with the AN control application,
during the process of DSL topology discovery. The control
application chooses which identifiers to use and the values to place
into them on a line-by-line basis, based on AN configuration and
deployment considerations.
The GSMP Event message with Port UP message type (80) is used for Aside from its use in ANCP signalling, access line identification is
conveying DSL line attributes to the NAS. The message SHOULD be also used in DHCP transactions involving hosts served by DSL. Either
generated when a line first comes UP, or any of the attributes of the the AN or the NAS can serve as a DHCP relay node. [TR-101] requires
line change e.g. the line re-trains to a different rate or one or the AN or NAS in this role to add access line identification in
more of the configured line attributes are administratively modified. Option 82 (Information) to each DHCP request it forwards to the DHCP
Also, when the ANCP session first comes up, the DSLAM SHOULD transmit server. It is desirable for efficiency that the identification used
a Port UP message to the NAS for each line that is up. When a DSL in this signalling should be the same as the identification used in
line goes down (idle or silent), the DSLAM SHOULD transmit an Event ANCP messages.
message with Port DOWN message type (81) to the NAS. It is
recommended that the DSLAMs use a dampening mechanism per DSL line to
control the rate of state changes per DSL line, communicated to the
NAS.
If a Port UP message with a Result field set to 0 is received by the From the point of view of ANCP itself, the identifiers are opaque.
NAS and the NAS is able to process the message correctly, the NAS From the point of view of the AN control application, the syntax for
MUST NOT generate any ANCP message in response to the Port UP. If the user-side access line identifier is the same as specified in
the Port UP message received cannot be processed correctly by the NAS Section 3.9.3 of [TR-101] for DHCP Option 82. The syntax for the
(e.g. the message is malformed) the NAS MAY respond with an ANCP ASCII form of the NAS-side access line identifier will be similar.
Generic Response message (Section 6.1.3) containing the reason for
the failure.
In the case of bonded copper loops to the customer premise (as per Access line identification by logical appearance on the user side of
the DSL multi-pair bonding described by [G.988.1] and [G.988.2]), the the Access Node will always identify a DSL loop uniquely.
DSLAM MUST report the aggregate net data rate and other attributes Identification by the logical appearance on the NAS side of the
for the DSL bonded circuit (represented as a single logical port) to Access Node is unique only if there is a one-to-one mapping between
the NAS in a Port UP message. Any change in the aggregate net data the appearances on the two sides and no identity-modifying
rate of the DSL bonded circuit (due to a change in net data rate or aggregation between the AN and the NAS. In other cases, and in
state of individual constituent DSL lines) MUST be reported by the particular in the case of Ethernet aggregation using the N:1 VLAN
DSLAM to the NAS in a Port UP message. The DSLAM MUST also report model, the user-side access line identification is necessary, but the
the aggregate state of the DSL bonded circuit to the NAS via Port UP NAS-side identification is potentially useful information allowing
and Port DOWN messages. the NAS to build up a picture of the aggregation network topology.
The definition of TLVs in the next section contains some additional Additional identification down to the user or host level is intended
procedural information. to supplement rather than replace either of the other two forms of
identification.
5.2.3.3. TLVs For DSL Topology Discovery Sections 3.8 and 3.9 of [TR-101] are contradictory on this point.
It is assumed here that Section 3.9 is meant to be authoritative.
The following TLVs are currently defined for DSL Topology Discovery, The user-level identification takes the form of an administered
but may be reused for other capabilities. string which again is opaque at the ANCP level.
5.2.3.3.1. Access-Loop-Circuit-ID TLV The NAS control application will use the identifying information it
receives from the AN directly for some purposes. For examples, see
the introductory part of Section 3.9 of [TR-101]. For other
purposes, the NAS will build a mapping between the unique access line
identification provided by the AN, the additional identification of
the user or host (where provided), and the IP interface on a
particular host. For access lines with static IP address assignment
that mapping could be configured instead.
Name: Access-Loop-Circuit-ID 5.1.2. TLVs For DSL Access Line Identification
Type: 0x0001 This section provides a normative specification of the TLVs that ANCP
provides to carry the types of identification just described. The
Access-Loop-Circuit-ID TLV identifies an access line by its logical
appearance on the user side of the Access Node. Two alternatives,
the Access-Aggregation-Circuit-ID-ASCII TLV and the Access-
Aggregation-Circuit-ID-Binary TLV, identify an access line by its
logical appearance on the NAS side of the Access Node. It is
unlikely that a given AN uses both of these TLVs, either for the same
line or for different lines, since they carry equivalent information.
Finally, the Access-Loop-Remote-Id TLV contains an operator-
configured string that uniquely identifies the user on the associated
access line, as described in Sections 3.9.1 and 3.9.2 of [TR-101].
Description: a locally administered human-readable string generated As normative requirements on ANCP agents conforming to this section:
by or configured on the Access Node, identifying the corresponding
access loop logical port. The access loop circuit ID has local
significance at the Access Node. The exact usage on the NAS is
beyond the scope of this document. The format used for local loop
identification in ANCP messages MUST be identical to what 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].
The local loop can be ATM based or Ethernet based. Section 3.9 of o ANCP agents MUST be able to build and send the Access-Loop-
[TR_101] recommends default formats for either case, with the Circuit-ID TLV, the Access-Loop-Remote-Id TLV, and either the
intention that the Access Node automatically generates the Access-Aggregation-Circuit-ID-ASCII TLV or the Access-Aggregation-
identifier for a given access line using the default format unless Circuit-ID-Binary TLV (implementation choice), when passed the
an identifier has been configured by the operator. The associated information from the AN control application.
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 SP "atm" SP slot "/" port ":" vpi "." o ANCP agents MUST be able to receive all four TLV types, extract
vci the relevant information, and pass it to the control application.
where the meanings of the terms should be obvious from their o If the Access-Loop-Remote-Id TLV is present in a message, it MUST
names. be accompanied by an Access-Loop-Circuit-ID TLV and/or an Access-
Aggregation-Circuit-ID-xxx TLV with two VLAN identifiers.
For a local loop which is Ethernet based (and tagged), the The Access-Loop-Remote-Id TLV is not enough to identify an
remainder of the string consists of slot/port and incoming VLAN access line uniquely on its own. As indicated above, an
tag (if any) describing the access line appearance on the Access Access-Aggregation-Circuit-ID-xxx TLV with two VLAN identifiers
Node. The syntax of the recommended default format in ABNF may or may not identify an access line uniquely, but this is up
notation is: to the control application to decide.
Access-Node-Identifier SP "eth" SP slot "/" port [":" vlan-id] o If the Access-Aggregation-Circuit-ID-xxx TLV is present in a
message with just one VLAN identifier, it MUST be accompanied by
an Access-Loop-Circuit-ID TLV.
This is a mandatory TLV. 5.1.2.1. Access-Loop-Circuit-ID TLV
Type: 0x0001
Description: a locally administered human-readable string generated
by or configured on the Access Node, identifying the corresponding
access loop logical port on the user side of the Access Node.
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.1.2.2. Access-Loop-Remote-Id TLV
Name: Access-Loop-Remote-Id
Type: 0x0002 Type: 0x0002
Description: This is an optional TLV. This contains an operator- Description: an operator-configured string that uniquely identifies
configured string that uniquely identifies the user on the the user on the associated access line, as described in Sections
associated access line, as described in Section 3.9.2 of [TR_101]. 3.9.1 and 3.9.2 of [TR-101].
The exact usage on the NAS is out of scope of this document. It
is desirable that the format used for the field be similar to what
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].
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.1.2.3. Access-Aggregation-Circuit-ID-Binary TLV
Name: Access-Aggregation-Circuit-ID-Binary
Type: 0x0006 Type: 0x0006
Description: This TLV identifies or partially identifies a specific
access line by means of its logical circuit identifier on the NAS
side of the Access Node.
Description: For ethernet access aggregation, where a per-subscriber For Ethernet access aggregation, where a per-subscriber (stacked)
(stacked) VLAN can be applied (1:1 model defined in [TR_101]), the VLAN can be applied (1:1 model as defined in [TR-101]), the TLV
VLAN stack provides a convenient way to uniquely identify the DSL contains two value fields. Each field carries a 12-bit VLAN
line. The outer VLAN is equivalent to virtual path between a identifier (which is part of the VLAN tag defined by IEEE 802.1Q).
DSLAM and the NAS and inner VLAN is equivalent to a virtual The first field MUST carry the inner VLAN identifier, while the
circuit on a per DSL line basis. In this scenario, any subscriber second field MUST carry the outer VLAN identifier.
data received by the Access Node and transmitted out the uplink to
the aggregation network will be tagged with the VLAN stack
assigned by the Access Node.
The Access-Aggregation-Circuit-ID-Binary is illustrated in When the N:1 VLAN model is used, only one VLAN tag is available.
Figure 9 (below). This TLV carries the VLAN tags assigned by the For the N:1 model, the Access-Aggregation-Circuit-ID-Binary TLV
access node in the ANCP messages. The VLAN tags can uniquely contains a single value field, which MUST carry the 12-bit VLAN
identify the DSL line being referred to in the ANCP messages, identifier derived from the single available VLAN tag.
assuming the VLAN tags are not in any way translated in the
aggregation network and are unique across physical ports. Each 32
bit unsigned integer contains a 12 bit VLAN identifier (which is
part of the VLAN tag defined by IEEE 802.1Q).
Also, in case of an ATM aggregation network, where the DSLAM is In the 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 VPI and VCI on the DSLAM uplink correspond uniquely
uplink (and correspond uniquely to the DSL line on the DSLAM). to the DSL line on the DSLAM. The Access-Aggregation-Circuit-ID-
Binary TLV MAY be used to carry the VPI and VCI. The first value
field of the TLV MUST carry the VCI, while the second value field
MUST carry the VPI.
This TLV is optional. Each identifier MUST be placed in the low-order bits of its
respective 32-bit field, with the higher-order bits set to zero.
The ordering of the bits of the identifer MUST be the same as when
the identifier is transmitted on the wire to identify an Ethernet
frame or ATM cell.
Length: 8 bytes The Access-Aggregation-Circuit-ID-Binary is illustrated in
Figure 12.
Value: two 32 bit unsigned integers Length: 4 or 8 bytes
Value: one or two 32-bit binary fields.
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 = 0x0006 | Length = 8 | | TLV Type = 0x0006 | Length = 4 or 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner VLAN tag or VCI | | Single VLAN Identifier, inner VLAN identifier, or VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer VLAN tag or VPI | | Outer VLAN identifier or VPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: The Access-Aggregation-Circuit-ID-Binary TLV
Figure 9: The Access-Aggregation-Circuit-ID-Binary TLV 5.1.2.4. Access-Aggregation-Circuit-ID-ASCII TLV
5.2.3.3.4. Access-Aggregation-Circuit-ID-ASCII TLV Type: 0x0003
Name: Access-Aggregation-Circuit-ID-ASCII Description: This TLV transmits the ASCII equivalent of the Access-
Aggregation-Circuit-ID-Binary TLV. As mentioned in the previous
section, the AN control application will use a format similar to
that specified in Section 3.9.3 of [TR-101] for the format of the
"circuit-id".
Type: 0x0003 As an extension to the present document, the Access Node could
convey to the NAS the characteristics (e.g., bandwidth) of the
uplink on the Access Node. This TLV or the binary equivalent
defined above then serves the purpose of uniquely identifying the
uplink whose characteristics are being defined. The present
document does not specify the TLVs needed to convey the uplink
characteristics.
Description: This field contains information pertaining to an uplink Length: up to 63 bytes
on the Access Node. For Ethernet access aggregation, assuming the
Access Node assigns VLAN tags (1:1 model), typical ABNF format for
the string is:
Access-Node-Identifier SP "eth" SP slot "/" port [":" inner- Value: ASCII string
vlan-id] [":" outer-vlan-id]
The slot/port corresponds to the ethernet uplink on the Access 6. ANCP Based DSL Topology Discovery
Node towards the NAS.
For an ATM aggregation network, the typical format for the string Section 3.1 of [RFC5851] describes the requirements for the DSL
is: Topology Discovery capability.
Access-Node-Identifier SP "atm" SP slot "/" port ":" vpi "." 6.1. Control Context (Informative)
vci
This TLV allows the NAS to associate the information contained in The AN control application in the DSLAM requests ANCP to send a DSL-
the ANCP messages to the DSL line on the Access Node. specific Port Up message to the NAS under the following
circumstances:
If the Access Node inserts this string in the ANCP messages, when o when a new adjacency with the NAS is established, for each DSL
referring to local loop characteristics (e.g. DSL line in case of loop that is synchronized at that time;
a DSLAM), then it should be able to map the information contained
in the string uniquely to the local loop (e.g. DSL line).
On the NAS, the information contained in this string can be used o subsequent to that, whenever a DSL loop resynchronizes; and
to derive an aggregation-network-facing construct (e.g. an IP
interface) corresponding to the local loop (e.g. DSL line). The
association could be based on local configuration on the NAS.
The Access Node can also convey to the NAS the characteristics o whenever the AN control application wishes to signal that a line
(e.g., bandwidth) of the uplink on the Access Node. This TLV then attribute has changed.
serves the purpose of uniquely identifying the uplink whose
characteristics are being defined. This version of the present
document does not specify the TLVs needed to convey the uplink
characteristics, in the same way that the DSL-Line-Attributes TLV
and the TLVs encapsulated within it convey the characteristics of
the subscriber access line.
This TLV is optional. The AN control application in the DSLAM requests ANCP to send a DSL-
specific Port Down message to the NAS under the following
circumstances:
Length: up to 63 bytes o when a new adjacency with the NAS is established, for each DSL
loop that is provisioned but not synchronized at that time;
Value: ASCII string o whenever a DSL loop that is equipped in an AN but administratively
disabled is signalled as "IDLE"; and
5.2.3.3.5. DSL-Line-Attributes TLV (Mandatory) o subsequent to that, whenever a DSL loop loses synchronization.
Name: DSL-Line-Attributes
Type: 0x0004 The AN control application passes information to identify the DSL
loop to ANCP to include in the Port Up or Port Down message, along
with information relating to DSL loop attributes.
Description: This is a mandatory TLV providing attribute values for In the case of bonded copper loops to the customer premise (as per
a DSL line serving a subscriber. DSL multi-pair bonding described by [G.988.1] and [G.988.2]), the AN
control application requests that ANCP send DSL-specific Port Up and
Port Down messages for the aggregate "DSL bonded circuit"
(represented as a single logical port) as well as the individual DSL
loops of which it is comprised. The information relating to DSL line
attributes that is passed by the AN control application is aggregate
information.
Length: variable (up to 1024 bytes) ANCP generates the DSL-specific Port Up or Port Down message and
transfers it to the NAS. ANCP on the NAS side passes an indication
to the NAS control application that a DSL Port Up or Port Down
message has been received along with the information contained in the
message.
Value: one or more encapsulated TLVs corresponding to DSL line The NAS control application updates its view of the DSL loop state,
attributes. The DSL-Line-Attributes TLV MUST contain the performs any required accounting operations, and uses any included
mandatory TLVs described below when it is present in a Port UP line attributes to adjust the operation of its queueing/scheduling
message. It MAY contain the optional TLVs described below when it mechanisms as they apply to data passing to and from that DSL loop.
is present in a Port UP message.
When the DSL-Line-Attributes TLV is present in a Port DOWN message Figure 13 summarizes the interaction.
it SHOULD NOT include any TLVs other than DSL-Type and DSL-Line-
State.
5.2.3.3.6. TLVs Delivering Line Attributes 1. Home Access NAS
Gateway Node
The TLVs which follow convey DSL line attributes. They MUST be -----------> -------------------------->
encapsulated within the DSL-Line-Attributes TLV when they are carried DSL Port Up (Event message)
in a Port UP or Port DOWN message. Signal (default line parameters)
5.2.3.3.6.1. DSL-Type TLV (Mandatory) 2. Home Access NAS
Gateway Node
Name: DSL-Type -----------> -------------------------->
DSL Port Up (Event message)
Resynch (updated line parameters)
3. Home Access NAS
Gateway Node
-----------> -------------------------->
Loss of Port Down (Event message)
DSL Signal (selected line parameters)
Figure 13: ANCP Message Flow For DSL Topology Discovery
6.2. Protocol Requirements
The DSL topology discovery capability is assigned capability type
0x0001. No capability data is associated with this capability.
6.2.1. Protocol Requirements On the AN Side
The AN-side ANCP agent MUST be able to create DSL-specific Port Up
and Port Down messages according to the format specified in
Section 6.3.
The AN-side ANCP agent MUST conform to the normative requirements of
Section 5.1.2.
The AN-side ANCP agent "must" be able to accept any information
passed to it by the AN control application that can validly be
included in any of the line attribute TLVs specified in Section 6.5,
MUST package that information as TLVs, and MUST include these TLVs,
encapsulated in the DSL-Line-Attributes TLV, within the Port Up or
Port Down message.
The AN-side ANCP agent MUST follow the AN-side procedures associated
with DSL-specific Port Up and Port Down messages as they are
specified in Section 6.4.
6.2.2. Protocol Requirements On the NAS Side
The NAS-side ANCP agent MUST be able to receive and validate DSL-
specific Port Up and Port Down messages according to the format
specified in Section 6.3.
The NAS-side ANCP agent MUST conform to the normative requirements of
Section 5.1.2.
The NAS-side ANCP agent MUST follow the NAS-side procedures
associated with DSL-specific Port Up and Port Down messages as they
are specified in Section 6.4.
The NAS-side ANCP agent MUST be able to extract the information
contained in any of the TLVs specified in Section 6.5 and "must" be
able to make that information available to the NAS control
application.
6.3. ANCP Port UP and Port DOWN Event Message Descriptions
The ANCP Port UP and Port DOWN Event messages are derived from the
GSMPv3 Event message shown in Section 9 of [RFC3292]. The modified
format used for DSL topology discovery is shown in Figure 14.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP/IP Encapsulating Header (Section 3.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header |
+ (Section 3.6.1) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port (unused) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number (unused) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Sequence Number (unused) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+--- Label (8 bytes, unused) ---+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Message Type | Tech Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs | Extension Block length (bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access line identifying TLV(s) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSL-Line-Attributes TLV |
~ (MANDATORY in Port Up, OPTIONAL in Port Down) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NOTE: TLVs MAY be in a different order from what is shown in this
figure.
Figure 14: Format Of the ANCP Port Up and Port Down Event Messages
For DSL Topology Discovery
See Section 3.6.1 for a description of the ANCP general message
header. 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
field MUST be set to 0 (signifying Ignore). The 24-bit Transaction
Identifier field MUST be set to 0. Other fields in the general
header MUST be set as described in Section 3.6.
The Port, Port Session Number, and Event Sequence Number fields are
not used by the DSL Topology Discovery capability. The Label field
(including the Stacked Label Indicator and the unused flags at the
start of the Label field), is also unused, and MUST be treated as an
unused fixed 8-byte field. The handling of unused/reserved fields is
described in Section 3.4.
The remaining message fields belong to the "extension block" added to
the original GSMPv3 message by ANCP, and are described as follows:
Extension Flags: The flag bits denoted by 'x' are currently
unspecified and reserved.
Message Type: Message Type has the same value as in the general
header (i.e., 80 or 81).
Tech Type: MUST be set to 0x05 (DSL).
# of TLVs: the number of TLVs that follow, not counting TLVs
encapsulated within other TLVs.
Extension Block Length: the total length of the TLVs carried in the
extension block in bytes, including any padding within individual
TLVs.
TLVs: one or more TLVs to identify a DSL line and zero or more TLVs
to define its characteristics.
6.4. Procedures
6.4.1. Procedures On the AN Side
The AN-side ANCP agent MUST create and transmit a DSL-specific Port
Up or Port Down message when requested by the AN control application
and presented with the information needed to build a valid message,
except if transmission is inhibited by a rate-dampening mechanism.
It is RECOMMENDED that the Access Node use a dampening mechanism per
DSL loop to control the rate at which state changes are communicated
to the NAS.
At the top level, the extension block within a DSL-specific Port Up
or Port Down message MUST include TLVs from Section 5.1.2 to identify
the DSL loop.
TLVs presenting DSL line attributes (i.e., the TLVs specified in
Section 6.5) MUST be encapsulated within the DSL-Line-Attributes TLV.
When the DSL-Line-Attributes TLV is present in a message, it MUST
contain at least one such TLV and will generally contain more than
one. In the Port Up message, the DSL-Line-Attributes TLV MUST be
present. In the Port Down message, the DSL-Line-Attributes TLV MAY
be present.
If the AN-side ANCP agent is unable to satisfy a request from the AN
control application because it detects an error in the request or
because it receives a Generic Response message indicating an error in
a Port Up or Port Down message that it has sent and is unable to
recover from that error at the protocol level, it "must" inform the
application, including any available diagnostic information.
6.4.2. Procedures On the NAS Side
The NAS-side ANCP agent MUST be prepared to receive Port Up and Port
Down messages for a given DSL loop or logical port at any time after
negotiation of an adjacency has been completed. It is possible for
two Port Up messages in succession to be received for the same DSL
loop without an intervening Port Down message, and vice versa.
The NAS-side ANCP agent SHOULD validate each message against the
specifications given in Section 6.3 and the TLV specifications given
in Section 5.1.2 and Section 6.5. If it finds an error it MAY
generate a Generic Response message containing an appropriate Result
Code value. If it does so, the message MUST contain copies of all of
the identifier TLVs from Section 5.1.2 that were present in the Port
Up or Port Down message. The message SHOULD also contain a Status-
Info TLV which in turn contains other information appropriate to the
message header Code value as described in Section 3.6.1.4.
If the received message passes validation, the NAS-side ANCP agent
"must" extract the information from the TLVs contained in the message
and present that information along with an indication of reported
event type to the NAS control application. If validation of
individual TLVs fails but the message as a whole can be processed,
the NAS-side ANCP agent "may" pass the valid message contents to the
NAS control application.
6.5. TLVs For DSL Line Attributes
As specified above, the DSL-Line-Attributes TLV is inserted into the
Port Up or Port Down message at the top level. The remaining TLVs
defined below are encapsulated within the DSL-Line-Attributes TLV.
6.5.1. DSL-Line-Attributes TLV
Type: 0x0004
Description: This TLV encapsulates attribute values for a DSL line
serving a subscriber.
Length: variable (up to 1024 bytes)
Value: one or more encapsulated TLVs corresponding to DSL line
attributes. The DSL-Line-Attributes TLV MUST contain at least one
TLV when it is present in a Port Up or Port Down message. The
actual contents are determined by the AN control application.
6.5.2. DSL-Type TLV
Type: 0x0091 Type: 0x0091
Description: Indicates the type of transmission system in use. This Description: Indicates the type of transmission system in use.
is a mandatory TLV.
Length: 4 bytes Length: 4 bytes
Value: 32 bit unsigned integer Value: 32 bit unsigned integer
ADSL1 = 1 ADSL1 = 1
ADSL2 = 2 ADSL2 = 2
ADSL2+ = 3 ADSL2+ = 3
VDSL1 = 4 VDSL1 = 4
VDSL2 = 5 VDSL2 = 5
SDSL = 6
UNKNOWN = 7 SDSL = 6
5.2.3.3.6.2. Actual-Net-Data-Rate-Upstream TLV OTHER = 0
Name: Actual-Net-Data-Rate-Upstream 6.5.3. Actual-Net-Data-Rate-Upstream TLV
Type: 0x0081 Type: 0x0081
Description: Actual upstream net data rate on a DSL line. This is a Description: Actual upstream net data rate on a DSL line.
mandatory TLV.
Length: 4 bytes Length: 4 bytes
Value: Rate in Kbits/s as a 32 bit unsigned integer Value: Rate in Kbits/s as a 32 bit unsigned integer
5.2.3.3.6.3. Actual-Net-Data-Rate-Downstream TLV 6.5.4. Actual-Net-Data-Rate-Downstream TLV
Name: Actual-Net-Data-Rate-Downstream
Type: 0x0082 Type: 0x0082
Description: Actual downstream net data rate on a DSL line.
Description: Actual downstream net data rate on a DSL line. This is
a mandatory TLV.
Length: 4 bytes Length: 4 bytes
Value: Rate in Kbits/s as a 32 bit unsigned integer Value: Rate in Kbits/s as a 32 bit unsigned integer
5.2.3.3.6.4. Minimum-Net-Data-Rate-Upstream TLV 6.5.5. Minimum-Net-Data-Rate-Upstream TLV
Name: Minimum-Net-Data-Rate-Upstream
Type: 0x0083 Type: 0x0083
Description: Minimum upstream net data rate desired by the operator. Description: Minimum upstream net data rate desired by the operator.
This is an optional TLV.
Length: 4 bytes Length: 4 bytes
Value: Rate in Kbits/s as a 32 bit unsigned integer Value: Rate in Kbits/s as a 32 bit unsigned integer
5.2.3.3.6.5. Minimum-Net-Data-Rate-Downstream TLV 6.5.6. Minimum-Net-Data-Rate-Downstream TLV
Name: Minimum-Net-Data-Rate-Downstream
Type: 0x0084 Type: 0x0084
Description: Minimum downstream net data rate desired by the Description: Minimum downstream net data rate desired by the
operator. This is an optional TLV. operator.
Length: 4 bytes Length: 4 bytes
Value: Rate in Kbits/s as a 32 bit unsigned integer Value: Rate in Kbits/s as a 32 bit unsigned integer
5.2.3.3.6.6. Attainable-Net-Data-Rate-Upstream TLV 6.5.7. Attainable-Net-Data-Rate-Upstream TLV
Name: Attainable-Net-Data-Rate-Upstream
Type: 0x0085 Type: 0x0085
Description: Maximum net upstream rate that can be attained on the Description: Maximum net upstream rate that can be attained on the
DSL line. This is an optional TLV. DSL line.
Length: 4 bytes Length: 4 bytes
Value: Rate in Kbits/s as a 32 bit unsigned integer Value: Rate in Kbits/s as a 32 bit unsigned integer
5.2.3.3.6.7. Attainable-Net-Data-Rate-Downstream TLV 6.5.8. Attainable-Net-Data-Rate-Downstream TLV
Name: Attainable-Net-Data-Rate-Downstream
Type: 0x0086 Type: 0x0086
Description: Maximum net downstream rate that can be attained on the Description: Maximum net downstream rate that can be attained on the
DSL line. This is an optional TLV. DSL line.
Length: 4 bytes Length: 4 bytes
Value: Rate in Kbits/s as a 32 bit unsigned integer Value: Rate in Kbits/s as a 32 bit unsigned integer
5.2.3.3.6.8. Maximum-Net-Data-Rate-Upstream TLV 6.5.9. Maximum-Net-Data-Rate-Upstream TLV
Name: Maximum-Net-Data-Rate-Upstream
Type: 0x0087 Type: 0x0087
Description: Maximum net upstream data rate desired by the operator. Description: Maximum net upstream data rate desired by the operator.
This is an optional TLV.
Length: 4 bytes Length: 4 bytes
Value: Rate in Kbits/s as a 32 bit unsigned integer Value: Rate in Kbits/s as a 32 bit unsigned integer
5.2.3.3.6.9. Maximum-Net-Data-Rate-Downstream TLV 6.5.10. Maximum-Net-Data-Rate-Downstream TLV
Name: Maximum-Net-Data-Rate-Downstream
Type: 0x0088 Type: 0x0088
Description: Maximum net downstream data rate desired by the Description: Maximum net downstream data rate desired by the
operator. This is an optional TLV. operator.
Length: 4 bytes Length: 4 bytes
Value: Rate in Kbits/s as a 32 bit unsigned integer Value: Rate in Kbits/s as a 32 bit unsigned integer
5.2.3.3.6.10. Minimum-Net-Low-Power-Data-Rate-Upstream TLV 6.5.11. Minimum-Net-Low-Power-Data-Rate-Upstream TLV
Name: Minimum-Net-Low-Power-Data-Rate-Upstream
Type: 0x0089 Type: 0x0089
Description: Minimum net upstream data rate desired by the operator Description: Minimum net upstream data rate desired by the operator
in low power state. This is an optional TLV. in low power state.
Length: 4 bytes Length: 4 bytes
Value: Rate in Kbits/s as a 32 bit unsigned integer Value: Rate in Kbits/s as a 32 bit unsigned integer
5.2.3.3.6.11. Minimum-Net-Low-Power-Data-Rate-Downstream TLV 6.5.12. Minimum-Net-Low-Power-Data-Rate-Downstream TLV
Name: Minimum-Net-Low-Power-Data-Rate-Downstream
Type: 0x008A Type: 0x008A
Description: Minimum net downstream data rate desired by the Description: Minimum net downstream data rate desired by the
operator in low power state. This is an optional TLV. operator in low power state.
Length: 4 bytes Length: 4 bytes
Value: Rate in Kbits/s as a 32 bit unsigned integer Value: Rate in Kbits/s as a 32 bit unsigned integer
5.2.3.3.6.12. Maximum-Interleaving-Delay-Upstream TLV 6.5.13. Maximum-Interleaving-Delay-Upstream TLV
Name: Maximum-Interleaving-Delay-Upstream
Type: 0x008B Type: 0x008B
Description: maximum one way interleaving delay. This is an Description: maximum one way interleaving delay.
optional TLV.
Length: 4 bytes Length: 4 bytes
Value: Time in ms as a 32 bit unsigned integer Value: Time in ms as a 32 bit unsigned integer
5.2.3.3.6.13. Actual-Interleaving-Delay-Upstream TLV 6.5.14. Actual-Interleaving-Delay-Upstream TLV
Name: Actual-Interleaving-Delay-Upstream
Type: 0x008C Type: 0x008C
Description: Value corresponding to the interleaver setting. This Description: Value corresponding to the interleaver setting.
is an optional TLV.
Length: 4 bytes Length: 4 bytes
Value: Time in ms as a 32 bit unsigned integer Value: Time in ms as a 32 bit unsigned integer
5.2.3.3.6.14. Maximum-Interleaving-Delay-Downstream TLV 6.5.15. Maximum-Interleaving-Delay-Downstream TLV
Name: Maximum-Interleaving-Delay-Downstream
Type: 0x008D Type: 0x008D
Description: maximum one way interleaving delay. This is an Description: maximum one way interleaving delay.
optional TLV.
Length: 4 bytes Length: 4 bytes
Value: Time in ms as a 32 bit unsigned integer Value: Time in ms as a 32 bit unsigned integer
5.2.3.3.6.15. Actual-Interleaving-Delay-Downstream 6.5.16. Actual-Interleaving-Delay-Downstream
Name: Actual-Interleaving-Delay-Downstream
Type: 0x008E Type: 0x008E
Description: Value corresponding to the interleaver setting. This Description: Value corresponding to the interleaver setting.
is an optional TLV.
Length: 4 bytes Length: 4 bytes
Value: Time in ms as a 32 bit unsigned integer Value: Time in ms as a 32 bit unsigned integer
5.2.3.3.6.16. DSL-Line-State TLV (Mandatory for Port DOWN) 6.5.17. DSL-Line-State TLV
Name: DSL-Line-State
Type: 0x008F Type: 0x008F
Description: The state of the DSL line. For the Port UP message, in Description: The state of the DSL line.
this specification, the TLV is optional (since the message type
implicitly conveys the state of the line). For Port DOWN, the TLV
is mandatory, since it further communicates the state of the line
as IDLE or SILENT.
Length: 4 bytes Length: 4 bytes
Value: 32 bit unsigned integer Value: 32 bit unsigned integer
SHOWTIME = 1 SHOWTIME = 1
IDLE = 2 IDLE = 2
SILENT = 3 SILENT = 3
5.2.3.3.6.17. Access-Loop-Encapsulation TLV 6.5.18. Access-Loop-Encapsulation TLV
Name: Access-Loop-Encapsulation
Type: 0x0090 Type: 0x0090
Description: The data link protocol and, optionally, the Description: The data link protocol and, optionally, the
encapsulation overhead on the access loop. This is an optional encapsulation overhead on the access loop. When this TLV is
TLV. However, when this TLV is present, the data link protocol present, at least the data link protocol MUST be indicated. The
MUST minimally be indicated. The encapsulation overhead MAY be encapsulation overhead MAY be indicated. The Access Node MAY
indicated. The Access Node can choose to not convey the choose to not convey the encapsulation on the access loop by
encapsulation on the access loop by specifying a value of 0 (NA) specifying values of 0 (NA) for the two encapsulation fields.
for the two encapsulation fields
Length: 3 bytes Length: 3 bytes
Value: The three bytes (most to least significant) and valid set of Value: The three bytes (most to least significant) and valid set of
values for each byte are defined below. values for each byte are defined as follows:
Byte 1: Data Link Byte 1: Data Link
ATM AAL5 = 0 ATM AAL5 = 0
ETHERNET = 1 ETHERNET = 1
Byte 2: Encapsulation 1 Byte 2: Encapsulation 1
NA = 0 NA = 0
Untagged Ethernet = 1 Untagged Ethernet = 1
skipping to change at page 39, line 16 skipping to change at page 48, line 48
ETHERNET = 1 ETHERNET = 1
Byte 2: Encapsulation 1 Byte 2: Encapsulation 1
NA = 0 NA = 0
Untagged Ethernet = 1 Untagged Ethernet = 1
Single-tagged Ethernet = 2 Single-tagged Ethernet = 2
Double-tagged Ethernet = 3
Byte 3: Encapsulation 2 Byte 3: Encapsulation 2
NA = 0 NA = 0
PPPoA LLC = 1 PPPoA LLC = 1
PPPoA NULL = 2 PPPoA NULL = 2
IPoA LLC = 3 IPoA LLC = 3
IPoA NuLL = 4 IPoA NuLL = 4
Ethernet over AAL5 LLC with FCS = 5 Ethernet over AAL5 LLC with FCS = 5
Ethernet over AAL5 LLC without FCS = 6 Ethernet over AAL5 LLC without FCS = 6
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 10. The Access-Loop-Encapsulation 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 = 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 10: The Access-Loop-Encapsulation TLV Figure 15: The Access-Loop-Encapsulation TLV
5.3. ANCP based DSL Line Configuration 7. ANCP based DSL Line Configuration
5.3.1. Goals The use case for ANCP-based DSL Line Configuration is described in
Section 3.2 of [RFC5851].
Following dynamic discovery of access topology (identification of DSL 7.1. Control Context (Informative)
line and its attributes) as assisted by the mechanism described in
the previous section (topology discovery), the NAS may query a
subscriber management OSS system (e.g., RADIUS server) to retrieve
subscriber authorization data (service profiles). Most of such
service mechanisms are typically enforced by the NAS itself, but
there are a few cases where it may be useful to push such service
parameters to the DSLAM for local enforcement of a mechanism (e.g.
DSL-related) on the corresponding subscriber line.
One such example of a service parameter that can be pushed to the Triggered by topology information reporting a new DSL line or
DSLAM for local enforcement is DSL "interleaving delay". Longer triggered by a subsequent user session establishment (PPP or DHCP),
interleaving delay (and hence stringent error correction) is required RADIUS/AAA sends service parameters to the NAS control application
for a video service to ensure better video "quality of experience", for configuration on the access line. The NAS control application
whereas for a VoIP service or for "shoot first" gaming service, a passes the request on to the NAS-side agent, which sends the
very short interleaving delay is more appropriate. Another relevant information to the AN by means of a Port Management (line
application is downloading per subscriber multicast channel configuration) message. The AN-side agent passes this information up
entitlement information in IPTV applications where the DSLAM is to the AN control application, which applies it to the line.
performing IGMP snooping or IGMP proxy function. Using ANCP, the NAS
can achieve the goal of pushing line configuration to the DSLAM by an
interoperable and standardized protocol.
If a subscriber wants to choose a different service, it can require Figure 16 summarizes the interaction.
an operational-expense-intensive reconfiguration of the line via a
network operator, possibly implying a business-to-business
transaction between an ISP and an access provider. Using ANCP for
line configuration from the NAS dramatically simplifies the OSS
infrastructure for service management, allowing fully centralized
subscriber-related service data (e.g., RADIUS server back-end) and
avoiding complex cross-organization business-to-business
interactions.
The best way to change line parameters is by using profiles. These Home Access NAS RADIUS/AAA
profiles (DSL profiles for different services) are pre-configured on Gateway Node Policy Server
the DSLAMs. The NAS can then send a reference to the right DSL
profile via ANCP. Alternatively, discrete DSL parameters can also be
conveyed by the NAS in ANCP.
5.3.2. Message Flow -----------> --------------->
DSL Port Up message)
Signal (line parameters)
Triggered by topology information reporting a new DSL line or --------------------------------> -------------->
triggered by a subsequent user session establishment (PPP or DHCP), PPP/DHCP Session Authentication &
the NAS may send line configuration information (e.g. reference to a authorization
DSL profile) to the DSLAM using ANCP Port Management messages. The
NAS may get such line configuration data from a policy server (e.g.,
RADIUS). Figure 11 summarizes the interaction.
+----------+ +-----+ +-----+ +-------+ +-----------+ <----------------
|Radius/AAA|---| NAS |-----| AN |----| Home |----|Subscriber | Port Management message
|Policy | +-----+ +-----+ |Gateway| +-----------+ (line configuration)
|Server | +-------+
+----------+
1.DSL Signal Figure 16: Message Flow - ANCP Mapping For Initial Line Configuration
<-----------
2. Port UP (Event Message)
(Access Topology Discovery)
<----------------
3. PPP/DHCP Session
<--------------------------------
4. Authorization
& Authentication
<-------------------
Port Management Message
(Line Configuration)
5. -------->
Figure 11: Message Flow - ANCP Mapping For Initial Line Configuration The NAS could update the line configuration as a result of a
subscriber service change (e.g. triggered by the policy server).
Figure 17 summarizes the interaction.
The NAS may update the line configuration due to a subscriber service User Home Access NAS
change (e.g. triggered by the policy server). Figure 12 summarizes Gateway Node
the interaction.
+------+ +-------+ +---------+ +----------+ -------------------------->
| NAS |-----| AN |---| Home |--|Subscriber| PPP/DHCP Session
+------+ +-------+ | Gateway | +----------+
+---------+
1. PPP/DHCP Session -------------------------------------------------------> Web portal,
<------------------------------------------ Service on demand OSS, etc.
|
<-------------- RADIUS/AAA
Change of Policy Server
authorization
+-----------+ 2. Service On Demand <------------
| |<----------------------------------------------- Port Management
| Web portal| message
| OSS etc | 3.Change of (new profile)
| | Authorization
|Radius AAA | --------> 4.Port Management
| Policy | Message
| | ------------->
+-----------+ (Updated Line Config - New Profile)
Figure 12: Message flow - ANCP Mapping For Updated Line Configuration Figure 17: Message flow - ANCP Mapping For Updated Line Configuration
The format of relevant extensions to port management message is 7.2. Protocol Requirements
defined in section Section 5.3.3. The line configuration models
could be viewed as a form of delegation of authorization from the NAS
to the DSLAM.
5.3.3. Specification of the ANCP DSL Line Configuration Capability The DSL line configuration capability is assigned capability type
0x0002. No capability data is associated with this capability.
5.3.3.1. Protocol Requirements 7.2.1. Protocol Requirements On the NAS Side
The DSL line configuration capability is assigned capability type The NAS-side ANCP agent MUST be able to create DSL-specific Port
0x02. No capability data is associated with this capability. Management (line configuration) messages according to the format
Implementations of the DSL line configuration capability MUST support specified in Section 7.3.
the following ANCP protocol elements:
o ANCP Port Management message, which is based on the GSMPv3 The NAS-side ANCP agent MUST conform to the normative requirements of
[RFC3292] message of the same name but includes capability- Section 5.1.2.
specific modifications and extensions (Section 5.3.3.2).
o The procedures associated with this message and its contents The NAS-side ANCP agent "must" be able to accept any information
(Section 5.3.3.3). passed to it by the NAS control application that may validly be
included in any of the TLVs specified in Section 7.5.
o Access-Loop-Circuit-ID TLV (as defined in Section 5.2.3.3); In the current version of this specification only one such TLV is
defined.
o Access-Aggregation-Circuit-ID-Binary TLV (as defined in The NAS-side ANCP agent MUST package that information as TLVs, and
Section 5.2.3.3); MUST include these TLVs within the Port Management (line
configuration) message.
o Access-Aggregation-Circuit-ID-ASCII TLV (as defined in The NAS-side ANCP agent MUST follow the NAS-side procedures
Section 5.2.3.3); associated with DSL-specific Port Management (line configuration)
messages as they are specified in Section 7.4.
o Service-Profile-Name TLV (as defined in Section 5.3.3.4). 7.2.2. Protocol Requirements On the AN Side
5.3.3.2. ANCP Port Management Message Format For DSL Line Configuration The AN-side ANCP agent MUST conform to the normative requirements of
Section 5.1.2.
The AN-side ANCP agent MUST be able to receive and validate DSL-
specific Port Management (line configuration) messages according to
the format specified in Section 7.3.
The AN-side ANCP agent MUST follow the AN-side procedures associated
with DSL-specific Port Management (line configuration) messages as
specified in Section 7.4.
The NAS-side ANCP agent MUST be able to extract the information
contained in any of the TLVs listed in Section 7.2.1 and "must" make
that information available to the NAS control application.
7.3. ANCP Port Management (Line Configuration) Message Format
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 13. format shown in Figure 18.
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 3.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header | | ANCP General Message Header |
+ (Section 4.4) + + (Section 3.6.1) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | | Port (unused) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number | | Port Session Number (unused) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Sequence Number | | Event Sequence Number (unused) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|x|x|x|x|x|x|x| Duration | Function | X-Function | |R|x|x|x|x|x|x|x| Dur. (unused) | Function=8 | X-Function=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Flags | Flow Control Flags | | Event Flags (unused) | Flow Control Flags (unused) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length | |x|x|x|x|x|x|x|x| Message Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs | Extension Block length (bytes) | | # of TLVs | Extension Block length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ TLVs ~ ~ Access line identifying TLV(s) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Line configuration TLVs ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13 NOTE: TLVs MAY be in a different order from what is shown in this
figure.
See Section 4.6 for a description of the ANCP general message header. Figure 18: Port Management Message For DSL Line Configuration
See Section 3.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.6. fields in the general header MUST be set as described in Section 3.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. The handling of
considered reserved. The handling of unused/reserved fields is unused/reserved fields is described in Section 3.4.
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.
Function: action to be performed. For DSL line configuration, Function: action to be performed. For line configuration, Function
Function MUST be set to 8 (Configure Connection Service Data). MUST be set to 8 (Configure Connection Service Data). This action
This action type requests the Access Node (i.e., DSLAM) to apply type requests the Access Node (i.e., DSLAM) to apply service
service configuration data contained in the extension value (TLVs) configuration data contained in the extension value (TLVs) to the
to the DSL line (identified by one of the TLVs in the extension DSL line (identified by one of the TLVs in the extension value).
value).
X-Function: qualifies the action set by Function. For DSL line X-Function: qualifies the action set by Function. For DSL line
configuration, this field MUST be set to 0. configuration, this field MUST be set to 0.
Event Flags: not used by ANCP. Event Flags: not used by ANCP.
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). Reserved (16 bits): reserved for future use.
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. TLVs.
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 Other ANCP capabilities, either specific to DSL or technology-
independent, MAY reuse the Port Management message for service
configuration. If the settings of the fixed fields are compatible
with the settings just described, the same Port Management message
that is used for DSL line configuration MAY be used to carry TLVs
relating to the other capabilities that apply to the same DSL loop.
Section 5.3.2 Describes the circumstances under which the NAS sends a Use of the Port Management message for configuration MAY also be
Port Management message to the AN to configure DSL service parameters generalized to other access technologies, if the respective
for a specific subscriber line. To identify the line, the NAS MUST capabilities specify use of access line identifiers appropriate to
include one of Access-Loop-Circuit-ID TLV, Access-Aggregation- those technologies in place of the identifiers defined in
Circuit-ID-Binary TLV, or Access-Aggregation-Circuit-ID-ASCII TLV in Section 5.1.2.
the Port Management message, depending upon the deployment scenario.
The NAS MUST include one or more TLVs to configure line service
parameters for that line. Section 5.3.3.4 currently identifies only
one such TLV, Service-Profile-Name, but other TLVs may be added by
extensions to ANCP.
If the NAS sets Result to AckAll (0x1) and the AN processes the Port 7.4. Procedures
Management message successfully, the AN MUST return a Port Management
message in reply, containing a Result field set to Success (0x3).
All other fields of the returned message MUST be identical to those
received in the request.
If an error occurs during the processing of the Port Management Service configuration MAY be performed on an access line regardless
message, then the AN MUST always return a Port Management message of its current state.
with the Result field set to Failure (0x4). The Code field MUST be
set to indicate the reason for failure. The remainder of the message 7.4.1. Procedures On the NAS Side
MUST be copied from the request. The AN MAY add a Status-Info TLV
(Section 6.2.3) to provide further information on the error, in which When requested by the NAS control application and presented with the
case the various length fields and the # of TLVs field within the necessary information to do so, the NAS-side agent MUST create and
send a Port Management message with the fixed fields set as described
in the previous section. The message MUST contain one or more TLVs
to identify an access line according the requirements of
Section 5.1.2. The NAS MUST include one or more TLVs to configure
line service parameters for that line. Section 7.5 currently
identifies only one such TLV, Service-Profile-Name, but other TLVs
MAY be added by extensions to ANCP.
7.4.2. Procedures On the AN Side
The AN-side ANCP agent MUST be prepared to receive Port Management
(line configuration) messages for a given DSL loop or logical port at
any time after negotiation of an adjacency has been completed.
The AN-side ANCP agent SHOULD validate each message against the
specifications given in Section 7.3 and the TLV specifications given
in Section 5.1.2 and Section 7.5. If it finds an error it MUST
return a Port Management response message which copies the Port
Management request as it was received, but has the Result header
field set to 0x04 (Failure) and the Code field set to the appropriate
value. The AN-side agent MAY add a Status-Info TLV (Section 4.5) to
provide further information on the error, particularly if this is
recommended in Section 3.6.1.4 for the given Code value. If it does
so, the various length fields and the # of TLVs field within the
message MUST be adjusted accordingly. message MUST be adjusted accordingly.
5.3.3.4. TLVs For DSL Line Configuration If the received message passes validation, the AN-side ANCP agent
"must" extract the information from the TLVs contained in the message
and present that information to the AN control application. In
addition, if the Result header field was set to 0x2 (AckAll) in the
original request, the AN-side agent "must" indicate to the AN control
application that a response is required. When the AN control
application indicates that it has processed the request successfully,
the AN-side agent MUST return a Port Management response message
which duplicates the request except that the Result header field is
set to 0x3 (Success). (The Code field, as in the original request,
has value 0.)
7.5. TLVs For DSL Line Configuration
Currently only the following TLV is specified for DSL line Currently only the following TLV is specified for DSL line
configuration. More TLVs may be defined in a future version of this configuration. More TLVs may be defined in a future version of this
specification or in ANCP extensions for individual service attributes specification or in ANCP extensions for individual service attributes
of a DSL line (e.g. rates, interleaving delay, multicast channel of a DSL line (e.g. rates, interleaving delay, multicast channel
entitlement access-list). entitlement access-list).
Name: Service-Profile-Name 7.5.1. Service-Profile-Name TLV
Type: 0x0005 Type: 0x0005
Description: Reference to a pre-configured profile on the DSLAM that Description: Reference to a pre-configured profile on the DSLAM that
contains service specific data for the subscriber. contains service specific data for the subscriber.
Length: up to 64 bytes Length: up to 64 bytes
Value: ASCII string containing the profile name (which the NAS Value: ASCII string containing the profile name (which the NAS
learns from a policy server after a subscriber is authorized). learns from a policy server after a subscriber is authorized).
5.4. ANCP Based DSL Line Testing Capability 8. ANCP-Based DSL Remote Line Connectivity Testing
In a mixed Ethernet and ATM access network (including the local The use case and requirements for ANCP-Based DSL remote line
loop), it is desirable to provide similar mechanisms for connectivity connectivity testing are specified in Section 3.3 of [RFC5851]
checks and fault isolation, as those used in an ATM based
architecture. This can be achieved using an ANCP based mechanism
until end-to-end Ethernet OAM mechanisms are more widely implemented
in various network elements.
A simple solution based on ANCP can provide the NAS with an access 8.1. Control Context (Informative)
line test capability and to some extent fault isolation. Controlled
by a local management interface the NAS can use an ANCP operation to
trigger the Access Node to perform a loopback test on the local loop
(between the Access Node and the CPE). The Access Node can respond
via another ANCP operation with the result of the triggered loopback
test. In the case of ATM based local loop the ANCP operation can
trigger the Access Node to generate ATM (F4/F5) loopback cells on the
local loop. In the case of Ethernet, the Access Node can trigger an
Ethernet loopback message(per EFM OAM) on the local loop.
5.4.1. Message Flow The NAS control application initiatea a request for remote
connectivity testing for a given access loop. The NAS control
application can provide loop count and timeout test parameters and
opaque data for its own use with the request. The loop count
parameter indicates the number of test messages or cells to be used.
The Port Management message can be used by the NAS to request Access The timeout parameter indicates the longest that the NAS control
Node to trigger a remote loopback test on the local loop. The result application will wait for a result.
of the loopback test can be asynchronously conveyed by the Access
Node to the NAS in a Port Management response message. The formats The request is passed in a Port Management (OAM) message. If the NAS
of the relevant extensions to the Port Management message are defined control application has supplied test parameters, they are used,
in Section 5.4.2.2. Figure 14 summarizes the interaction. otherwise the AN control application uses default test parameters.
If a loop count parameter provided by the NAS is outside the valid
range, the AN does not execute the test, but returns a result
indicating that the test has failed due to an invalid parameter. If
the test takes longer than the timeout value (default or provided by
the NAS) the AN control application can return a failure result
indicating timeout or else can send no response. The AN control
application can provide a human-readable string describing the test
results,for both failures and successes. If provided, this string is
included in the response. Responses always include the opaque data,
if any, provided by the NAS control application.
Figure 19 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 14: Message Flow For ANCP based OAM Figure 19: Message Flow For ANCP based OAM
5.4.2. Specification of the ANCP DSL Line Testing Capability 8.2. Protocol Requirements
5.4.2.1. Protocol Requirements The DSL remote line connectivity testing capability is assigned
capability type 0x0004. No capability data is associated with this
capability.
The DSL line testing capability is assigned capability type 0x04. No 8.2.1. Protocol Requirements On the NAS Side
capability data is associated with this capability. Implementations
of the DSL line testing capability MUST support the following ANCP
protocol elements:
o ANCP Port Management message, which is based on the GSMPv3 The NAS-side ANCP agent MUST be able to create DSL-specific Port
[RFC3292] message of the same name but includes capability- Management (OAM) messages according to the format specified in
specific modifications and extensions (Section 5.4.2.2). Section 8.3.
o The procedures associated with this message and its contents The NAS-side ANCP agent MUST conform to the normative requirements of
(Section 5.4.2.3). Section 5.1.2.
o Access-Loop-Circuit-ID TLV (as defined in Section 5.2.3.3); The NAS-side ANCP agent "must" be able to accept any information
passed to it by the NAS control application that may validly be
included in any of the TLVs specified in Section 8.5.
o Access-Aggregation-Circuit-ID-Binary TLV (as defined in The NAS-side ANCP agent MUST package that information as TLVs, and
Section 5.2.3.3); MUST include these TLVs within the Port Management (OAM) message.
o Access-Aggregation-Circuit-ID-ASCII TLV (as defined in The NAS-side ANCP agent MUST follow the NAS-side procedures
Section 5.2.3.3); associated with DSL-specific Port Management (OAM) messages as they
are specified in Section 8.4.
o OAM-Loopback-Test-Parameters TLV; 8.2.2. Protocol Requirements On the AN Side
o Opaque-Data TLV; The AN-side ANCP agent MUST conform to the normative requirements of
Section 5.1.2.
o OAM-Loopback-Test-Response-String TLV. The AN-side ANCP agent MUST be able to receive and validate DSL-
specific Port Management (OAM) messages according to the format
specified in Section 8.3.
If not otherwise indicated, the TLVs listed above are defined in The AN-side ANCP agent MUST follow the AN-side procedures associated
Section 5.4.2.4. with DSL-specific Port Management (OAM) messages as specified in
Section 8.4.
5.4.2.2. Message Format The NAS-side ANCP agent MUST be able to extract the information
contained in any of the TLVs listed in Section 8.2.1 and "must" make
that information available to the NAS control application.
8.3. Port Management (OAM) Message Format
The Port Management message for DSL line testing has the same format The Port Management message for DSL line testing has the same format
as for DSL line configuration (see Section 5.3.3.2), with the as for DSL line configuration (see Section 7.3), with the following
following differences: differences:
o The Result field in the request SHOULD be set to AckAll (0x1), to o The Result field in the request SHOULD be set to AckAll (0x1), to
allow the NAS to receive the information contained in a successful allow the NAS to receive the information contained in a successful
test response. test response.
o The Function field MUST be set to 9 (Remote Loopback). (The o The Function field MUST be set to 9 (Remote Loopback). (The
X-Function field continues to be 0.) X-Function field continues to be 0.)
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 The Port Management (OAM) message is illustrated in Figure 20.
The ANCP Port Management message as described in Section 5.4.2.2 MAY 0 1 2 3
be used by the NAS to trigger the Access Node to run a loopback test 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
on the local loop. To identify the line to be tested, the NAS MUST +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
include one of Access-Loop-Circuit-ID TLV, Access-Aggregation- | TCP/IP Encapsulating Header (Section 3.2) |
Circuit-ID-Binary TLV, or Access- Aggregation-Circuit-ID-ASCII TLV in +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
the Port Management message, depending upon the deployment scenario. | ANCP General Message Header |
The NAS MAY include the OAM-Loopback-Test-Parameters and/or Opaque- + (Section 3.6.1) +
Data TLVs (defined in Section 5.4.2.4) to configure the loopback test | |
for that line. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port (unused) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number (unused) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Sequence Number (unused) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|x|x|x|x|x|x|x| Dur. (unused) | Function=9 | X-Function=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Flags (unused) | Flow Control Flags (unused) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Message Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs | Extension Block length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access line identifying TLV(s) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Testing-related TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Access Node SHOULD generate a Port Management response when it NOTE: TLVs MAY be in a different order from what is shown in this
deems the loopback test to be complete. (The exception is described figure.
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
Success (0x3) or Failure (0x4) as applicable. The Code field SHOULD
be set to one of the following values if applicable.
1280 (0x500): Specified access line does not exist Figure 20: Port Management Message For DSL Line Remote Connectivity
Testing
1281 (0x501): Loopback test timed out 8.4. Procedures
1282 (0x502): Reserved From the point of view of ANCP, it is permissible to attempt line
connectivity testing regardless of the state of the line. However,
testing could fail in some states due to technology limitations.
8.4.1. NAS-Side Procedures
When requested by the NAS control application and presented with the
necessary information to do so, the NAS-side agent MUST create and
send a Port Management (OAM) request with the fixed fields set as
described in the previous section. The message MUST contain one or
more TLVs to identify an access line according the requirements of
Section 5.1.2. The NAS MAY include the Opaque-Data TLV and/or the
OAM-Loopback-Test-Parameters TLV (defined in Section 8.5) to
configure the loopback test for that line.
8.4.2. AN-Side Procedures
The AN-side ANCP agent SHOULD validate each message against the
specifications given in Section 8.3 and the TLV specifications given
in Section 5.1.2 and Section 8.5. If it finds an error it MUST
return a Port Management response message which copies the Port
Management request as it was received, but has the Result header
field set to 0x04 (Failure) and the Code field set to the appropriate
value. Code value 1289 as described below MAY apply, as well as the
other Code values documented in Section 3.6.1.4. Code value 1289
SHOULD be used if the OAM-Loopback-Test-Parameters TLV is present
with an invalid value of the Count field. The AN-side agent MAY add
a Status-Info TLV (Section 4.5) to provide further information on the
error, particularly if this is recommended in Section 3.6.1.4 for the
given Code value. If it does so, the various length fields and the #
of TLVs field within the message MUST be adjusted accordingly.
If the received message passes validation, the AN-side ANCP agent
"must" extract the information from the TLVs contained in the message
and present that information to the AN control application. It MUST
NOT generate an immediate response to the request, but MUST instead
wait for the AN control application to indicate that the response
should be sent.
When requested by the AN control application and presented with the
necessary information to do so, the AN-side agent MUST create and
send a Port Management (OAM) response to the original request. The
Result field MUST be set to Success (0x3) or Failure (0x4), and the
Code field SHOULD be set to one of the following values, as indicated
by the AN control application.
1280 (0x500): Specified access line does not exist. See the
documentation of Code 3/1280 in Section 3.6.1.4 for more
information. The Result header field MUST be set to Failure
(0x4).
1281 (0x501): Loopback test timed out. The Result header field MUST
be set to Failure (0x4).
1283 (0x503): DSL line status showtime 1283 (0x503): DSL line status showtime
1284 (0x504): DSL line status idle 1284 (0x504): DSL line status idle
1285 (0x505): DSL line status silent 1285 (0x505): DSL line status silent
1286 (0x506): DSL line status training 1286 (0x506): DSL line status training
1287 (0x507): DSL line integrity error 1287 (0x507): DSL line integrity error
1288 (0x508): DSLAM resource not available 1288 (0x508): DSLAM resource not available. The Result header field
MUST be set to Failure (0x04).
1289 (0x509): Invalid test parameter
All other fields including the appended TLVs MUST be copied from the 1289 (0x509): Invalid test parameter. The Result header field MUST
request, except that the OAM-Loopback-Test-Parameters TLV MUST NOT be set to Failure (0x4).
appear in the response and the OAM-Loopback-Test-Response-String TLV
SHOULD appear in the response.
Section 5.4.2.4 contains additional procedures relating to specific All other fields of the request including the TLVs MUST be copied
TLVs. into the response unchanged, except that in a successful response the
OAM-Loopback-Test-Parameters TLV MUST NOT appear. If the AN control
application has provided the necessary information, the AN-side agent
MUST also include an instance of the OAM-Loopback-Test-Response-
String TLV in the response.
5.4.2.4. TLVs For the DSL Line Test Capability 8.5. TLVs For the DSL Line Remote Connectivity Testing Capability
The following TLVs have been defined for use with the DSL line The following TLVs have been defined for use with the DSL line
testing capability. testing capability.
5.4.2.4.1. OAM-Loopback-Test-Parameters TLV 8.5.1. OAM-Loopback-Test-Parameters TLV
Name: OAM-Loopback-Test-Parameters
Type: 0x0007 Type: 0x0007
Description: Parameters related to a loopback test. This is an Description: Parameters intended to override the default values for
optional TLV. If this TLV is not present in the request message, this loopback test.
the DSLAM SHOULD use locally determined default values for the
test parameters.
Length: 2 bytes Length: 2 bytes
Value: two 1 byte fields described below (listed in order of most to Value: two unsigned 1 byte fields described below (listed in order
least significant). of most to least significant).
Byte 1: Count. Number of loopback cells/messages that should Byte 1: Count. Number of loopback cells/messages that should
be generated on the local loop as part of the loopback test. be generated on the local loop as part of the loopback test.
The NAS SHOULD restrict the "count" to be greater than 0 and The Count value SHOULD be greater than 0 and less than or equal
less than or equal to 32. The DSLAM SHOULD discard a request to 32.
for a loopback test, if the received test parameters contain an
out of range value for the "count" field. The AN MAY include a
Code value of 0x509 "Invalid test parameter" in the resulting
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. The value 0 MAY
taken by the DSLAM to complete a test with requested be used, but has a special meaning.
parameters, exceeds the specified "timeout" value, it MAY
choose to omit the generation of a response to the NAS. The
DSLAM SHOULD use a locally determined value for Timeout, if the
received value of the Timeout parameter is 0.
The OAM-Loopback-Test-Parameters TLV is illustrated in Figure 15 The OAM-Loopback-Test-Parameters TLV is illustrated in Figure 21
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 15: The OAM-Loopback-Test-Parameters TLV Figure 21: The OAM-Loopback-Test-Parameters TLV
5.4.2.4.2. Opaque-Data TLV
Name: Opaque-Data 8.5.2. Opaque-Data TLV
Type: 0x0008 Type: 0x0008
Description: This is an optional TLV. If it is present in the Description: An 8 byte opaque field used by the NAS control
request message, the DSLAM SHOULD reflect it back in the response application for its own purposes (e.g., response correlation.)
unmodified. The procedures in Section 8.4.2 ensure that if it is present in
the request it is copied unchanged to the response.
Length: 8 bytes Length: 8 bytes
Value: Two 32 bit unsigned integers inserted by the NAS (not to be Value: Two 32 bit unsigned integers.
interpreted by the DSLAM, but just reflected back in the
response).
5.4.2.4.3. OAM-Loopback-Test-Response-String TLV
Name: OAM-Loopback-Test-Response-String 8.5.3. OAM-Loopback-Test-Response-String TLV
Type: 0x0009 Type: 0x0009
Description: Suitably formatted string containing useful details Description: Suitably formatted string containing useful details
about the test that the NAS will display for the operator, exactly about the test that the NAS will display for the operator, exactly
as received from the DSLAM (no manipulation/interpretation by the as received from the DSLAM (no manipulation or interpretation by
NAS). This is an optional TLV, but it is strongly RECOMMENDED the NAS).
that in case of ATM based local loop, the DSLAM at the very least
indicates, via this TLV, the total loopback cells generated and
the total loopback cells successfully received as part of
executing the requested loopback test.
Length: up to 128 bytes Length: up to 128 bytes
Value: UTF-8 encoded string of text. Value: UTF-8 encoded string of text.
6. Additional ANCP Messages and TLVs 9. IANA Considerations
This section defines two messages and a number of TLVs that may be
useful in multiple capabilities. Typically the content is under-
specified, with the intention that particular capabilities spell out
the remaining details.
6.1. Additional Messages and General Messaging Principles
6.1.1. General Principles for the Design of ANCP Messages
The GSMPv3 protocol [RFC3292] allows for two messaging constructs to
support request/response interaction:
a. The same message type is used for both the request message and
the response message. The Result and Code field settings are
used to differentiate between request and response messages.
b. The request and response messages use two different message
types.
The first approach is illustrated by the protocol specifications in
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
construct for the development of additional ANCP extensions.
As Section 4.6 indicated, all ANCP messages other than adjacency
messages share a common header format. When the response message
type is different from that of the request, the specification of the
request message will typically indicate that the Result field is set
to Ignore (0x0) and provide procedures indicating explicitly when the
receiver should generate a response and what message type it should
use.
The Transaction ID field is used to distinguish between request
messages and to associate a response message to a request.
Specifications of ANCP messages for applications not requiring
response correlation should indicate that the Transaction ID must be
set to zero in requests. Applications that require response
correlation should refer to the Transaction ID behaviour described in
Section 4.6.1.
The specification for a response message should indicate in all cases
that value of the Transaction Identifier must be set to that of the
corresponding request message. This allows the requester to
establish whether or not correlation is needed (by setting a non-zero
or zero value for the Transaction ID).
6.1.2. Provisioning Message
The Provisioning message is sent by the NAS to the AN to provision
information of global scope on the AN. The Provisioning message has
the format shown in Figure 16.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP/IP Encapsulating Header (Section 4.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header |
+ (Section 4.4) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Format of the Provisioning Message
This document specifies the following fields. The remaining fields
in the ANCP general message header MUST be set as specified in
Section 4.6.1. The TLVs are specified elsewhere on a per-capability
basis. The Provisioning message MAY be used to carry data relating
to more than one capability at once, assuming that the capabilities
concerned can co-exist and have all been negotiated during adjacency
establishment.
Message Type: MUST be set to 93.
Result: MUST be set to 0x0 (Ignore).
Code: MUST be set to zero.
Transaction ID: MUST be populated with a non-zero value chosen in
the manner described in Section 4.6.1.
If the AN can process the message successfully and accept all the
provisioning directives contained in it, the AN MUST NOT send any
response.
If not otherwise specified, if the AN fails to process the message
successfully it MUST send a Generic Response message (Section 6.1.3)
indicating failure and providing appropriate diagnostic information.
6.1.3. Generic Response Message
This section defines the Generic Response message. The Generic
Response message may be specified as the appropriate response to a
message defined in an extension to ANCP, instead of a more specific
response message. As a general guideline, specification of the
Generic Response message as a response is appropriate where no data
needs to be returned to the peer other than a result (success or
failure), plus, in the case of a failure, a code indicating the
reason for failure and a limited amount of diagnostic data.
Depending on the particular use case, the Generic Response message
MAY be sent by either the NAS or the AN.
The AN or NAS MAY send a Generic Response message indicating a
failure condition independently of a specific request before closing
the adjacency as a consequence of that failure condition. In this
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
receiver MAY record the information contained in the Status-info TLV
for management use.
The format of the Generic Response message is shown in Figure 17
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP/IP Encapsulating Header (Section 4.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header |
+ (Section 4.4) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status-Info TLV |
~ (Section 6.2.3) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Structure of the Generic Response Message
This document specifies the following fields. The remaining fields
in the ANCP general message header MUST be set as specified in
Section 4.6.1.
Message Type: MUST be set to 91.
Result: MUST be set to 0x3 (Success) or 0x4 (Failure).
Code: MUST be set to zero for success or an appropriate non-zero
value for failure.
Transaction ID: MUST be copied from the message to which this
message is a response.
Status-Info TLV: MAY be present in a success response, to provide a
warning as defined for a specific request message type. MUST be
present in a failure response. See Section 6.2.3 for a detailed
description of the Status- Info TLV. The actual contents will
depend on the request message type this message is responding to.
6.2. TLVs For General Use
This section contains the definitions of some TLVs that are intended
to be re-usable across different message types and capabilities.
6.2.1. Target TLV
Name: Target
Type: 0x1000 to 0x1020 depending on the specific content. Only
0x1000 has been assigned in this specification (see below).
Description: The Target TLV (0x1000 - 0x1020) is intended to be a
general means to represent different types of objects.
Length: Variable, depending on the specific object type.
Value: Target information as defined for each object type. The
field can consist of sub-TLVs.
TLV Type 0x1000 is assigned to a variant of the Target TLV
representing a single access line and encapsulating one or more sub-
TLVs identifying the target. Figure 18 illustrates the message
format for a single port identified by an Access-Loop-Circuit-ID TLV
(0x0001) that could be derived from a Port-UP message:
0 1 2 3
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Example of Target TLV For Single Access Line
6.2.2. Command TLV
Name: Command
Type: 0x0011
Description: The Command TLV (0x0011) is intended to be a general
means of encapsulating one or more command directives in a TLV
oriented message. The semantics of the command can be specified
for each message type using it. I.e., the specification of each
message type that can carry the Command TLV is expected to define
the meaning of the content of the payload, although re-use of
specifications is, of course, permissible when appropriate.
Length: Variable, depending on the specific contents.
Value: Command information as defined for each message type. The
field can include sub-TLVs. The contents of this TLV MUST be
specified as one "command" or alternatively a sequence of one or
more "commands", each beginning with a one-byte Command Code and
possibly including other data following the Command Code. An IANA
registry has been established for Command Code values. This
document reserves the Command Code value 0 as an initial entry in
the registry.
6.2.3. Status-Info TLV
Name: Status-Info
Type: 0x0106
Description: The Status-Info-TLV is intended to be a general
container for warning or error diagnostics relating to commands
and/or requests. It is a supplement to the Code field in the ANCP
general header. The specifications for individual message types
may indicate the use of this TLV as part of responses,
particularly for failures. As mentioned above, the Generic
Response message will usually include an instance of the Status-
Info TLV.
Length: Variable, depending on the specific contents.
Value: The following fixed fields. In addition, sub-TLVs may be
appended to provide further diagnostic information.
Reserved: see Section 4.4 for handling of reserved fields.
Msg Type: Message Type of the request for which this TLV is
providing diagnostics.
Error Message Length: Number of bytes in the error message,
excluding padding. This MAY be zero if no error message is
provided.
Error Message: Human-readable string providing information about
the warning or error condition. Padded with zeroes as
necessary to extend to a four-byte word boundary.
The following TLVs are RECOMMENDED to be appended if the indicated
Code values are given in the header of the message containing the
Status-info TLV:
* Code value 4 or 5: the Target or other TLV identifying the
unknown or unavailable port.
* Code value 84: the TLV that is unsupported or contains the
unsupported value.
Figure 19 illustrates the Status-Info TLV.
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 = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Msg Type | Error Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message (padded to 4 byte boundary) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional sub-TLVs... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: The Status-Info TLV
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 9.1. Summary
This section requests the following IANA actions: This section requests the following IANA actions:
o addition of message types to the GSMPv3 Message Type Name Space o addition of message types to the GSMPv3 Message Type Name Space
registry; registry;
o addition of a result type to the GSMPv3 Result Type Name Space o addition of a result type to the GSMPv3 Result Type Name Space
registry; [Editor's Note: may need an ANCP registry instead. registry;
Coordination between the two protocols is unnecessary because of
ANCP's reorganization of the Result field.]
o extension of limits [Editor's Note: assuming we are allowed to do o extension of limits and addition of failure codes to the GSMPv3
this!] and addition of failure codes to the GSMPv3 Failure 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; ANCP Function Codes;
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 9.2. IANA Actions
IANA is requested to add a new message category to the GSMPv3 Message IANA is requested to add a new message category to the GSMPv3 Message
Type Name Space registry: "Access Network Control Protocol (ANCP) Type Name Space registry: "Access Network Control Protocol (ANCP)
Messages". IANA is requested to add the following entries under that Messages". IANA is requested to add the following entries under that
category: category:
+------------------+----------------+--------+-----------+ +------------------+----------------+--------+-----------+
| Message Name | Message Number | Status | Reference | | Message Name | Message Number | Status | Reference |
+------------------+----------------+--------+-----------+ +------------------+----------------+--------+-----------+
| Generic Response | 91 | | RFCXXXX | | Generic Response | 91 | | RFCXXXX |
skipping to change at page 59, line 14 skipping to change at page 63, line 26
o Replace the ranges of unassigned codes at the end of the failure o Replace the ranges of unassigned codes at the end of the failure
response message name table as indicated. response message name table as indicated.
+----------+------------------------+---------------+ +----------+------------------------+---------------+
| Range | Registration Procedure | Notes | | Range | Registration Procedure | Notes |
+----------+------------------------+---------------+ +----------+------------------------+---------------+
| 256-4095 | IETF Consensus | ANCP use only | | 256-4095 | IETF Consensus | ANCP use only |
+----------+------------------------+---------------+ +----------+------------------------+---------------+
+-------+-----------------------------------------------+-----------+ +-------+----------------------------------------------+-----------+
| Value | Failure Response Message Name | Reference | | Value | Failure Response Message Name | Reference |
+-------+-----------------------------------------------+-----------+ +-------+----------------------------------------------+-----------+
| 81 | Request message type not implemented (0x51) | RFCXXXX | | 81 | Request message type not implemented (0x51) | RFCXXXX |
| 82 | Transaction identifier out of sequence (0x52) | RFCXXXX | | 83 | Malformed message (0x53) | RFCXXXX |
| 83 | Malformed message (0x53) | RFCXXXX | | 84 | Mandatory TLV missing (0x54) | RFCXXXX |
| 84 | TLV or value not supported by negotiated | RFCXXXX | | 85 | Invalid value in TLV (0x55) | RFCXXXX |
| | capability set (0x54) | | | 1280 | Specified access line does not exist (0x500) | RFCXXXX |
| 85 | Invalid value in TLV (0x55) | RFCXXXX | | 1281 | Loopback test timed out (0x501) | RFCXXXX |
| 1280 | Specified access line does not exist (0x500) | RFCXXXX | | 1282 | Reserved (0x502) | RFCXXXX |
| 1281 | Loopback test timed out (0x501) | RFCXXXX | | 1283 | DSL line status showtime (0x503) | RFCXXXX |
| 1282 | Reserved (0x502) | RFCXXXX | | 1284 | DSL line status idle (0x504) | RFCXXXX |
| 1283 | DSL line status showtime (0x503) | RFCXXXX | | 1285 | DSL line status silent (0x505) | RFCXXXX |
| 1284 | DSL line status idle (0x504) | RFCXXXX | | 1286 | DSL line status training (0x506) | RFCXXXX |
| 1285 | DSL line status silent (0x505) | RFCXXXX | | 1287 | DSL line integrity error (0x507) | RFCXXXX |
| 1286 | DSL line status training (0x506) | RFCXXXX | | 1288 | DSLAM resource not available (0x508) | RFCXXXX |
| 1287 | DSL line integrity error (0x507) | RFCXXXX | | 1289 | Invalid test parameter (0x509) | RFCXXXX |
| 1288 | DSLAM resource not available (0x508) | RFCXXXX | +-------+----------------------------------------------+-----------+
| 1289 | Invalid test parameter (0x509) | RFCXXXX |
+-------+-----------------------------------------------+-----------+
+-----------+-------------------------------+-----------+ +-----------+-------------------------------+-----------+
| Value | Failure Response Message Name | Reference | | Value | Failure Response Message Name | Reference |
+-----------+-------------------------------+-----------+ +-----------+-------------------------------+-----------+
| 8-9 | Unassigned | | | 8-9 | Unassigned | |
| 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) | |
+-----------+-------------------------------+-----------+ +-----------+-------------------------------+-----------+
skipping to change at page 61, line 12 skipping to change at page 66, line 12
New assignments should be in the range of values from 0x0100 upwards. New assignments should be in the range of values from 0x0100 upwards.
The initial entries are as follows: The initial entries are as follows:
+--------------+----------------------------------------+-----------+ +--------------+----------------------------------------+-----------+
| Type Code | TLV Name | Reference | | Type Code | TLV Name | Reference |
+--------------+----------------------------------------+-----------+ +--------------+----------------------------------------+-----------+
| 0x0000 | Reserved | RFCXXXX | | 0x0000 | Reserved | RFCXXXX |
| 0x0001 | Access-Loop-Circuit-ID | RFCXXXX | | 0x0001 | Access-Loop-Circuit-ID | RFCXXXX |
| 0x0002 | Access-Loop-Remote-Id | RFCXXXX | | 0x0002 | Access-Loop-Remote-Id | RFCXXXX |
| 0x0003 | Access-Aggregation-Circuit-ID-ASCII | RFCXXXX | | 0x0003 | Access-Aggregation-Circuit-ID-ASCII | RFCXXXX |
| 0x0004 | DSL Line Attributes | RFCXXXX | | 0x0004 | DSL-Line-Attributes | RFCXXXX |
| 0x0005 | Service-Profile-Name | RFCXXXX | | 0x0005 | Service-Profile-Name | RFCXXXX |
| 0x0006 | Access-Aggregation-Circuit-ID-Binary | RFCXXXX | | 0x0006 | Access-Aggregation-Circuit-ID-Binary | RFCXXXX |
| 0x0007 | OAM-Loopback-Test-Parameters | RFCXXXX | | 0x0007 | OAM-Loopback-Test-Parameters | RFCXXXX |
| 0x0008 | Opaque-Data | RFCXXXX | | 0x0008 | Opaque-Data | RFCXXXX |
| 0x0009 | OAM-Loopback-Test-Response-String | RFCXXXX | | 0x0009 | OAM-Loopback-Test-Response-String | RFCXXXX |
| 0x000a-0x001 | Unassigned | | | 0x000a-0x001 | Unassigned | |
| 0 | | | | 0 | | |
| 0x0011 | Command | RFCXXXX | | 0x0011 | Command | RFCXXXX |
| 0x0012-0x008 | Unassigned | | | 0x0012-0x008 | Unassigned | |
| 0 | | | | 0 | | |
skipping to change at page 61, line 39 skipping to change at page 66, line 39
| 0x0087 | Maximum-Net-Data-Rate-Upstream | RFCXXXX | | 0x0087 | Maximum-Net-Data-Rate-Upstream | RFCXXXX |
| 0x0088 | Maximum-Net-Data-Rate-Downstream | RFCXXXX | | 0x0088 | Maximum-Net-Data-Rate-Downstream | RFCXXXX |
| 0x0089 | Minimum-Net-Low-Power-Data-Rate-Upstre | RFCXXXX | | 0x0089 | Minimum-Net-Low-Power-Data-Rate-Upstre | RFCXXXX |
| | am | | | | am | |
| 0x008A | Minimum-Net-Low-Power-Data-Rate-Downst | RFCXXXX | | 0x008A | Minimum-Net-Low-Power-Data-Rate-Downst | RFCXXXX |
| | ream | | | | ream | |
| 0x008B | Maximum-Interleaving-Delay-Upstream | RFCXXXX | | 0x008B | Maximum-Interleaving-Delay-Upstream | RFCXXXX |
| 0x008C | Actual-Interleaving-Delay-Upstream | RFCXXXX | | 0x008C | Actual-Interleaving-Delay-Upstream | RFCXXXX |
| 0x008D | Maximum-Interleaving-Delay-Downstream | RFCXXXX | | 0x008D | Maximum-Interleaving-Delay-Downstream | RFCXXXX |
| 0x008E | Actual-Interleaving-Delay-Downstream | RFCXXXX | | 0x008E | Actual-Interleaving-Delay-Downstream | RFCXXXX |
| 0x008F | DSL line state | RFCXXXX | | 0x008F | DSL-Line-State | RFCXXXX |
| 0x0090 | Access Loop Encapsulation | RFCXXXX | | 0x0090 | Access-Loop-Encapsulation | RFCXXXX |
| 0x0091 | DSL-Type | RFCXXXX | | 0x0091 | DSL-Type | RFCXXXX |
| 0x092-0x0105 | Unassigned | | | 0x092-0x0105 | Unassigned | |
| 0x0106 | Status-info | RFCXXXX | | 0x0106 | Status-Info | RFCXXXX |
| 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
skipping to change at page 62, line 26 skipping to change at page 67, line 26
| 0 | Reserved | | | RFCXXXX | | 0 | Reserved | | | RFCXXXX |
| 1 | DSL Topology | DSL | None | RFCXXXX | | 1 | DSL Topology | DSL | None | RFCXXXX |
| | Discovery | | | | | | Discovery | | | |
| 2 | DSL Line | DSL | None | RFCXXXX | | 2 | DSL Line | DSL | None | RFCXXXX |
| | Configuration | | | | | | Configuration | | | |
| 3 | Reserved | | | RFCXXXX | | 3 | Reserved | | | RFCXXXX |
| 4 | DSL Line Testing | DSL | None | RFCXXXX | | 4 | DSL Line Testing | DSL | None | RFCXXXX |
| 5-255 | Unassigned | | | | | 5-255 | Unassigned | | | |
+-------+-------------------+------------+--------------+-----------+ +-------+-------------------+------------+--------------+-----------+
8. Security Considerations 10. Security Considerations
Security of the ANCP protocol is discussed in [RFC5713] Security of the ANCP protocol is discussed in [RFC5713]. A number of
security requirements on ANCP are stated in Section 8 of that
document. Those applicable to ANCP itself are listed here:
9. Acknowledgements o The protocol solution MUST offer authentication of the AN to the
NAS.
o The protocol solution MUST offer authentication of the NAS to the
AN.
o The protocol solution MUST allow authorization to take place at
the NAS and the AN.
o The protocol solution MUST offer replay protection.
o The protocol solution MUST provide data-origin authentication.
o The protocol solution MUST be robust against denial-of-service
(DoS) attacks. In this context, the protocol solution MUST
consider a specific mechanism for the DoS that the user might
create by sending many IGMP messages.
o The protocol solution SHOULD offer confidentiality protection.
o The protocol solution SHOULD ensure that operations in default
configuration guarantees a low number of AN/NAS protocol
interactions.
Most of these requirements relate to secure transport of ANCP.
Robustness against denial-of-service attacks partly depends on
transport and partly on protocol design. Ensuring a low number of
AN/NAS protocol interactions in default mode is purely a matter of
protocol design.
For secure transport, either the combination of IPsec with IKEv2
(references below) or the use of TLS [RFC5246] will meet the
requirements listed above. The deciding point is a detail of
protocol design that was unavailable when [RFC5713] was written. The
ANCP adjacency is a major point of vulnerability for denial-of-
service attacks. If the adjacency can be shut down, either the AN
clears its state pending reestablishment of the adjacency, or the
possibility of mismatches between the AN's and NAS's view of state on
the AN is opened up. Two ways to cause an adjacency to be taken down
are to modify messages so that the ANCP agents conclude that they are
no longer synchronized, or to attack the underlying TCP session. TLS
will protect message contents, but not the TCP connection. One has
to use either IPsec or the TCP authentication option [RFC5925] for
that. Hence the conclusion that ANCP MUST run over IPsec with IKEv2
for authentication and key management.
In greater detail: the ANCP stack MUST include IPsec [RFC4301]
running in transport mode, since the AN and NAS are the endpoints of
the path. The Encapsulating Security Payload (ESP) [RFC4303] MUST be
used, in order to satisfy the requirement for data confidentiality.
ESP MUST be configured for the combination of confidentiality,
integrity, anti-replay capability. The traffic flow confidentiality
service of ESP is unnecessary and, in fact, unworkable in the case of
ANCP.
IKEv2 [RFC5996] is also REQUIRED, to meet the requirements for mutual
authentication and authorization. Since the NAS and AN MAY be in
different trust domains, the use of certificates for mutual
authentication could be the most practical approach. However, this
is up to the operator(s) concerned.
The AN MUST play the role of initiator of the IKEv2 conversation.
11. Acknowledgements
The authors would like to thank everyone who provided comments or The authors would like to thank everyone who provided comments 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 12. References
10.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", [RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
RFC 3046, January 2001. RFC 3046, January 2001.
[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 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Specifications: ABNF", STD 68, RFC 5234, January 2008. Internet Protocol", RFC 4301, December 2005.
10.2. Informative References [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
12.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.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security [RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security
Threats and Security Requirements for the Access Node Threats and Security Requirements for the Access Node
Control Protocol (ANCP)", RFC 5713, January 2010. Control Protocol (ANCP)", RFC 5713, January 2010.
[RFC5851] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. [RFC5851] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S.
Wadhwa, "Framework and Requirements for an Access Node Wadhwa, "Framework and Requirements for an Access Node
Control Mechanism in Broadband Multi-Service Networks", Control Mechanism in Broadband Multi-Service Networks",
RFC 5851, May 2010. RFC 5851, May 2010.
[TR_058] Elias, M. and S. Ooghe, "DSL Forum TR-058, Multi-Service [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.
[TR-058] Elias, M. and S. Ooghe, "DSL Forum TR-058, Multi-Service
Architecture & Framework Requirements", September 2003. Architecture & Framework Requirements", September 2003.
[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 (now the Broadband Forum), "DSL Forum TR-092,
requirements document", 2005. Broadband Remote access server 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.
[TR-147] Voight et al, "Layer 2 Control Mechanism For Broadband
Multi-Service Architectures", 2008.
[US_ASCII] [US_ASCII]
American National Standards Institute, "Coded Character American National Standards Institute, "Coded Character
Set - 7-bit American Standard Code for Information Set - 7-bit American Standard Code for Information
Interchange", ANSI X.34, 1986. Interchange", ANSI X.34, 1986.
Authors' Addresses Authors' Addresses
Sanjay Wadhwa Sanjay Wadhwa
Juniper Networks Alcatel-Lucent
10 Technology Park Drive
Westford, MA 01886
USA
Phone: Phone:
Fax: Fax:
Email: swadhwa@juniper.net Email: sanjay.wadhwa@alcatel-lucent.com
Jerome Moisand Jerome Moisand
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
USA USA
Phone: Phone:
Fax: Fax:
Email: jmoisand@juniper.net Email: jmoisand@juniper.net
 End of changes. 414 change blocks. 
1456 lines changed or deleted 1821 lines changed or added

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