Protocol for Access Node Control Mechanism in Broadband Networks
draft-ietf-ancp-protocol-15

Abstract

This document describes the Access Node Control Protocol (ANCP). ANCP operates between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform QoS-related, service-related and subscriber-related operations. Use cases for ANCP are documented in RFC 5851. As well as describing the base ANCP protocol, this document specifies capabilities for Digital Subscriber Line (DSL) topology discovery, line configuration, and remote line connectivity testing. The design of ANCP allows for protocol extensions in other documents if they are needed to support other use cases and other access technologies.

ANCP is based on GSMPv3 (RFC 3292), but with many modifications and extensions, to the point that the two protocols are not interoperable.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on August 6, 2011.

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Table of Contents

1.  Introduction
    1.1.  Requirements Language
    1.2.  Terminology
2.  Broadband Access Aggregation
    2.1.  ATM-based Broadband Aggregation
    2.2.  Ethernet-Based Broadband Aggregation
3.  Access Node Control Protocol -- General Aspects
    3.1.  Protocol Version
    3.2.  ANCP Transport
    3.3.  Encoding of Text Fields
    3.4.  Treatment of Reserved and Unused Fields
    3.5.  Use of the GSMPv3 Adjacency Protocol
        3.5.1.  ANCP Adjacency Message Format
        3.5.2.  ANCP Adjacency Procedures
    3.6.  ANCP General Message Formats
        3.6.1.  The ANCP Message Header
        3.6.2.  The ANCP Message Body
    3.7.  General Principles for the Design of ANCP Messages
4.  Generally Useful ANCP Messages and TLVs
    4.1.  Provisioning Message
    4.2.  Generic Response Message
    4.3.  Target TLV
    4.4.  Command TLV
    4.5.  Status-Info TLV
5.  Introduction To ANCP Capabilities For Digital Subscriber Lines (DSL)
    5.1.  DSL Access Line Identification
        5.1.1.  Control Context (Informative)
        5.1.2.  TLVs For DSL Access Line Identification
6.  ANCP Based DSL Topology Discovery
    6.1.  Control Context (Informative)
    6.2.  Protocol Requirements
        6.2.1.  Protocol Requirements On the AN Side
        6.2.2.  Protocol Requirements On the NAS Side
    6.3.  ANCP Port UP and Port DOWN Event Message Descriptions
    6.4.  Procedures
        6.4.1.  Procedures On the AN Side
        6.4.2.  Procedures On the NAS Side
    6.5.  TLVs For DSL Line Attributes
        6.5.1.  DSL-Line-Attributes TLV
        6.5.2.  DSL-Type TLV
        6.5.3.  Actual-Net-Data-Rate-Upstream TLV
        6.5.4.  Actual-Net-Data-Rate-Downstream TLV
        6.5.5.  Minimum-Net-Data-Rate-Upstream TLV
        6.5.6.  Minimum-Net-Data-Rate-Downstream TLV
        6.5.7.  Attainable-Net-Data-Rate-Upstream TLV
        6.5.8.  Attainable-Net-Data-Rate-Downstream TLV
        6.5.9.  Maximum-Net-Data-Rate-Upstream TLV
        6.5.10.  Maximum-Net-Data-Rate-Downstream TLV
        6.5.11.  Minimum-Net-Low-Power-Data-Rate-Upstream TLV
        6.5.12.  Minimum-Net-Low-Power-Data-Rate-Downstream TLV
        6.5.13.  Maximum-Interleaving-Delay-Upstream TLV
        6.5.14.  Actual-Interleaving-Delay-Upstream TLV
        6.5.15.  Maximum-Interleaving-Delay-Downstream TLV
        6.5.16.  Actual-Interleaving-Delay-Downstream
        6.5.17.  DSL-Line-State TLV
        6.5.18.  Access-Loop-Encapsulation TLV
7.  ANCP based DSL Line Configuration
    7.1.  Control Context (Informative)
    7.2.  Protocol Requirements
        7.2.1.  Protocol Requirements On the NAS Side
        7.2.2.  Protocol Requirements On the AN Side
    7.3.  ANCP Port Management (Line Configuration) Message Format
    7.4.  Procedures
        7.4.1.  Procedures On the NAS Side
        7.4.2.  Procedures On the AN Side
    7.5.  TLVs For DSL Line Configuration
        7.5.1.  Service-Profile-Name TLV
8.  ANCP-Based DSL Remote Line Connectivity Testing
    8.1.  Control Context (Informative)
    8.2.  Protocol Requirements
        8.2.1.  Protocol Requirements On the NAS Side
        8.2.2.  Protocol Requirements On the AN Side
    8.3.  Port Management (OAM) Message Format
    8.4.  Procedures
        8.4.1.  NAS-Side Procedures
        8.4.2.  AN-Side Procedures
    8.5.  TLVs For the DSL Line Remote Connectivity Testing Capability
        8.5.1.  OAM-Loopback-Test-Parameters TLV
        8.5.2.  Opaque-Data TLV
        8.5.3.  OAM-Loopback-Test-Response-String TLV
9.  IANA Considerations
    9.1.  Summary
    9.2.  IANA Actions
10.  Security Considerations
11.  Acknowledgements
12.  References
    12.1.  Normative References
    12.2.  Informative References
§  Authors' Addresses

1.  Introduction

This draft defines a new protocol, the Access Node Control Protocol (ANCP), to realize a control plane between a service-oriented layer 3 edge device (the Network Access Server, NAS) and a layer 2 Access Node (e.g., Digital Subscriber Line Access Module, DSLAM) in order to perform QoS-related, service-related and subscriber-related operations. The requirements for ANCP and the context within which it operates are described in [RFC5851] (Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Wadhwa, “Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks,” May 2010.).

The protocol specification takes GSMPv3 [RFC3292] (Doria, A., Hellstrand, F., Sundell, K., and T. Worster, “General Switch Management Protocol (GSMP) V3,” June 2002.) as a starting point, and the implementor is directed to parts of [RFC3292] (Doria, A., Hellstrand, F., Sundell, K., and T. Worster, “General Switch Management Protocol (GSMP) V3,” June 2002.) 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.

ANCP provides its services to control applications operating in the AN and NAS respectively. This relationship is shown in Figure 1 ( Architectural Context For the Access Node Control Protocol). Specification of the control applications is beyond the scope of this document, but informative partial descriptions are provided as necessary to give a context for the operation of the protocol.

       Access Node                            Network Access Server
  +--------------------+                     +--------------------+
  | +----------------+ |                     | +----------------+ |
  | |   AN Control   | |                     | |  NAS Control   | |
  | |  Application   | |                     | |  Application   | |
  | +----------------+ |                     | +----------------+ |
  | +----------------+ |                     | +----------------+ |
  | |   ANCP Agent   | |    ANCP Messages    | |   ANCP Agent   | |
  | |   (AN side)    |<----------------------->|   (NAS side)   | |
  | +----------------+ |                     | +----------------+ |
  +--------------------+                     +--------------------+

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] (Voight et al, “Layer 2 Control Mechanism For Broadband Multi-Service Architectures,” 2008.). 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 TCP/IP. TCP encapsulation for ANCP is as defined for GSMPv3 in [RFC3293] (Worster, T., Doria, A., and J. Buerkle, “General Switch Management Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and Transmission Control Protocol (TCP),” June 2002.). The alternative GSMPv3 encapsulation directly over Ethernet and ATM as defined in [RFC3293] (Worster, T., Doria, A., and J. Buerkle, “General Switch Management Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and Transmission Control Protocol (TCP),” June 2002.) is not considered for ANCP.

The organization of this document is as follows:

• The next two sub-sections introduce some terminology that will be useful in understanding the rest of the document.
• Section 2 ( Broadband Access Aggregation) provides a description of the access networks within which ANCP will typically be deployed.
• Section 3 (Access Node Control Protocol -- General Aspects) specifies generally applicable aspects of the ANCP protocol.
• Section 4 (Generally Useful ANCP Messages and TLVs) specifies some messages and TLVs intended for use by multiple capabilities spanning multiple technologies.
• Section 5 (Introduction To ANCP Capabilities For Digital Subscriber Lines (DSL)) and the three following sections describe and specify the ANCP implementation of three capabilities applicable to the control of DSL access technology: topology discovery, line configuration, and remote line connectivity testing.
• Section 9 (IANA Considerations) is the IANA Considerations section. Some codepoints are added to existing GSMPv3 registries set up by [RFC3292] (Doria, A., Hellstrand, F., Sundell, K., and T. Worster, “General Switch Management Protocol (GSMP) V3,” June 2002.), but a number of new ANCP-specific registries are also defined.
• Section 10 (Security Considerations) addresses security considerations relating to ANCP, beginning with the requirements stated in [RFC5713] (Moustafa, H., Tschofenig, H., and S. De Cnodder, “Security Threats and Security Requirements for the Access Node Control Protocol (ANCP),” January 2010.).

RFC EDITOR'S NOTE: the following paragraph should be deleted upon publication.

At the time of writing of this specification some implementations of the ANCP protocol based on pre-standards drafts are already available. These early-draft implementations use protocol 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 disambiguate the two protocols and provides support for running a pre-standard and a standards compliant ANCP implementation on any given ANCP node. The mechanism used to identify the protocol version/sub-version is part of the adjacency negotiation process and it is described in detail in Section 3.5 (Use of the GSMPv3 Adjacency Protocol). NOTE: this mechanism does not guarantee backwards compatibility of the published ANCP specification with those early-draft implementations.

1.1.  Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

This specification uses requirements language in lower case and between quotation marks (e.g., "must") to denote requirements on the interface between ANCP and the control application. Such requirements are inherently untestable but need to be taken into account by the implementor.

1.2.  Terminology

This section repeats some definitions from [RFC5851] (Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Wadhwa, “Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks,” May 2010.), but also adds definitions for terms used only in this document.

Access Node (AN):

[RFC5851] (Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Wadhwa, “Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks,” May 2010.) 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] (Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Wadhwa, “Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks,” May 2010.) 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 to the Access Node and the access network. In the case of DSL, 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 case, such a device is also referred to as a Routing Gateway (RG).

ANCP agent:

A logical entity that implements the ANCP protocol in the Access Node (AN-side) or NAS (NAS-side).

Access Node control adjacency:

(modified from [RFC5851] (Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Wadhwa, “Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks,” May 2010.)) the relationship between the AN-side ANCP agent and the NAS-side ANCP 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.

ANCP capability:

A specific set of ANCP messages, message content, and procedures required to implement a specific use case or set of use cases. Some ANCP capabilities are applicable to just one access technology while others are technology independent. The capabilities applicable to a given ANCP adjacency are negotiated during adjacency startup.

Type-Length-Value (TLV):

a data structure consisting of a sixteen-bit type field, a sixteen-bit length field, and a variable-length value field padded to the nearest 32-bit word boundary, as described in Section 3.6.2 (The ANCP Message Body). The value field of a TLV can contain other TLVs. An IANA registry is maintained for values of the ANCP TLV Type field.

Net data rate:

[RFC5851] (Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Wadhwa, “Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks,” May 2010.) defined by ITU-T G.993.2 [G.993.2], Section 3.39, i.e., the portion of the total data rate that can be used to transmit user information (e.g., ATM cells or Ethernet frames). It excludes overhead that pertains to the physical transmission mechanism (e.g., trellis coding in the case of DSL). It includes TPS-TC (Transport Protocol Specific - Transmission Convergence) encapsulation; this is zero for ATM encapsulation, and non-zero for 64/65 encapsulation.

Line rate:

[RFC5851] (Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Wadhwa, “Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks,” May 2010.) defined by ITU-T G.993.2. It contains the complete overhead including Reed-Solomon and trellis coding.

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.

2.  Broadband Access Aggregation

2.1.  ATM-based Broadband Aggregation

The end to end DSL network consists of network service provider (NSP) and application service provider (ASP) networks, regional/access network, and customer premises network. Figure 2 (ATM Broadband Aggregation Topology ) shows ATM broadband access network components.

The regional/access network consists of the regional network, Network Access Server (NAS), and the access network as shown in Figure 2 (ATM Broadband Aggregation Topology ). Its primary function is to provide end-to-end transport between the customer premises and the NSP or ASP.

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 Multiplexer (RAM). The Access Node is the first point in the network where traffic on multiple DSL lines will be aggregated onto a single network.

The NAS performs multiple functions in the network. The NAS is the aggregation point for subscriber traffic. It provides aggregation capabilities (e.g. IP, PPP, ATM) between the Regional/Access Network and the NSP or ASP. These include traditional ATM-based offerings and newer, more native IP-based services. This includes support for Point-to-Point Protocol over ATM (PPPoA) and PPP over Ethernet (PPPoE), as well as direct IP services encapsulated over an appropriate layer 2 transport.

Beyond aggregation, the NAS is also the enforcement point for policy management and IP QoS in the regional/access networks. To allow IP QoS support over an existing non-IP-aware layer 2 access network without using multiple layer 2 QoS classes, a mechanism based on hierarchical scheduling is used. This mechanism, defined in [TR‑059] (Anschutz, T., “DSL Forum TR-059, DSL Evolution - Architecture Requirements for the Support of QoS-Enabled IP Services,” September 2003.), preserves IP QoS over the ATM network between the NAS and the routing gateway (RG) at the edge of the subscriber network, by carefully controlling downstream traffic in the NAS, so that significant queuing and congestion does not occur further down the ATM network. This is achieved by using a diffserv-aware hierarchical scheduler in the NAS that will account for downstream trunk bandwidths and DSL synchronization rates.

[RFC5851] (Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Wadhwa, “Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks,” May 2010.) provides detailed definitions of the functions of each network element in the broadband reference architecture.

                              Access                   Customer
                       <--- Aggregation -->  <------- Premises ------->
                              Network                   Network

                       +------------------+ +--------------------------+
   +---------+   +---+ | +-----+ +------+ | |+-----+ +---+ +---------+ |
NSP|         | +-|NAS|-| |ATM  |-|Access| --||DSL  |-|HGW|-|Subscriber||
---+ Regional| | +---+ | +-----+ | Node | | ||Modem| +---+ |Devices   ||
   |Broadband| | +---+ |         +------+ | |+-----+       +----------+|
ASP|Network  |-+-|NAS| +--------------|---+ +--------------------------+
---+         | | +---+                |     +--------------------------+
   |         | | +---+                |     |+-----+ +---+ +----------+|
   +---------+ +-|NAS|                +-----|| DSL |-|HGW|-|Subscriber||
                 +---+                      ||Modem| +---+ |Devices   ||
                                            |+-----+       +----------+|
                                            +--------------------------+
 HGW   : Home Gateway
 NAS   : Network Access Server

2.2.  Ethernet-Based Broadband Aggregation

The Ethernet aggregation network architecture builds on the Ethernet bridging/switching concepts defined in IEEE 802. The Ethernet aggregation network provides traffic aggregation, class of service distinction, and customer separation and traceability. VLAN tagging defined in IEEE 802.1Q and being enhanced by IEEE 802.1ad is used as standard virtualization mechanism in the Ethernet aggregation network. The aggregation devices are "provider edge bridges" defined in IEEE 802.ad.

Stacked VLAN tags provide one possible way to create equivalent of "virtual paths" and "virtual circuits" in the aggregation network. 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 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 from multiple subscribers behind a DSLAM into a single VLAN in the aggregation network. This is the N:1 VLAN allocation model. Section 1.6 of [TR‑101] (Cohen et al, “Architecture & Transport: "Migration to Ethernet Based DSL Aggregation", DSL Forum TR-101,” 2005.) provides brief definitions of these two models, while section 2.5.1 describes them in more detail.

3.  Access Node Control Protocol -- General Aspects

This section specifies aspects of the Access Node Control Protocol (ANCP) that are generally applicable. As indicated above, ANCP is derived from GSMPv3 [RFC3292] (Doria, A., Hellstrand, F., Sundell, K., and T. Worster, “General Switch Management Protocol (GSMP) V3,” June 2002.). Reference to [RFC3292] (Doria, A., Hellstrand, F., Sundell, K., and T. Worster, “General Switch Management Protocol (GSMP) V3,” June 2002.) is made where this is applicable, but ANCP introduces numerous modifications and extensions to the basic GSMPv3 protocol. Moreover, ANCP uses only a subset of the messages, message contents, and procedures defined for GSMPv3, and defines additional messages, message contents, and procedures that are specific to ANCP.

3.1.  Protocol Version

GSMPv3 messages contain an 8-bit protocol version field. As described below, ANCP subdivides this into two 4-bit sub-fields, for version and sub-version. Implementations of this version of the ANCP 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 of the complete protocol version field MUST be 0x31.

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 the published specification. For an explanation see the Introduction above.

3.2.  ANCP Transport

This document specifies the use of TCP/IP for transport of ANCP messages. Other specifications may introduce additional transports in the future.

In the case of ATM access, a separate PVC (control channel) capable of transporting IP MAY be configured between NAS and the AN for ANCP messages.

In the case of an Ethernet access/aggregation network, a typical practice is to send the Access Node Control Protocol messages over a dedicated Ethernet virtual LAN (VLAN) using a separate VLAN identifier (VLAN ID).

When transported over TCP, ANCP messages MUST use the encapsulation specified for GSMPv3 messages carried over TCP in [RFC3293] (Worster, T., Doria, A., and J. Buerkle, “General Switch Management Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and Transmission Control Protocol (TCP),” June 2002.). This encapsulation consists of a four-byte header field prepended to the ANCP message as shown in Figure 3 (Encapsulation of ANCP Messages Over TCP/IP).

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Identifier (0x880C)        |           Length              |
   |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                         ANCP Message                          ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The fields of the encapsulating header are as follows:

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 as GSMP's Ethertype).

Length:

This 2-byte unsigned integer indicates the total length of the ANCP message, not including the 4-byte encapsulating header.

The Access Node MUST initiate the TCP session to the NAS. This is a deviation from [RFC3293] (Worster, T., Doria, A., and J. Buerkle, “General Switch Management Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and Transmission Control Protocol (TCP),” June 2002.), which requires the controller to initiate the TCP connection to the switch.

This is necessary to avoid static address provisioning on the NAS 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 serves the AN.

The NAS MUST listen for incoming connections from the Access Nodes. Port 6068 is used for TCP connection.

In the event of an ANCP transport protocol failure, all pending ANCP messages destined to the disconnected recipient SHOULD be discarded until the transport connection is re-established.

3.3.  Encoding of Text Fields

In ANCP, all text fields use UTF-8 encoding [RFC3629] (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.). Note that US ASCII characters have the same representation when coded as UTF-8 as they do when coded according to [US_ASCII] (American National Standards Institute, “Coded Character Set - 7-bit American Standard Code for Information Interchange,” 1986.).

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. Some fields are always unused (typically because they were inherited from GSMPv3 but are not useful in the ANCP context). Others are reserved in the current specification, but are provided for flexibility in future extensions to ANCP. Both reserved and unused fields MUST be set to zeroes by the sender and MUST be ignored by the receiver.

Unused bits in a flag field are shown in figures as 'x'. The above requirement (sender set to zero, receiver ignore) applies to such unused bits.

3.5.  Use of the GSMPv3 Adjacency Protocol

Section 11 of [RFC3292] (Doria, A., Hellstrand, F., Sundell, K., and T. Worster, “General Switch Management Protocol (GSMP) V3,” June 2002.) defines the GSMPv3 adjacency protocol. ANCP reuses the GSMPv3 adjacency protocol to synchronize the NAS and Access Nodes and maintain the ANCP session. After the TCP connection is established, adjacency protocol messages MUST be exchanged as specified in Section 11 of [RFC3292] (Doria, A., Hellstrand, F., Sundell, K., and T. Worster, “General Switch Management Protocol (GSMP) V3,” June 2002.), subject to the additional specifications of this section. ANCP messages other than adjacency protocol messages MUST NOT be sent until the adjacency protocol has achieved synchronization.

3.5.1.  ANCP Adjacency Message Format

The GSMPv3 adjacency message format defined in Section 11 of [RFC3292] (Doria, A., Hellstrand, F., Sundell, K., and T. Worster, “General Switch Management Protocol (GSMP) V3,” June 2002.) is modified and extended for ANCP as shown in Figure 4 (ANCP Adjacency Message Format) below. The 8-bit "version" field in the GSMPv3 adjacency protocol messages is modified to carry the ANCP version (four bits) and sub-version (four bits). See Section 3.1 (Protocol Version) for the values to set for version and sub-version for the present version of this specification.

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] (Doria, A., Hellstrand, F., Sundell, K., and T. Worster, “General Switch Management Protocol (GSMP) V3,” June 2002.). 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 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    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Sender Name                          |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                         Receiver Name                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Sender Port                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Receiver Port                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | PType | PFlag |               Sender Instance                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Partition ID  |              Receiver Instance                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Reserved      | # of Caps     | Total Length                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                   Capability Fields                           ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The fields added by ANCP are as follows:

Reserved (8 bits):

reserved for use by a future version of this specification.

# of Caps:

indicates the number of capability fields that follow.

Total Length:

indicates the total number of bytes occupied by the capability fields that follow.

Capability Fields:

Each capability field indicates one ANCP capability supported by the sender of the adjacency message. Negotiation of a common set of capabilities to be supported within the ANCP session is described in Section 3.5.2 (ANCP Adjacency Procedures). The detailed format of a capability field is shown in Figure 5 (Capability Field) and described below.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Capability Type           |   Capability Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                                                               ~
   ~                   Capability Data                             ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The sub-fields of this structure are as follows:

Capability Type:

indicates the specific capability supported. An IANA registry exists for values of this sub-field. The values specified by this document are listed below.

Capability Length:

the number of bytes of data contained in the Capability Data sub-field, excluding padding. If the definition of a particular capability includes no capability data, the value of the Capability Length sub-field is zero.

Capability Data:

contains data associated with the capability as specified for that capability. If the definition of a particular capability includes no capability data, the Capability Data sub-field is absent (has zero length). Otherwise, the Capability Data sub-field MUST be padded with zeroes as required to terminate on a 4-byte word boundary. The possibility of specifying capability data provides the flexibility to advertise more than the mere presence or absence of a capability if needed.

The following capabilities are defined for ANCP as applied to DSL access:

• Capability Type : DSL Topology Discovery = 0x01

  Access technology: DSL

  Length (in bytes) : 0

  Capability Data : NULL

  For the detailed protocol specification of this capability see Section 6 (ANCP Based DSL Topology Discovery).
• Capability Type : DSL Line Configuration = 0x02

  Access technology: DSL

  Length (in bytes) : 0

  Capability Data : NULL

  For the detailed protocol specification of this capability see Section 7 (ANCP based DSL Line Configuration ).
• Capability Type : DSL Remote Line Connectivity Testing = 0x04

  Access technology: DSL

  Length (in bytes) : 0

  Capability Data : NULL

  For the detailed protocol specification of this capability see Section 8 (ANCP-Based DSL Remote Line Connectivity Testing).

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 master). Once the adjacency is established, periodic adjacency messages (type ACK) MUST be exchanged. The default for the ACK interval to be advertised in the adjacency messages is 25 seconds for ANCP. The actual value SHOULD be configurable and is a deployment choice. It is RECOMMENDED that both ends specify the same timer value; to achieve this, each end SHOULD compare the timer value in the first adjacency message it receives with its own preferred value and agree to use the higher of the two values. That is, the node that receives a higher timer value than its own SHOULD reply in its subsequent adjacency messages (such as SYNACK, ACK) with the higher timer value.

In the adjacency protocol the version and sub-version fields are used for version negotiation. The version negotiation MUST be completed before synchronisation is achieved. In a SYN message the version/sub-version fields always contain the highest version understood by the sender. A receiver receiving a SYN message with a version/sub-version higher than it understands MUST silently discard that message. A receiver receiving a SYN message with a version/sub-version within the range of versions that it understands MUST reply with a SYNACK with the version/sub-version from the received SYN in its ANCP version/sub-version fields. This defines the version/sub-version of the ANCP protocol to be used while the adjacency remains synchronized. All other ANCP messages within the session MUST use the agreed version in the version/sub-version fields.

Both the NAS and the Access Node MUST advertise supported capabilities in the adjacency messages they send. The same message MAY advertise capabilities for any mixture of access technologies. If a received adjacency message indicates no support for a capability that is supported by the receiving device, it MUST disable the capability locally and MUST send an updated adjacency message with the corresponding capability field omitted to match the received capability set. This process will eventually result in both sides agreeing on the maximal common set of supported capabilities. The 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 is detected, the adjacency MUST be brought down (RSTACK MUST be generated by the device detecting the mismatch), and synchronization MUST be re-attempted.

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 the adjacency messages.

The GSMPv3 general message format, used by all GSMP messages other than adjacency protocol messages, is defined in Section 3.1.1 of GSMPv3 [RFC3292] (Doria, A., Hellstrand, F., Sundell, K., and T. Worster, “General Switch Management Protocol (GSMP) V3,” June 2002.). ANCP modifies this base GSMPv3 message format as shown in Figure 6 (ANCP General Message Format).

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vers  |  Sub  | Message Type  | Result|        Code           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Partition ID  |            Transaction Identifier             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|      SubMessage Number      |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                          Message Payload                      ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.6.1.  The ANCP Message Header

The immediately visible differences from GSMPv3 are the subdivision of the Version field into version and sub-version, and the reallocation of space between Result and Code to enlarge the range 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-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 long.

A complete explanation of the header fields follows.

3.6.1.1.  Version and Sub-Version Fields

Together these fields reproduce the version of the ANCP protocol that was agreed for the session during adjacency negotiation. See Section 3.1 (Protocol Version) for the values to set for version and sub-version for the present version of this specification.

3.6.1.2.  Message Type Field

This field indicates the ANCP message type. Message type values are registered in a common GSMPv3/ANCP IANA registry.

3.6.1.3.  Result Field

The Result field is derived from GSMPv3 [RFC3292] (Doria, A., Hellstrand, F., Sundell, K., and T. Worster, “General Switch Management Protocol (GSMP) V3,” June 2002.). Ignore (0x0) is a 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.

Ignore:

Res = 0x0 – Treat this field as a "no operation" and follow the response procedures specified for the received message type.

Nack:

Res = 0x1 – Result value indicating that a response is expected to the request only in cases of failure caused during the processing of the message contents or of the contained directive(s).

AckAll:

Res = 0x2 – Result value indicating that a response to the message is requested in all cases.

Success:

Res = 0x3 – Result value indicating that this is a response and that the request was executed successfully. The Code field for a successful result is typically 0, but MAY take on other values as specified for particular message types.

Failure:

Res = 0x4 – Result value indicating that this is a response and that the request was not executed successfully. The receiver 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.

3.6.1.4.  Code Field

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.

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:

• Code value;
• One-line description;
• Where condition detected: (control application or ANCP agent);
• Further description (if any);
• Required additional information in the response message;
• Target (control application or ANCP agent at the peer that sent the original request);
• Action RECOMMENDED for the receiving ANCP agent

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.

ANCP agents MAY use any of the Code values specified in the IANA registry "Global Switch Management Protocol version 3 (GSMPv3) Failure Response Message Name Space" if they appear applicable. In particular, the values 2, 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.

Code value: 2

• One-line description: Invalid request message
• Where condition detected: ANCP agent
• Further description: The request was a properly formed message 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.
• 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 (Generic Response Message) 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 original 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.

Code value: 6

• One-line description: One or more of the specified ports are down
• Where condition detected: control application
• Further description (if any): This Code value indicates a state mismatch between the NAS and AN control applications, possibly due to a race condition.
• 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 line identifier(s) of the access lines that are not operational.
• 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 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 (Generic Response Message) 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] (Doria, A., Hellstrand, F., Sundell, K., and T. Worster, “General Switch Management Protocol (GSMP) V3,” June 2002.).
  
  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 (Generic Response Message) 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 (Generic Response Message) 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] (Doria, A., Hellstrand, F., Sundell, K., and T. Worster, “General Switch Management Protocol (GSMP) V3,” June 2002.).

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 (Generic Response Message) 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:

• The partition ID MAY be configured on the AN and learned by the NAS in the adjacency message; or
• 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 (ANCP Transport).

3.6.2.  The ANCP Message Body

The detailed contents of the message payload portion of a given ANCP message can vary with the capability in the context of which it is being used. However, the general format consists of zero or more fixed fields, followed by a variable amount of data in the form of Type-Length-Value (TLV) data structures.

The general format of a TLV is shown in Figure 7 (General TLV Format):

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type (IANA registered)    |          Length               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                            Value                              ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The fields of a TLV are defined as follows:

Type:

The TLV Type is a 16-bit unsigned value identifying the TLV type and nature of its contents. An IANA registry has been established for ANCP TLV Type codes.

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 boundary (see "Value" below). If a TLV contains other TLVs, any padding in the contained TLVs MUST be included in the value of 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 varying quantity.

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 4-byte word boundary. The Value field of a TLV MAY include fixed fields and/or other TLVs.

Unless otherwise specified, TLVs MAY be added to a message in any order. If the recipient of a message does not understand a particular TLV, it MUST silently ignore it.

A number of TLVs are specified in the remainder of this document.

3.7.  General Principles for the Design of ANCP Messages

The GSMPv3 protocol [RFC3292] (Doria, A., Hellstrand, F., Sundell, K., and T. Worster, “General Switch Management Protocol (GSMP) V3,” June 2002.) 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 8.4 (Procedures), the second by specifications in Section 6.4 (Procedures). 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 3.6 (ANCP General Message Formats) 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 multiple request messages of the same type 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 3.6.1 (The ANCP Message Header).

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).

4.  Generally Useful ANCP Messages and TLVs

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.

4.1.  Provisioning Message

The Provisioning message is sent by the NAS to the AN to provision information of global scope (i.e., not associated with specific access lines) on the AN. The Provisioning message has the format shown in Figure 8 (Format of the Provisioning Message). Support of the Provisioning message is OPTIONAL unless the ANCP agent claims support for a capability that requires its use.

 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                              ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The message header field settings given below are REQUIRED in the Provisioning message. The remaining message header fields MUST be set as specified in Section 3.6.1 (The ANCP Message Header). Which TLVs to carry in the Provisioning message is specified as part of the specification of the capabilities that use that message. 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 3.6.1.6 (Transaction ID).

If the AN can process the message successfully and accept all the provisioning directives contained in it, the AN MUST NOT send any response.

Unless otherwise specified for a particular capability, if the AN fails to process the message successfully it MUST send a Generic Response message (Section 4.2 (Generic Response Message)) indicating failure and providing appropriate diagnostic information.

4.2.  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.

Support of the Generic Response message, both as sender and as receiver, is REQUIRED for all ANCP agents, regardless of what capabilities they support.

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 9 (Structure of the Generic Response 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           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 4.5)                             ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

NOTE: TLVs MAY be in a different order from what is shown in this figure.

This document specifies the following header fields. The remaining fields in the ANCP general message header MUST be set as specified in Section 3.6.1 (The ANCP Message Header).

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.

If the original request applied to a specific access line or set of lines, the TLVs identifying the line(s) and possibly the user MUST be copied into the Generic Response message at the top level.

The Status-Info TLV MAY be present in a success response, to provide a warning as defined for a specific request message type. It MUST be present in a failure response. See Section 4.5 (Status-Info TLV) 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.

To prevent an infinite loop of error responses, if the Generic Response message is itself in error, the receiver MUST NOT generate an error response in return.

4.3.  Target 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.

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 Value field MAY 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 10 (Example of Target TLV For Single Access Line) 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 (Access-Loop-Circuit-ID 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                     ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.4.  Command TLV

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. Support of any specific variant of the Command TLV is OPTIONAL unless the ANCP agent claims support for a capability that requires its use.

Length:

Variable, depending on the specific contents.

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.

4.5.  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. Support of the Status-Info TLV, both as sender and as receiver, is REQUIRED for all ANCP agents, regardless of what capabilities they support.

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 (one byte):

see Section 3.4 (Treatment of Reserved and Unused Fields) 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.

Section 3.6.1.4 (Code Field) provides recommendations for what TLVs to add in the Status-Info TLV for particular values of the message header Code field.

Figure 11 (The Status-Info TLV) 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...                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.  Introduction To ANCP Capabilities For Digital Subscriber Lines (DSL)

DSL is a widely deployed access technology for Broadband Access for Next Generation Networks. Specifications such as [TR‑059] (Anschutz, T., “DSL Forum TR-059, DSL Evolution - Architecture Requirements for the Support of QoS-Enabled IP Services,” September 2003.), [TR‑058] (Elias, M. and S. Ooghe, “DSL Forum TR-058, Multi-Service Architecture & Framework Requirements,” September 2003.), and [TR‑092] (DSL Forum (now the Broadband Forum), “DSL Forum TR-092, Broadband Remote access server requirements document,” 2005.) describe possible architectures for these access networks. The scope of these specifications includes the delivery of voice, video, and data services.

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.

5.1.  DSL Access Line Identification

Most ANCP messages involve actions relating to a specific access 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.

5.1.1.  Control Context (Informative)

Three types of identification are described in [TR‑101] (Cohen et al, “Architecture & Transport: "Migration to Ethernet Based DSL Aggregation", DSL Forum TR-101,” 2005.) and provided for in the TLVs defined in this section:

• identification of an access line by its logical appearance on the user side of the Access Node;
• identification of an access line by its logical appearance on the NAS side of the Access Node; and
• identification down to the user or host level as a supplement to access line identification in one of the other two forms.

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.

Aside from its use in ANCP signalling, access line identification is also used in DHCP transactions involving hosts served by DSL. Either the AN or the NAS can serve as a DHCP relay node. [TR‑101] (Cohen et al, “Architecture & Transport: "Migration to Ethernet Based DSL Aggregation", DSL Forum TR-101,” 2005.) requires the AN or NAS in this role to add access line identification in Option 82 (Information) to each DHCP request it forwards to the DHCP server. It is desirable for efficiency that the identification used in this signalling should be the same as the identification used in ANCP messages.

From the point of view of ANCP itself, the identifiers are opaque. From the point of view of the AN control application, the syntax for the user-side access line identifier is the same as specified in Section 3.9.3 of [TR‑101] (Cohen et al, “Architecture & Transport: "Migration to Ethernet Based DSL Aggregation", DSL Forum TR-101,” 2005.) for DHCP Option 82. The syntax for the ASCII form of the NAS-side access line identifier will be similar.

Access line identification by logical appearance on the user side of the Access Node will always identify a DSL loop uniquely. Identification by the logical appearance on the NAS side of the Access Node is unique only if there is a one-to-one mapping between the appearances on the two sides and no identity-modifying aggregation between the AN and the NAS. In other cases, and in particular in the case of Ethernet aggregation using the N:1 VLAN model, the user-side access line identification is necessary, but the NAS-side identification is potentially useful information allowing the NAS to build up a picture of the aggregation network topology.

Additional identification down to the user or host level is intended to supplement rather than replace either of the other two forms of identification.

Sections 3.8 and 3.9 of [TR‑101] (Cohen et al, “Architecture & Transport: "Migration to Ethernet Based DSL Aggregation", DSL Forum TR-101,” 2005.) are contradictory on this point. It is assumed here that Section 3.9 is meant to be authoritative.

The user-level identification takes the form of an administered string which again is opaque at the ANCP level.

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] (Cohen et al, “Architecture & Transport: "Migration to Ethernet Based DSL Aggregation", DSL Forum TR-101,” 2005.). 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.

5.1.2.  TLVs For DSL Access Line Identification

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] (Cohen et al, “Architecture & Transport: "Migration to Ethernet Based DSL Aggregation", DSL Forum TR-101,” 2005.).

As normative requirements on ANCP agents conforming to this section:

• ANCP agents MUST be able to build and send the Access-Loop-Circuit-ID TLV, the Access-Loop-Remote-Id TLV, and either the Access-Aggregation-Circuit-ID-ASCII TLV or the Access-Aggregation-Circuit-ID-Binary TLV (implementation choice), when passed the associated information from the AN control application.
• ANCP agents MUST be able to receive all four TLV types, extract the relevant information, and pass it to the control application.
• If the Access-Loop-Remote-Id TLV is present in a message, it MUST be accompanied by an Access-Loop-Circuit-ID TLV and/or an Access-Aggregation-Circuit-ID-xxx TLV with two VLAN identifiers.

  The Access-Loop-Remote-Id TLV is not enough to identify an access line uniquely on its own. As indicated above, an Access-Aggregation-Circuit-ID-xxx TLV with two VLAN identifiers may or may not identify an access line uniquely, but this is up to the control application to decide.

• 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.

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

Value:

ASCII string

5.1.2.2.  Access-Loop-Remote-Id TLV

Type:

0x0002

Description:

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] (Cohen et al, “Architecture & Transport: "Migration to Ethernet Based DSL Aggregation", DSL Forum TR-101,” 2005.).

Length:

up to 63 bytes

Value:

ASCII string

5.1.2.3.  Access-Aggregation-Circuit-ID-Binary TLV

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.
For Ethernet access aggregation, where a per-subscriber (stacked) VLAN can be applied (1:1 model as defined in [TR‑101] (Cohen et al, “Architecture & Transport: "Migration to Ethernet Based DSL Aggregation", DSL Forum TR-101,” 2005.)), the TLV contains two value fields. Each field carries a 12-bit VLAN identifier (which is part of the VLAN tag defined by IEEE 802.1Q). The first field MUST carry the inner VLAN identifier, while the second field MUST carry the outer VLAN identifier.

When the N:1 VLAN model is used, only one VLAN tag is available. For the N:1 model, the Access-Aggregation-Circuit-ID-Binary TLV contains a single value field, which MUST carry the 12-bit VLAN identifier derived from the single available VLAN tag.

In the case of an ATM aggregation network, where the DSLAM is directly connected to the NAS (without an intermediate ATM switch), the VPI and VCI on the DSLAM uplink correspond uniquely 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.

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.

The Access-Aggregation-Circuit-ID-Binary is illustrated in Figure 12 (The Access-Aggregation-Circuit-ID-Binary TLV).

Length:

4 or 8 bytes

Value:

one or two 32-bit binary fields.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    TLV Type = 0x0006          |        Length = 4 or 8        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Single VLAN Identifier, inner VLAN identifier, or VCI        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                Outer VLAN identifier or VPI                   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.1.2.4.  Access-Aggregation-Circuit-ID-ASCII TLV

Type:

0x0003

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] (Cohen et al, “Architecture & Transport: "Migration to Ethernet Based DSL Aggregation", DSL Forum TR-101,” 2005.) for the format of the "circuit-id".
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.

Length:

up to 63 bytes

Value:

ASCII string

6.  ANCP Based DSL Topology Discovery

Section 3.1 of [RFC5851] (Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Wadhwa, “Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks,” May 2010.) describes the requirements for the DSL Topology Discovery capability.

6.1.  Control Context (Informative)

The AN control application in the DSLAM requests ANCP to send a DSL-specific Port Up message to the NAS under the following circumstances:

• when a new adjacency with the NAS is established, for each DSL loop that is synchronized at that time;
• subsequent to that, whenever a DSL loop resynchronizes; and
• whenever the AN control application wishes to signal that a line attribute has changed.

The AN control application in the DSLAM requests ANCP to send a DSL-specific Port Down message to the NAS under the following circumstances:

• when a new adjacency with the NAS is established, for each DSL loop that is provisioned but not synchronized at that time;
• whenever a DSL loop that is equipped in an AN but administratively disabled is signalled as "IDLE"; and
• subsequent to that, whenever a DSL loop loses synchronization.

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.

In the case of bonded copper loops to the customer premise (as per 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.

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.

The NAS control application updates its view of the DSL loop state, performs any required accounting operations, and uses any included line attributes to adjust the operation of its queueing/scheduling mechanisms as they apply to data passing to and from that DSL loop.

Figure 13 (ANCP Message Flow For DSL Topology Discovery) summarizes the interaction.

1.   Home            Access                          NAS
    Gateway           Node

          ----------->     -------------------------->
               DSL          Port Up (Event message)
              Signal        (default line parameters)

2.   Home            Access                          NAS
    Gateway           Node

          ----------->     -------------------------->
               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)

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 (ANCP Port UP and Port DOWN Event Message Descriptions).

The AN-side ANCP agent MUST conform to the normative requirements of Section 5.1.2 (TLVs For DSL Access Line Identification).

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 (TLVs For DSL Line Attributes), 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 (Procedures).

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 (ANCP Port UP and Port DOWN Event Message Descriptions).

The NAS-side ANCP agent MUST conform to the normative requirements of Section 5.1.2 (TLVs For DSL Access Line Identification).

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 (Procedures).

The NAS-side ANCP agent MUST be able to extract the information contained in any of the TLVs specified in Section 6.5 (TLVs For DSL Line Attributes) 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] (Doria, A., Hellstrand, F., Sundell, K., and T. Worster, “General Switch Management Protocol (GSMP) V3,” June 2002.). The modified format used for DSL topology discovery is shown in Figure 14 (Format Of the ANCP Port Up and Port Down Event Messages For DSL Topology Discovery).

 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.

See Section 3.6.1 (The ANCP Message Header) 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 (ANCP General Message Formats).

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 (Treatment of Reserved and Unused Fields).

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 (TLVs For DSL Access Line Identification) to identify the DSL loop.

TLVs presenting DSL line attributes (i.e., the TLVs specified in Section 6.5 (TLVs For DSL Line Attributes)) 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 (ANCP Port UP and Port DOWN Event Message Descriptions) and the TLV specifications given in Section 5.1.2 (TLVs For DSL Access Line Identification) and Section 6.5 (TLVs For DSL Line Attributes). 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 (TLVs For DSL Access Line Identification) 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 (Code Field).

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

Description:

Indicates the type of transmission system in use.

Length:

4 bytes

Value:

32 bit unsigned integer

ADSL1 = 1

ADSL2 = 2

ADSL2+ = 3

VDSL1 = 4

VDSL2 = 5

SDSL = 6

OTHER = 0

6.5.3.  Actual-Net-Data-Rate-Upstream TLV

Type:

0x0081

Description:

Actual upstream net data rate on a DSL line.

Length:

4 bytes

Value:

Rate in Kbits/s as a 32 bit unsigned integer

6.5.4.  Actual-Net-Data-Rate-Downstream TLV

Type:

0x0082

Description:

Actual downstream net data rate on a DSL line.

Length:

4 bytes

Value:

Rate in Kbits/s as a 32 bit unsigned integer

6.5.5.  Minimum-Net-Data-Rate-Upstream TLV

Type:

0x0083

Description:

Minimum upstream net data rate desired by the operator.

Length:

4 bytes

Value:

Rate in Kbits/s as a 32 bit unsigned integer

6.5.6.  Minimum-Net-Data-Rate-Downstream TLV

Type:

0x0084

Description:

Minimum downstream net data rate desired by the operator.

Length:

4 bytes

Value:

Rate in Kbits/s as a 32 bit unsigned integer

6.5.7.  Attainable-Net-Data-Rate-Upstream TLV

Type:

0x0085

Description:

Maximum net upstream rate that can be attained on the DSL line.

Length:

4 bytes

Value:

Rate in Kbits/s as a 32 bit unsigned integer

6.5.8.  Attainable-Net-Data-Rate-Downstream TLV

Type:

0x0086

Description:

Maximum net downstream rate that can be attained on the DSL line.

Length:

4 bytes

Value:

Rate in Kbits/s as a 32 bit unsigned integer

6.5.9.  Maximum-Net-Data-Rate-Upstream TLV

Type:

0x0087

Description:

Maximum net upstream data rate desired by the operator.

Length:

4 bytes

Value:

Rate in Kbits/s as a 32 bit unsigned integer

6.5.10.  Maximum-Net-Data-Rate-Downstream TLV

Type:

0x0088

Description:

Maximum net downstream data rate desired by the operator.

Length:

4 bytes

Value:

Rate in Kbits/s as a 32 bit unsigned integer

6.5.11.  Minimum-Net-Low-Power-Data-Rate-Upstream TLV

Type:

0x0089

Description:

Minimum net upstream data rate desired by the operator in low power state.

Length:

4 bytes

Value:

Rate in Kbits/s as a 32 bit unsigned integer

6.5.12.  Minimum-Net-Low-Power-Data-Rate-Downstream TLV

Type:

0x008A

Description:

Minimum net downstream data rate desired by the operator in low power state.

Length:

4 bytes

Value:

Rate in Kbits/s as a 32 bit unsigned integer

6.5.13.  Maximum-Interleaving-Delay-Upstream TLV

Type:

0x008B

Description:

maximum one way interleaving delay.

Length:

4 bytes

Value:

Time in ms as a 32 bit unsigned integer

6.5.14.  Actual-Interleaving-Delay-Upstream TLV

Type:

0x008C

Description:

Value corresponding to the interleaver setting.

Length:

4 bytes

Value:

Time in ms as a 32 bit unsigned integer

6.5.15.  Maximum-Interleaving-Delay-Downstream TLV

Type:

0x008D

Description:

maximum one way interleaving delay.

Length:

4 bytes

Value:

Time in ms as a 32 bit unsigned integer

6.5.16.  Actual-Interleaving-Delay-Downstream

Type:

0x008E

Description:

Value corresponding to the interleaver setting.

Length:

4 bytes

Value:

Time in ms as a 32 bit unsigned integer

6.5.17.  DSL-Line-State TLV

Type:

0x008F

Description:

The state of the DSL line.

Length:

4 bytes

Value:

32 bit unsigned integer

SHOWTIME = 1

IDLE = 2

SILENT = 3

6.5.18.  Access-Loop-Encapsulation TLV

Type:

0x0090

Description:

The data link protocol and, optionally, the encapsulation overhead on the access loop. When this TLV is present, at least the data link protocol MUST be indicated. The encapsulation overhead MAY be indicated. The Access Node MAY choose to not convey the encapsulation on the access loop by specifying values of 0 (NA) for the two encapsulation fields.

Length:

3 bytes

Value:

The three bytes (most to least significant) and valid set of values for each byte are defined as follows:

Byte 1: Data Link

ATM AAL5 = 0

ETHERNET = 1

Byte 2: Encapsulation 1

NA = 0

Untagged Ethernet = 1

Single-tagged Ethernet = 2

Double-tagged Ethernet = 3

Byte 3: Encapsulation 2

NA = 0

PPPoA LLC = 1

PPPoA NULL = 2

IPoA LLC = 3

IPoA NuLL = 4

Ethernet over AAL5 LLC with FCS = 5

Ethernet over AAL5 LLC without FCS = 6

Ethernet over AAL5 NULL with FCS = 7

Ethernet over AAL5 NULL without FCS = 8

The Access-Loop-Encapsulation TLV is illustrated in Figure 15 (The Access-Loop-Encapsulation 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 = 0x0090          |        Length = 3             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Data link     |    Encaps 1   |    Encaps 2   | Padding (=0)  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

7.  ANCP based DSL Line Configuration

The use case for ANCP-based DSL Line Configuration is described in Section 3.2 of [RFC5851] (Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Wadhwa, “Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks,” May 2010.).

7.1.  Control Context (Informative)

Triggered by topology information reporting a new DSL line or triggered by a subsequent user session establishment (PPP or DHCP), RADIUS/AAA sends service parameters to the NAS control application for configuration on the access line. The NAS control application passes the request on to the NAS-side agent, which sends the information to the AN by means of a Port Management (line configuration) message. The AN-side agent passes this information up to the AN control application, which applies it to the line. Figure 16 (Message Flow - ANCP Mapping For Initial Line Configuration) summarizes the interaction.

  Home            Access               NAS             RADIUS/AAA
 Gateway           Node                             Policy Server

       ----------->     --------------->
           DSL          Port Up message)
          Signal       (line parameters)

       -------------------------------->   -------------->
               PPP/DHCP Session            Authentication &
                                           authorization

                       <----------------
                         Port Management message
                         (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 (Message flow - ANCP Mapping For Updated Line Configuration) summarizes the interaction.

User     Home            Access         NAS
        Gateway           Node

             -------------------------->
               PPP/DHCP Session

   -------------------------------------------------------> Web portal,
               Service on demand                              OSS, etc.
                                                                 |
                                           <--------------  RADIUS/AAA
                                             Change of     Policy Server
                                           authorization

                             <------------
                              Port Management
                                  message
                              (new profile)

7.2.  Protocol Requirements

The DSL line configuration capability is assigned capability type 0x0002. No capability data is associated with this capability.

7.2.1.  Protocol Requirements On the NAS Side

The NAS-side ANCP agent MUST be able to create DSL-specific Port Management (line configuration) messages according to the format specified in Section 7.3 (ANCP Port Management (Line Configuration) Message Format).

The NAS-side ANCP agent MUST conform to the normative requirements of Section 5.1.2 (TLVs For DSL Access Line Identification).

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 7.5 (TLVs For DSL Line Configuration).

In the current version of this specification only one such TLV is defined.

The NAS-side ANCP agent MUST package that information as TLVs, and MUST include these TLVs within the Port Management (line configuration) message.

The NAS-side ANCP agent MUST follow the NAS-side procedures associated with DSL-specific Port Management (line configuration) messages as they are specified in Section 7.4 (Procedures).

7.2.2.  Protocol Requirements On the AN Side

The AN-side ANCP agent MUST conform to the normative requirements of Section 5.1.2 (TLVs For DSL Access Line Identification).

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 (ANCP Port Management (Line Configuration) Message Format).

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 (Procedures).

The NAS-side ANCP agent MUST be able to extract the information contained in any of the TLVs listed in Section 7.2.1 (Protocol Requirements On the NAS Side) 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 format shown in Figure 18 (Port Management Message For DSL Line Configuration).

 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)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|x|x|x|x|x|x|x| Dur. (unused) |  Function=8   | 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)                ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                Line configuration TLV(s)                      ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

NOTE: TLVs MAY be in a different order from what is shown in this figure.

See Section 3.6 (ANCP General Message Formats) for a description of the ANCP general message header. 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) or 2 (AckAll), as determined by policy on the NAS. The 24-bit Transaction Identifier field MUST be set to a positive value. Other fields in the general header MUST be set as described in Section 3.6 (ANCP General Message Formats).

As with the Port Up and Port Down messages described above, the Port Management message format defined in [RFC3292] (Doria, A., Hellstrand, F., Sundell, K., and T. Worster, “General Switch Management Protocol (GSMP) V3,” June 2002.) has been modified to contain additional data in an "extension block" at the end of the message. Also, the original two byte Function field has been modified to contain one 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, which further qualifies the action specified in the Function field. Any Function specific data MUST be carried in TLVs in the extension block.

The Port, Port Session Number, and Event Sequence Number fields are not used by the DSL Line Configuration capability. The handling of unused/reserved fields is described in Section 3.4 (Treatment of Reserved and Unused Fields).

The remaining message fields are described as follows:

R Flag:

not used by ANCP.

Additional Port Management flags:

the flag bits marked 'x' following the R flag are not used by ANCP.

Duration:

not used for DSL line configuration.

Function:

action to be performed. For line configuration, Function MUST be set to 8 (Configure Connection Service Data). This action type requests the Access Node (i.e., DSLAM) to apply service configuration data contained in the line configuration TLVs to the DSL line designated by the access line identifying TLVs.

X-Function:

qualifies the action set by Function. For DSL line configuration, this field MUST be set to 0.

Event Flags:

not used by ANCP.

Flow Control Flags:

not used by ANCP.

Extension Flags:

the flag bits denoted by 'x' before the Message Type field are reserved for future use.

Message Type:

Message Type has the same value as in the general header (i.e., 32).

Reserved (16 bits):

reserved for future use.

# 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:

two or more TLVs to identify a DSL line and configure its service data.

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.

Use of the Port Management message for configuration MAY also be generalized to other access technologies, if the respective capabilities specify use of access line identifiers appropriate to those technologies in place of the identifiers defined in Section 5.1.2 (TLVs For DSL Access Line Identification).

7.4.  Procedures

Service configuration MAY be performed on an access line regardless of its current state.

7.4.1.  Procedures On the NAS Side

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 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 (TLVs For DSL Access Line Identification). The NAS MUST include one or more TLVs to configure line service parameters for that line. Section 7.5 (TLVs For DSL Line Configuration) 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 (ANCP Port Management (Line Configuration) Message Format) and the TLV specifications given in Section 5.1.2 (TLVs For DSL Access Line Identification) and Section 7.5 (TLVs For DSL Line Configuration). 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 (Status-Info TLV)) to provide further information on the error, particularly if this is recommended in Section 3.6.1.4 (Code Field) 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. 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 configuration. More TLVs may be defined in a future version of this specification or in ANCP extensions for individual service attributes of a DSL line (e.g. rates, interleaving delay, multicast channel entitlement access-list).

7.5.1.  Service-Profile-Name TLV

Type:

0x0005

Description:

Reference to a pre-configured profile on the DSLAM that contains service specific data for the subscriber.

Length:

up to 64 bytes

Value:

ASCII string containing the profile name (which the NAS learns from a policy server after a subscriber is authorized).

8.  ANCP-Based DSL Remote Line Connectivity Testing

The use case and requirements for ANCP-Based DSL remote line connectivity testing are specified in Section 3.3 of [RFC5851] (Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Wadhwa, “Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks,” May 2010.)

8.1.  Control Context (Informative)

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 timeout parameter indicates the longest that the NAS control application will wait for a result.

The request is passed in a Port Management (OAM) message. If the NAS control application has supplied test parameters, they are used, 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 (Message Flow For ANCP based OAM) summarizes the interaction.

+-------------+    +-----+       +-------+           +----------------+
|Radius/AAA   |----|NAS  |-------| DSLAM |-----------|    CPE         |
|Policy Server|    +-----+       +-------+           | (DSL Modem +   |
+-------------+                                      |Routing Gateway)|
                                                     +----------------+
                 Port Management Message
                 (Remote Loopback          ATM loopback
                  Trigger Request)         OR EFM Loopback
               1.  ---------------->     2. --------->
                                            <--------+
                    3. <---------------
                    Port Management Message
               (Remote Loopback Test Response)

8.2.  Protocol Requirements

The DSL remote line connectivity testing capability is assigned capability type 0x0004. No capability data is associated with this capability.

8.2.1.  Protocol Requirements On the NAS Side

The NAS-side ANCP agent MUST be able to create DSL-specific Port Management (OAM) messages according to the format specified in Section 8.3 (Port Management (OAM) Message Format).

The NAS-side ANCP agent MUST conform to the normative requirements of Section 5.1.2 (TLVs For DSL Access Line Identification).

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 (TLVs For the DSL Line Remote Connectivity Testing Capability).

The NAS-side ANCP agent MUST package that information as TLVs, and MUST include these TLVs within the Port Management (OAM) message.

The NAS-side ANCP agent MUST follow the NAS-side procedures associated with DSL-specific Port Management (OAM) messages as they are specified in Section 8.4 (Procedures).

8.2.2.  Protocol Requirements On the AN Side

The AN-side ANCP agent MUST conform to the normative requirements of Section 5.1.2 (TLVs For DSL Access Line Identification).

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 (Port Management (OAM) Message Format).

The AN-side ANCP agent MUST follow the AN-side procedures associated with DSL-specific Port Management (OAM) messages as specified in Section 8.4 (Procedures).

The NAS-side ANCP agent MUST be able to extract the information contained in any of the TLVs listed in Section 8.2.1 (Protocol Requirements On the NAS Side) 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 as for DSL line configuration (see Section 7.3 (ANCP Port Management (Line Configuration) Message Format)), with the following differences:

• The Result field in the request SHOULD be set to AckAll (0x1), to allow the NAS to receive the information contained in a successful test response.
• The Function field MUST be set to 9 (Remote Loopback). (The X-Function field continues to be 0.)
• The appended TLVs in the extension value field include testing-related TLVs rather than subcriber service information.

The Port Management (OAM) message is illustrated in Figure 20 (Port Management Message For DSL Line Remote Connectivity Testing).

 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)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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                        ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

NOTE: TLVs MAY be in a different order from what is shown in this figure.

8.4.  Procedures

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 (TLVs For DSL Access Line Identification). The NAS MAY include the Opaque-Data TLV and/or the OAM-Loopback-Test-Parameters TLV (defined in Section 8.5 (TLVs For the DSL Line Remote Connectivity Testing Capability)) 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 (Port Management (OAM) Message Format) and the TLV specifications given in Section 5.1.2 (TLVs For DSL Access Line Identification) and Section 8.5 (TLVs For the DSL Line Remote Connectivity Testing Capability). 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 Field). 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 (Status-Info TLV)) to provide further information on the error, particularly if this is recommended in Section 3.6.1.4 (Code Field) 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 (Code Field) 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

1284 (0x504):

DSL line status idle

1285 (0x505):

DSL line status silent

1286 (0x506):

DSL line status training

1287 (0x507):

DSL line integrity error

1288 (0x508):

DSLAM resource not available. The Result header field MUST be set to Failure (0x04).

1289 (0x509):

Invalid test parameter. The Result header field MUST be set to Failure (0x4).

All other fields of the request including the TLVs MUST be copied 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.

8.5.  TLVs For the DSL Line Remote Connectivity Testing Capability

The following TLVs have been defined for use with the DSL line testing capability.

8.5.1.  OAM-Loopback-Test-Parameters TLV

Type:

0x0007

Description:

Parameters intended to override the default values for this loopback test.

Length:

2 bytes

Value:

two unsigned 1 byte fields described below (listed in order of most to least significant).

Byte 1: Count. Number of loopback cells/messages that should be generated on the local loop as part of the loopback test. The Count value SHOULD be greater than 0 and less than or equal to 32.

Byte 2: Timeout. Upper bound on the time in seconds that the NAS will wait for a response from the DSLAM. The value 0 MAY be used, but has a special meaning.

The OAM-Loopback-Test-Parameters TLV is illustrated in Figure 21 (The OAM-Loopback-Test-Parameters 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 = 0x0007          |        Length = 2             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Count       |  Timeout      |         Padding (=0)          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.5.2.  Opaque-Data TLV

Type:

0x0008

Description:

An 8 byte opaque field used by the NAS control application for its own purposes (e.g., response correlation.) The procedures in Section 8.4.2 (AN-Side Procedures) ensure that if it is present in the request it is copied unchanged to the response.

Length:

8 bytes

Value:

Two 32 bit unsigned integers.

8.5.3.  OAM-Loopback-Test-Response-String TLV

Type:

0x0009

Description:

Suitably formatted string containing useful details about the test that the NAS will display for the operator, exactly as received from the DSLAM (no manipulation or interpretation by the NAS).

Length:

up to 128 bytes

Value:

UTF-8 encoded string of text.

9.  IANA Considerations

RFC EDITOR'S NOTE: please replace "RFCXXXX" with the number of this specification.

9.1.  Summary

This section requests the following IANA actions:

• addition of message types to the GSMPv3 Message Type Name Space registry;
• addition of a result type to the GSMPv3 Result Type Name Space registry;
• extension of limits and addition of failure codes to the GSMPv3 Failure Response Message Name Space registry;
• establishment of the following new ANCP registries:

  ANCP Function Codes;

  ANCP Technology Types;

  ANCP Command Codes;

  ANCP TLV Types;

  ANCP Capabilities.

9.2.  IANA Actions

IANA is requested to add a new message category to the GSMPv3 Message Type Name Space registry: "Access Network Control Protocol (ANCP) Messages". IANA is requested to add the following entries under that category:

IANA is requested to implement the following modification to the General Switch Management Protocol version 3 (GSMPv3) Result Type Name Space registry:

IANA is requested to implement the following modifications to the GSMPv3 Failure Response Message Name Space:

• Add the following note to the registry:

  This registry is shared with the Access Node Control Protocol (ANCP) [RFCXXXX]. GSMPv3 [RFC3292] allows values up to a maximum of 255. ANCP extends this maximum to 4095. Hence values above 255 are applicable to ANCP only.

• Extend the table of registration procedures as indicated.
• Add entries to the failure response message name table as indicated.
• Replace the ranges of unassigned codes at the end of the failure response message name table as indicated.

IANA is requested to create a new ANCP Port Management Function Name registry, with the following initial entries. Additions to this registry will be by IETF Consensus. Values may range from 0 to 255.

NOTE: future extensions of ANCP may need to establish sub-registries of permitted X-Function values for specific values of Function.

IANA is requested to create a new ANCP Version registry, with additions by IETF consensus. The initial entries are as follows:

IANA is requested to create a new ANCP Technology Type registry, with additions by IETF Consensus. Values may range from 0 to 255. The initial entries are as follows:

IANA is requested to create a new ANCP Command Code registry, with additions by IETF Consensus. The initial entry is as follows:

IANA is requested to create a new ANCP TLV Type registry, with additions by IETF Consensus. Values may range from 0x0000 to 0xFFFF. New assignments should be in the range of values from 0x0100 upwards. The initial entries are as follows:

IANA is requested to create a new ANCP Capability registry, with additions by IETF Consensus. Values may range from 0 to 255. The specification for a given capability MUST indicate whether it applies to a specific access technology or applies to all access technologies. The specification MUST further indicate whether the capability is associated with any capability data. The initial entries in the ANCP capability registry are as follows:

10.  Security Considerations

Security of the ANCP protocol is discussed in [RFC5713] (Moustafa, H., Tschofenig, H., and S. De Cnodder, “Security Threats and Security Requirements for the Access Node Control Protocol (ANCP),” January 2010.). A number of security requirements on ANCP are stated in Section 8 of that document. Those applicable to ANCP itself are listed here:

• The protocol solution MUST offer authentication of the AN to the NAS.
• The protocol solution MUST offer authentication of the NAS to the AN.
• The protocol solution MUST allow authorization to take place at the NAS and the AN.
• The protocol solution MUST offer replay protection.
• The protocol solution MUST provide data-origin authentication.
• 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.
• The protocol solution SHOULD offer confidentiality protection.
• 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] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) will meet the requirements listed above. The deciding point is a detail of protocol design that was unavailable when [RFC5713] (Moustafa, H., Tschofenig, H., and S. De Cnodder, “Security Threats and Security Requirements for the Access Node Control Protocol (ANCP),” January 2010.) 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] (Touch, J., Mankin, A., and R. Bonica, “The TCP Authentication Option,” June 2010.) 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] (Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,” December 2005.) running in transport mode, since the AN and NAS are the endpoints of the path. The Encapsulating Security Payload (ESP) [RFC4303] (Kent, S., “IP Encapsulating Security Payload (ESP),” December 2005.) 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] (Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, “Internet Key Exchange Protocol Version 2 (IKEv2),” September 2010.) 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 inputs to this document. Swami Subramanian was an early member of the authors' team. The ANCP Working Group is grateful to Roberta Maglione, who served as design team member and primary editor of this document for two years before stepping down. The authors acknowledge the inputs provided by Wojciech Dec, Peter Arberg, Josef Froehler, Derek Harkness, Kim Hyldgaard, Sandy Ng, Robert Peschi, and Michel Platnic.

12.  References

12.1. Normative References

12.2. Informative References

Authors' Addresses