GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc6320

Internet Engineering Task Force (IETF) S. Wadhwa Request for Comments: 6320 Alcatel-Lucent Category: Standards Track J. Moisand ISSN: 2070-1721 Juniper Networks

                                                              T.  Haag
                                                      Deutsche Telekom
                                                              N. Voigt
                                                Nokia Siemens Networks
                                                        T. Taylor, Ed.
                                                   Huawei Technologies
                                                          October 2011
  Protocol for Access Node Control Mechanism in Broadband Networks

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 operations
 related to Quality of Service, service, and subscribers.  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 the General Switch Management Protocol version 3
 (GSMPv3) described in RFC 3292, but with many modifications and
 extensions, to the point that the two protocols are not
 interoperable.  For this reason, ANCP was assigned a separate version
 number to distinguish it.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6320.

Wadhwa, et al. Standards Track [Page 1] RFC 6320 ANCP Protocol October 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 ....................................................5
    1.1. Historical Note ............................................6
    1.2. Requirements Language ......................................6
    1.3. Terminology ................................................6
 2. Broadband Access Aggregation ....................................8
    2.1. ATM-Based Broadband Aggregation ............................8
    2.2. Ethernet-Based Broadband Aggregation .......................9
 3. Access Node Control Protocol -- General Aspects ................10
    3.1. Protocol Version ..........................................10
    3.2. ANCP Transport ............................................10
    3.3. Encoding of Text Fields ...................................11
    3.4. Treatment of Reserved and Unused Fields ...................12
    3.5. The ANCP Adjacency Protocol ...............................12
         3.5.1. ANCP Adjacency Message Format ......................12
         3.5.2. ANCP Adjacency Procedures ..........................18
    3.6. ANCP General Message Formats ..............................29
         3.6.1. The ANCP Message Header ............................29
         3.6.2. The ANCP Message Body ..............................36
    3.7. General Principles for the Design of ANCP Messages ........37

Wadhwa, et al. Standards Track [Page 2] RFC 6320 ANCP Protocol October 2011

 4. Generally Useful ANCP Messages and TLVs ........................38
    4.1. Provisioning Message ......................................38
    4.2. Generic Response Message ..................................39
    4.3. Target TLV ................................................41
    4.4. Command TLV ...............................................41
    4.5. Status-Info TLV ...........................................42
 5. Introduction to ANCP Capabilities for Digital
    Subscriber Lines (DSLs) ........................................43
    5.1. DSL Access Line Identification ............................44
         5.1.1. Control Context (Informative) ......................44
         5.1.2. TLVs for DSL Access Line Identification ............45
 6. ANCP-Based DSL Topology Discovery ..............................48
    6.1. Control Context (Informative) .............................48
    6.2. Protocol Requirements .....................................50
         6.2.1. Protocol Requirements on the AN Side ...............50
         6.2.2. Protocol Requirements on the NAS Side ..............50
    6.3. ANCP Port Up and Port Down Event Message Descriptions .....51
    6.4. Procedures ................................................52
         6.4.1. Procedures on the AN Side ..........................52
         6.4.2. Procedures on the NAS Side .........................53
    6.5. TLVs for DSL Line Attributes ..............................53
         6.5.1. DSL-Line-Attributes TLV ............................53
         6.5.2. DSL-Type TLV .......................................54
         6.5.3. Actual-Net-Data-Rate-Upstream TLV ..................54
         6.5.4. Actual-Net-Data-Rate-Downstream TLV ................54
         6.5.5. Minimum-Net-Data-Rate-Upstream TLV .................55
         6.5.6. Minimum-Net-Data-Rate-Downstream TLV ...............55
         6.5.7. Attainable-Net-Data-Rate-Upstream TLV ..............55
         6.5.8. Attainable-Net-Data-Rate-Downstream TLV ............55
         6.5.9. Maximum-Net-Data-Rate-Upstream TLV .................56
         6.5.10. Maximum-Net-Data-Rate-Downstream TLV ..............56
         6.5.11. Minimum-Net-Low-Power-Data-Rate-Upstream TLV ......56
         6.5.12. Minimum-Net-Low-Power-Data-Rate-Downstream TLV ....56
         6.5.13. Maximum-Interleaving-Delay-Upstream TLV ...........57
         6.5.14. Actual-Interleaving-Delay-Upstream TLV ............57
         6.5.15. Maximum-Interleaving-Delay-Downstream TLV .........57
         6.5.16. Actual-Interleaving-Delay-Downstream ..............57
         6.5.17. DSL-Line-State TLV ................................58
         6.5.18. Access-Loop-Encapsulation TLV .....................58
 7. ANCP-Based DSL Line Configuration ..............................59
    7.1. Control Context (Informative) .............................59
    7.2. Protocol Requirements .....................................61
         7.2.1. Protocol Requirements on the NAS Side ..............61
         7.2.2. Protocol Requirements on the AN Side ...............61
    7.3. ANCP Port Management (Line Configuration) Message Format ..62
    7.4. Procedures ................................................64
         7.4.1. Procedures on the NAS Side .........................64
         7.4.2. Procedures on the AN Side ..........................64

Wadhwa, et al. Standards Track [Page 3] RFC 6320 ANCP Protocol October 2011

    7.5. TLVs for DSL Line Configuration ...........................64
         7.5.1. Service-Profile-Name TLV ...........................65
 8. ANCP-Based DSL Remote Line Connectivity Testing ................65
    8.1. Control Context (Informative) .............................65
    8.2. Protocol Requirements .....................................66
         8.2.1. Protocol Requirements on the NAS Side ..............66
         8.2.2. Protocol Requirements on the AN Side ...............66
    8.3. Port Management (OAM) Message Format ......................67
    8.4. Procedures ................................................68
         8.4.1. NAS-Side Procedures ................................68
         8.4.2. AN-Side Procedures .................................69
    8.5. TLVs for the DSL Line Remote Connectivity Testing
         Capability ................................................70
         8.5.1. OAM-Loopback-Test-Parameters TLV ...................70
         8.5.2. Opaque-Data TLV ....................................71
         8.5.3. OAM-Loopback-Test-Response-String TLV ..............71
 9. IANA Considerations ............................................71
 10. IANA Actions ..................................................72
    10.1. ANCP Message Type Registry ...............................72
    10.2. ANCP Result Code Registry ................................73
    10.3. ANCP Port Management Function Registry ...................74
    10.4. ANCP Technology Type Registry ............................75
    10.5. ANCP Command Code Registry ...............................75
    10.6. ANCP TLV Type Registry ...................................75
    10.7. ANCP Capability Type Registry ............................77
    10.8. Joint GSMP / ANCP Version Registry .......................77
 11. Security Considerations .......................................77
 12. Contributors ..................................................79
 13. Acknowledgements ..............................................79
 14. References ....................................................79
    14.1. Normative References .....................................79
    14.2. Informative References ...................................80

Wadhwa, et al. Standards Track [Page 4] RFC 6320 ANCP Protocol October 2011

1. Introduction

 This document 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
 Multiplexer, DSLAM) in order to perform operations related to quality
 of service (QoS), services, and subscriptions.  The requirements for
 ANCP and the context within which it operates are described in
 [RFC5851].
 ANCP provides its services to control applications operating in the
 AN and NAS, respectively.  This relationship is shown in Figure 1.
 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)   | |
   | +----------------+ |                     | +----------------+ |
   +--------------------+                     +--------------------+
 Figure 1:  Architectural Context for the Access Node Control Protocol
 At various points in this document, information flows between the
 control applications and ANCP are described.  The purpose of such
 descriptions is to clarify the boundary between this specification
 and, for example, [TR-147].  There is no intention to place limits on
 the degree to which the control application and the protocol
 implementation are integrated.
 This specification specifies ANCP transport over TCP/IP.  TCP
 encapsulation for ANCP is as defined in Section 3.2.
 The organization of this document is as follows:
 o  Sections 1.2 and 1.3 introduce some terminology that will be
    useful in understanding the rest of the document.
 o  Section 2 provides a description of the access networks within
    which ANCP will typically be deployed.

Wadhwa, et al. Standards Track [Page 5] RFC 6320 ANCP Protocol October 2011

 o  Section 3 specifies generally applicable aspects of ANCP.
 o  Section 4 specifies some messages and TLVs intended for use by
    multiple capabilities spanning multiple technologies.
 o  Section 5 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.
 o  Section 9 is the IANA Considerations section.  This section
    defines a number of new ANCP-specific registries as well as the
    joint GSMP/ANCP version registry mentioned below.
 o  Section 11 addresses security considerations relating to ANCP,
    beginning with the requirements stated in [RFC5713].

1.1. Historical Note

 Initial implementations of the protocol that became ANCP were based
 on the General Switch Management Protocol version 3 (GSMPv3)
 [RFC3292].  The ANCP charter required the Working Group to develop
 its protocol based on these implementations.  In the end, ANCP
 introduced so many extensions and modifications to GSMPv3 that the
 two protocols are not interoperable.  Nevertheless, although this
 specification has no normative dependencies on [RFC3292], the mark of
 ANCP's origins can be seen in the various unused fields within the
 ANCP message header.
 Early in ANCP's development, the decision was made to use the same
 TCP port and encapsulation as GSMPv3, and by the time ANCP was
 finished, it was too late to reverse that decision because of
 existing implementations.  As a result, it is necessary to have a way
 for an ANCP peer to quickly distinguish ANCP from GSMP during initial
 adjacency negotiations.  This has been provided by a joint registry
 of GSMP and ANCP version numbers.  GSMP has version numbers 1 through
 3.  ANCP has the initial version number 50.

1.2. 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].

1.3. Terminology

 This section repeats some definitions from [RFC5851], but it also
 adds definitions for terms used only in this document.

Wadhwa, et al. Standards Track [Page 6] RFC 6320 ANCP Protocol October 2011

 Access Node (AN):  [RFC5851] Network device, usually located at a
    service provider central office or street cabinet that terminates
    access (local) loop connections from subscribers.  In case the
    access loop is a Digital Subscriber Line (DSL), the Access Node
    provides DSL signal termination and is referred to as a DSL Access
    Multiplexer (DSLAM).
 Network Access Server (NAS):  [RFC5851] Network element that
    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 ANCP in the Access Node
    (AN-side) or NAS (NAS-side).
 Access Node control adjacency:  (modified from [RFC5851]) 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 be either 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 16-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 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] 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

Wadhwa, et al. Standards Track [Page 7] RFC 6320 ANCP Protocol October 2011

    TPS-TC (Transport Protocol Specific - Transmission Convergence)
    encapsulation; this is zero for ATM encapsulation and non-zero for
    64/65 encapsulation.
 Line rate:  [RFC5851] 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 access lines into a single bidirectional logical link,
    henceforth referred to in this document 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
    [G.998.1] and G.998.2 [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 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.
 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, a remote DSLAM, or a Remote Access
 Multiplexer (RAM).  The Access Node is the first point in the network
 where traffic on multiple DSL access 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

Wadhwa, et al. Standards Track [Page 8] RFC 6320 ANCP Protocol October 2011

 without using multiple layer 2 QoS classes, a mechanism based on
 hierarchical scheduling is used.  This mechanism, defined in
 [TR-059], preserves IP QoS over the ATM network between the NAS and
 the Routing Gateway (RG) at the edge of the subscriber network, by
 carefully controlling downstream traffic in the NAS, so that
 significant queuing and congestion do not occur farther 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] 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

             Figure 2: ATM Broadband Aggregation Topology

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 [IEEE802.1Q] and enhanced by [IEEE802.1ad], is used as the
 standard virtualization mechanism in the Ethernet aggregation
 network.  The aggregation devices are "provider edge bridges" defined
 in [IEEE802.1ad].
 Stacked VLAN tags provide one possible way to create an equivalent of
 "virtual paths" and "virtual circuits" in the aggregation network.
 The "outer" VLAN can be used to create a form of "virtual path"

Wadhwa, et al. Standards Track [Page 9] RFC 6320 ANCP Protocol October 2011

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

3.1. Protocol Version

 ANCP messages contain an 8-bit protocol version field.  For the
 protocol version specified in this document, the value of that field
 MUST be set to 50.

3.2. ANCP Transport

 This document specifies the use of TCP / IPsec+IKEv2 / IP for
 transport of ANCP messages.  For further discussion of the use of
 IPsec and IKEv2, see Section 11.  The present section deals with the
 TCP aspects.  Other specifications may introduce additional
 transports in the future.
    In the case of ATM access, a separate permanent virtual circuit
    (PVC) that is a control channel and is capable of transporting IP
    MAY be configured between the 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 an encapsulation
 consisting of a 4-byte header field prepended to the ANCP message as
 shown in Figure 3.

Wadhwa, et al. Standards Track [Page 10] RFC 6320 ANCP Protocol October 2011

     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                          ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         Figure 3: Encapsulation of ANCP Messages over TCP/IP
 The fields of the encapsulating header are as follows:
 Identifier (16 bits):  This identifies a GSMP or ANCP message.  It
    MUST be set to 0x880C.
 Length (16 bits):  Total length of the ANCP message in bytes, not
    including the 4-byte encapsulating header.
 The Access Node MUST initiate the TCP session to the NAS, using
 destination port 6068.
    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 on port 6068 for incoming connections from the
 Access Nodes.
 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].  Note that US-
 ASCII characters have the same representation when coded as UTF-8 as
 they do when coded according to [US_ASCII].
 When extracting text fields from a message, the ANCP agent MUST NOT
 assume that the fields are zero-terminated.

Wadhwa, et al. Standards Track [Page 11] RFC 6320 ANCP Protocol October 2011

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. The ANCP Adjacency Protocol

 ANCP uses the 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 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 ANCP adjacency message format is shown in Figure 4 below.

Wadhwa, et al. Standards Track [Page 12] RFC 6320 ANCP Protocol October 2011

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Version   | Message Type  |     Timer     |M|     Code    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Sender Name                          |
    +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
    |                         Receiver Name                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Sender Port                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Receiver Port                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | PType |P Flag |               Sender Instance                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Partition ID  |              Receiver Instance                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Reserved      | # of Caps     | Total Length                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                   Capability Fields                           ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Figure 4: ANCP Adjacency Message Format
 The fields of the ANCP adjacency message are as follows:
 Version (8 bits):  ANCP version, which is subject to negotiation.
    This is the key parameter by means of which ANCP messages can be
    distinguished from GSMP messages received over the same port.
 Message Type (8 bits):  Always has value 10 (adjacency protocol).
 Timer (8 bits):  The Timer field is used to negotiate the timer value
    used in the adjacency protocol with the peer.  The timer specifies
    the nominal time between periodic adjacency protocol messages.  It
    is a constant for the duration of an ANCP session.  The Timer
    field is specified in units of 100 ms, with a default value of 250
    (i.e., 25 seconds).
 M flag (1 bit):  Used in the SYN message to prevent the NAS from
    synchronizing with another NAS and the AN from synchronizing with
    another AN.  In the SYN message, it is always set to 1 by the NAS
    and to 0 by the AN.  In other adjacency message types, it is
    always set to 0 by the sender and ignored by the receiver.

Wadhwa, et al. Standards Track [Page 13] RFC 6320 ANCP Protocol October 2011

 Code (7 bits):  The adjacency protocol message type.  It MUST have
    one of the following values:
       Code = 1: SYN;
       Code = 2: SYNACK;
       Code = 3: ACK;
       Code = 4: RSTACK.
 Sender Name (48 bits):  For the SYN, SYNACK, and ACK messages, is the
    identifier of the entity sending the message.  The Sender Name is
    a 48-bit quantity that is unique within the operational context of
    the device.  A 48-bit IEEE 802 Media Access Control (MAC) address,
    if available, may be used for the Sender Name.  If the Ethernet
    encapsulation is used, the Sender Name MUST be the Source Address
    from the MAC header.  For the RSTACK message, the Sender Name
    field is set to the value of the Receiver Name field from the
    incoming message that caused the RSTACK message to be generated.
 Receiver Name (48 bits)  For the SYN, SYNACK, and ACK messages, is
    the name of the entity that the sender of the message believes is
    at the far end of the link.  If the sender of the message does not
    know the name of the entity at the far end of the link, this field
    SHOULD be set to zero.  For the RSTACK message, the Receiver Name
    field is set to the value of the Sender Name field from the
    incoming message that caused the RSTACK message to be generated.
 Sender Port (32 bits):  For the SYN, SYNACK, and ACK messages, is the
    local port number of the link across which the message is being
    sent.  For the RSTACK message, the Sender Port field is set to the
    value of the Receiver Port field from the incoming message that
    caused the RSTACK message to be generated.
 Receiver Port (32 bits):  For the SYN, SYNACK, and ACK messages, is
    what the sender believes is the local port number for the link,
    allocated by the entity at the far end of the link.  If the sender
    of the message does not know the port number at the far end of the
    link, this field SHOULD be set to zero.  For the RSTACK message,
    the Receiver Port field is set to the value of the Sender Port
    field from the incoming message that caused the RSTACK message to
    be generated.
 PType (4 bits):  PType is used to specify if partitions are used and
    how the Partition ID is negotiated.

Wadhwa, et al. Standards Track [Page 14] RFC 6320 ANCP Protocol October 2011

       Type of partition being requested:
       0 - no partition;
       1 - fixed partition request;
       2 - fixed partition assigned.
 P Flag (4 bits):  Used to indicate the type of partition request.
       1 - new adjacency;
       2 - recovered adjacency.
    In case of a conflict between the peers' views of the value of the
    P Flag, the lower value is used.
 Sender Instance (24 bits):  For the SYN, SYNACK, and ACK messages, is
    the sender's instance number for the link to the peer.  It is used
    to detect when the link comes back up after going down or when the
    identity of the entity at the other end of the link changes.  The
    instance number is a 24-bit number that is guaranteed to be unique
    within the recent past and to change when the link or node comes
    back up after going down.  Zero is not a valid instance number.
    For the RSTACK message, the Sender Instance field is set to the
    value of the Receiver Instance field from the incoming message
    that caused the RSTACK message to be generated.
 Partition ID (8 bits):  Field used to associate the message with a
    specific partition of the AN.  The value of this field is
    negotiated during the adjacency procedure.  The AN makes the final
    decision, but will consider a request from the NAS.  If the AN
    does not support partitions, the value of this field MUST be 0.
    Otherwise, it MUST be non-zero.
 Receiver Instance (24 bits):  For the SYN, SYNACK, and ACK messages,
    is what the sender believes is the current instance number for the
    link, allocated by the entity at the far end of the link.  If the
    sender of the message does not know the current instance number at
    the far end of the link, this field SHOULD be set to zero.  For
    the RSTACK message, the Receiver Instance field is set to the
    value of the Sender Instance field from the incoming message that
    caused the RSTACK message to be generated.
 Reserved (8 bits):  Reserved for use by a future version of this
    specification.

Wadhwa, et al. Standards Track [Page 15] RFC 6320 ANCP Protocol October 2011

 # of Caps (8 bits):  Indicates the number of Capability fields that
    follow.
 Total Length (16 bits):  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 below.  The detailed format of a
    Capability field is shown in Figure 5 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                             ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      Figure 5: Capability Field
 The sub-fields of this structure are as follows:
 Capability Type (16 bits):  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 (16 bits):  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 (as indicated by Capability Length):  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.

Wadhwa, et al. Standards Track [Page 16] RFC 6320 ANCP Protocol October 2011

 The following capabilities are defined for ANCP as applied to DSL
 access:
 o  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.
 o  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.
 o  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.
 In addition to the adjacency messages whose format is shown in
 Figure 6, ANCP adjacency procedures use the Adjacency Update message
 (Figure 6) to inform other NASs controlling the same AN partition
 when a particular NAS joins or loses an adjacency with that
 partition.

Wadhwa, et al. Standards Track [Page 17] RFC 6320 ANCP Protocol October 2011

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Version    | Message Type  | Result|        Code           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Partition ID  |            Transaction Identifier             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |I|      SubMessage Number      |           Length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Figure 6: The Adjacency Update Message
 The Adjacency Update message is identical to the general ANCP message
 header described in Section 3.6, but the field settings are in part
 specific to the Adjacency Update message.  The fields in this message
 are as follows:
 Version (8 bits):  The ANCP version negotiated and running in this
    adjacency.
 Message Type (8 bits):  Always 85.
 Result (4 bits):  Set to Ignore (0).
 Code (12 bits):  Set to the total number of adjacencies currently
    established on this partition, from the point of view of the AN.
 Partition ID (8 bits):  The partition identifier of the partition for
    which this notification is being sent.
 Transaction Identifier (24 bits):  MUST be set to 0.
 I (1 bit), SubMessage number (15 bits):  Set as described in
    Section 3.6.1.7.
 Length (16 bits):  Set as described in Section 3.6.1.8.

3.5.2. ANCP Adjacency Procedures

3.5.2.1. Overview

 The ANCP adjacency protocol operates symmetrically between the NAS
 and the AN.  In the absence of errors or race conditions, each peer
 sends a SYN message, receives a SYNACK message in acknowledgement,
 and completes the establishment of the adjacency by sending an ACK
 message.  Through this exchange, each peer learns the values of the
 Name, Port, and Instance parameters identifying the other peer, and

Wadhwa, et al. Standards Track [Page 18] RFC 6320 ANCP Protocol October 2011

 the two peers negotiate the values of the Version, Timer, P Flag, and
 Partition ID parameters and the set of capabilities that the
 adjacency will support.
 Once the adjacency has been established, its liveness is periodically
 tested.  The peers engage in an ACK message exchange at a frequency
 determined by the negotiated value of the Timer field.
 If an inconsistency, loss of contact, or protocol violation is
 detected, the detecting peer can force a restart of the
 synchronization process by sending an RSTACK message to the other
 end.
 Once an adjacency has been established, if more than one NAS has
 established an adjacency to the same partition, then the AN sends an
 Adjacency Update message to each such NAS to let it know how many
 established adjacencies the partition currently supports.  Similarly,
 if an adjacency is lost, the AN sends an Adjacency Update message to
 each of the remaining adjacent NASs to let them know about the change
 in status.

3.5.2.2. Adjacency Protocol State Machine

 The adjacency protocol is described by the following rules and state
 tables.  It begins with the sending of a SYN by each end as soon as
 the transport connection has been established.  If at any point the
 operations A, B, C, or "Verify Adjacent State" defined below detect a
 mismatch, a log SHOULD be generated, identifying the fields concerned
 and the expected and received values for each.
 The rules and state tables use the following operations:
 o  The "Record Adjacency State" operation is defined in
    Section 3.5.2.3.2.
 o  The "Verify Adjacency State" operation consists of verifying that
    the contents of the incoming SYNACK message match the adjacency
    state values previously recorded.
 o  The procedure "Reset the link" is defined as:
    1.  Generate a new instance number for the link.
    2.  Delete the peer verifier (set to zero the values of Sender
        Instance, Sender Port, and Sender Name previously stored by
        the "Record Adjacency State" operation).
    3.  Send a SYN message (Section 3.5.2.3.1).

Wadhwa, et al. Standards Track [Page 19] RFC 6320 ANCP Protocol October 2011

    4.  Enter the SYNSENT state.
 o  The state tables use the following Boolean terms and operators.
    A.  The Sender Instance in the incoming message matches the value
        stored from a previous message by the "Record Adjacency State"
        operation.
    B.  The Sender Instance, Sender Port, Sender Name, and Partition
        ID fields in the incoming message match the values stored from
        a previous message by the "Record Adjacency State" operation.
    C.  The Receiver Instance, Receiver Port, Receiver Name, and
        Partition ID fields in the incoming message match the values
        of the Sender Instance, Sender Port, Sender Name, and
        Partition ID currently sent in outgoing SYN, SYNACK, and ACK
        messages, except that the NAS always accepts the Partition ID
        value presented to it in a SYN or SYNACK message.
       "&&" Represents the logical AND operation.
       "||" Represents the logical OR operation.
       "!"  Represents the logical negation (NOT) operation.
 o  A timer is required for the periodic generation of SYN, SYNACK,
    and ACK messages.  The value of the timer is negotiated in the
    Timer field.  The period of the timer is unspecified, but a value
    of 25 seconds is suggested.  Note that since ANCP uses a reliable
    transport protocol, the timer is unlikely to expire in any state
    other than ESTAB.
    There are two independent events: the timer expires, and a packet
    arrives.  The processing rules for these events are:
       Timer Expires: Reset Timer
          If state = SYNSENT Send SYN
          If state = SYNRCVD Send SYNACK
          If state = ESTAB Send ACK

Wadhwa, et al. Standards Track [Page 20] RFC 6320 ANCP Protocol October 2011

       Packet Arrives:
          If incoming message is an RSTACK:
             If (A && C && !SYNSENT) Reset the link
             Else discard the message.
          If incoming message is a SYN, SYNACK, or ACK:
             Response defined by the following state tables.
          If incoming message is any other ANCP message and state !=
          ESTAB:
             Discard incoming message.
             If state = SYNSENT Send SYN (Note 1)
             If state = SYNRCVD Send SYNACK (Note 1)
       Note 1: No more than two SYN or SYNACK messages should be sent
       within any time period of length defined by the timer.
 o  State synchronization across a link is considered to be achieved
    when the protocol reaches the ESTAB state.  All ANCP messages,
    other than adjacency protocol messages, that are received before
    synchronization is achieved will be discarded.

3.5.2.2.1. State Tables

  State: SYNSENT
 +===================================================================+
 |    Condition    |                Action               | New State |
 +=================+=====================================+===========+
 |   SYNACK && C   |  Update Peer Verifier; Send ACK     |   ESTAB   |
 +-----------------+-------------------------------------+-----------+
 |   SYNACK && !C  |            Send RSTACK              |  SYNSENT  |
 +-----------------+-------------------------------------+-----------+
 |       SYN       |  Update Peer Verifier; Send SYNACK  |  SYNRCVD  |
 +-----------------+-------------------------------------+-----------+
 |       ACK       |            Send RSTACK              |  SYNSENT  |
 +===================================================================+

Wadhwa, et al. Standards Track [Page 21] RFC 6320 ANCP Protocol October 2011

  State: SYNRCVD
 +===================================================================+
 |    Condition    |                Action               | New State |
 +=================+=====================================+===========+
 |   SYNACK && C   |  Verify Adjacency State; Send ACK   |   ESTAB   |
 +-----------------+-------------------------------------+-----------+
 |   SYNACK && !C  |            Send RSTACK              |  SYNRCVD  |
 +-----------------+-------------------------------------+-----------+
 |       SYN       | Record Adjacency State; Send SYNACK |  SYNRCVD  |
 +-----------------+-------------------------------------+-----------+
 |  ACK && B && C  |              Send ACK               |   ESTAB   |
 +-----------------+-------------------------------------+-----------+
 | ACK && !(B && C)|            Send RSTACK              |  SYNRCVD  |
 +===================================================================+
  State: ESTAB
 +===================================================================+
 |    Condition    |                Action               | New State |
 +=================+=====================================+===========+
 |  SYN || SYNACK  |           Send ACK (Note 2)         |   ESTAB   |
 +-----------------+-------------------------------------+-----------+
 |  ACK && B && C  |           Send ACK (Note 3)         |   ESTAB   |
 +-----------------+-------------------------------------+-----------+
 | ACK && !(B && C)|              Send RSTACK            |   ESTAB   |
 +===================================================================+
 Note 2: No more than two ACKs should be sent within any time period
 of length defined by the timer.  Thus, one ACK MUST be sent every
 time the timer expires.  In addition, one further ACK may be sent
 between timer expirations if the incoming message is a SYN or SYNACK.
 This additional ACK allows the adjacency protocol to reach
 synchronization more quickly.
 Note 3: No more than one ACK should be sent within any time period of
 length defined by the timer.

3.5.2.3. The Adjacency Protocol SYN Message

3.5.2.3.1. Action by the Sender

 The SYN message is sent in accordance with the state tables just
 described.  The sender sets the individual fields as follows:

Wadhwa, et al. Standards Track [Page 22] RFC 6320 ANCP Protocol October 2011

 Version:  SHOULD be set to the highest version of ANCP that the
    sender supports.
 Message Type:  MUST be set to 10.
 Timer:  SHOULD be set to the value configured in the AN or NAS
    sending the message.
 M Flag:  MUST be set to 1 by the NAS, and 0 by the AN.
 Code:  MUST be set to 1 (SYN).
 Sender Name:  Set as described in Section 3.5.1.
 Receiver Name:  SHOULD be set to 0.
 Sender Port:  Set as described in Section 3.5.1.
 Receiver Port:  SHOULD be set to 0.
 PType:  Set according to the following rules:
       Settings by the AN:
          0 - the AN does not support partitions;
          2 - the value of Partition ID contained in this message is
          assigned to the current partition.
       Settings by the NAS:
          0 - the NAS leaves the decision on partitioning to the AN
          (RECOMMENDED setting);
          1 - the NAS requests that the AN use the value of Partition
          ID contained in this message for the current partition.  The
          NAS MAY use this setting even if it has already received a
          SYN message from the AN, provided that the AN has indicated
          support for partitions.  The NAS MUST be prepared to use
          whatever value it receives in a subsequent SYN or SYNACK
          message, even if this differs from the requested value.
 P Flag:  Set to the mode of adjacency setup (new adjacency vs.
    recovered adjacency) requested by the sender.  Warning: setting P
    Flag=1 runs the risk of state mismatch because ANCP does not
    provide the means for the NAS to audit the current state of the
    AN.

Wadhwa, et al. Standards Track [Page 23] RFC 6320 ANCP Protocol October 2011

 Sender Instance:  Set as described in Section 3.5.1.
 Partition ID:  MUST be set to 0 if PType=0; otherwise, set to the
    assigned or requested partition identifier value.
 Receiver Instance:  SHOULD be set to 0.
 # of Caps:  MUST be set to the number of Capability fields that
    follow.
 Total Length:  MUST be set to the total number of bytes in the
    Capability fields that follow.
 Capability Fields:  One Capability field MUST be present for each
    ANCP capability for which the sender wishes to advertise support.

3.5.2.3.2. Action by the Receiver

 Upon receiving a validly formed SYN message, the receiver first
 checks the value of the Version field.  If this value is not within
 the range of ANCP versions that the receiver supports, the message
 MUST be silently ignored.  Similarly, the message is silently ignored
 if the M flag is 0 and the receiver is an AN or if the M flag is 1
 and the receiver is a NAS.  If these checks are passed and the
 receiver is in ESTAB state, it returns an ACK (as indicated by the
 ESTAB state table in Section 3.5.2.2.1).  The contents of the ACK
 MUST reflect the adjacency state as previously recorded by the
 receiver.
 Otherwise, the receiver MUST perform the "Record Adjacency State"
 operation by recording the following fields:
 Version:  The supported Version value received in the SYN message.
    This value MUST be used for all subsequent ANCP messages sent
    during the life of the adjacency.
 Timer:  The larger of the Timer value received in the SYN message and
    the value with which the receiver is configured.
 Sender Name:  The value of the Sender Name field in the SYN message
    just received.
 Receiver Name:  The value used by the receiver in the Sender Name
    field of SYN, SYNACK, and ACK messages it sends in this adjacency.

Wadhwa, et al. Standards Track [Page 24] RFC 6320 ANCP Protocol October 2011

 Sender Port:  The value of the Sender Port field in the SYN message
    just received.
 Receiver Port:  The value used by the receiver in the Sender Port
    field of SYN, SYNACK, and ACK messages it sends in this adjacency.
 Sender Instance:  The value of the Sender Instance field in the SYN
    message just received.
 P Flag:  The lesser of the value determined by local policy and the
    value received in the SYN message.  That is, preference is given
    to "0 - New adjacency" if there is a conflict.
 Partition ID:  If the SYN receiver is the AN, this is set to 0 if the
    AN does not support partitions or to the non-zero value of the
    partition identifier it chooses to assign otherwise.  If the SYN
    receiver is the NAS, this is set to the value of the Partition ID
    field copied from the SYN.
 Receiver Instance:  The value used by the receiver in the Sender
    Instance field of SYN, SYNACK, and ACK messages it sends in this
    adjacency.
 Capabilities:  The set of ANCP capabilities that were offered in the
    SYN and are supported by the receiver.

3.5.2.4. The Adjacency Protocol SYNACK Message

3.5.2.4.1. Action by the Sender

 The SYNACK is sent in response to a successfully received SYN
 message, as indicated by the state tables.  The Version, Timer, P
 Flag, and Partition ID fields MUST be populated with the values
 recorded as part of adjacency state.  The # of Caps, Total Length,
 and Capability fields MUST also be populated in accordance with the
 Capabilities recorded as part of adjacency state.  The remaining
 fields of the SYNACK message MUST be populated as follows:
 Message Type:  MUST be 10.
 M flag:  MUST be set to 0.
 Code:  MUST be 2 (SYNACK).
 PType:  MUST be 0 if the Partition ID value is 0 or 2 if the
    Partition ID value is non-zero.

Wadhwa, et al. Standards Track [Page 25] RFC 6320 ANCP Protocol October 2011

 Sender Name:  MUST be set to the Receiver Name value recorded as part
    of adjacency state.
 Receiver Name:  MUST be set to the Sender Name value recorded as part
    of adjacency state.
 Sender Port:  MUST be set to the Receiver Port value recorded as part
    of adjacency state.
 Receiver Port:  MUST be set to the Sender Port value recorded as part
    of adjacency state.
 Sender Instance:  MUST be set to the Receiver Instance value recorded
    as part of adjacency state.
 Receiver Instance:  MUST be set to the Sender Instance value recorded
    as part of adjacency state.
 If the set of capabilities recorded in the adjacency state is empty,
 then after sending the SYNACK the sender MUST raise an alarm to
 management, halt the adjacency procedure, and tear down the TCP
 session if it is not being used by another adjacency.  The sender MAY
 also terminate the IPsec security association if no other adjacency
 is using it.

3.5.2.4.2. Action by the Receiver

 As indicated by the state tables, the receiver of a SYNACK first
 checks that the Receiver Name, Receiver Port, and Receiver Instance
 values match the Sender Name, Sender Port, and Sender Instance values
 it sent in SYN message that is being acknowledged.  The AN also
 checks that the PType and Partition ID match.  If any of these checks
 fail, the receiver sends an RSTACK as described in Section 3.5.2.6.1.
 The receiver next checks whether the set of capabilities provided in
 the SYNACK is empty.  If so, the receiver MUST raise an alarm to
 management and halt the adjacency procedure.
 Assuming that the SYNACK passes these checks, two cases arise.  The
 first possibility is that the receiver has already recorded adjacency
 state.  This will occur if the SYNACK is received while the receiver
 is in SYNRCVD state.  In this case, the Version, Timer, Sender Name,
 Sender Port, Sender Instance, P Flag, and capability-related fields
 in the SYNACK MUST match those recorded as part of adjacency state.
 If a mismatch is detected, the receiver sends an RSTACK.  This is the
 "Verify Adjacency State" procedure shown in the SYNRCVD state table.

Wadhwa, et al. Standards Track [Page 26] RFC 6320 ANCP Protocol October 2011

 If, on the other hand, the SYNACK is received while the receiver is
 in SYNSENT state, the receiver MUST record session state as described
 in Section 3.5.2.3.2.
 In either case, if the receiver is the NAS, it MUST accept the
 Partition ID value provided in the SYNACK, updating its recorded
 adjacency state if necessary.

3.5.2.5. The Adjacency Protocol ACK Message

3.5.2.5.1. Actions by the Sender

 As indicated by the state tables, the ACK message is sent in a number
 of different circumstances.  The main-line usages are as a response
 to SYNACK, leading directly to the ESTAB state, and as a periodic
 test of liveness once the ESTAB state has been reached.
 The sender MUST populate the ACK from recorded adjacency state,
 exactly as described in Section 3.5.2.4.1.  The only difference is
 that Code MUST be set to 3 (ACK).

3.5.2.5.2. Actions by the Receiver

 The required actions by the receiver are specified by the state
 tables.  In addition to the checks B and C, the receiver SHOULD
 verify that the remaining contents of the ACK match the recorded
 adjacency state at the receiver.  If that check fails, the receiver
 MUST send an RSTACK as described in Section 3.5.2.6.1.
 Once the adjacency has been established, either peer can initiate the
 ACK exchange that tests for liveness.  To meet the restrictions on
 ACK frequency laid down in the notes to the state tables, it is
 desirable that only one such exchange occur during any one interval.
 Hence, if a peer receives an ACK when in ESTAB state, it MUST reply
 to that ACK as directed by the state tables, but SHOULD NOT initiate
 another ACK exchange in the same interval.  To meet this objective,
 the receiver MUST reset its timer when it receives an ACK while in
 ESTAB state.
    It is, of course, possible that two exchanges happen because of
    race conditions.

Wadhwa, et al. Standards Track [Page 27] RFC 6320 ANCP Protocol October 2011

3.5.2.6. The Adjacency Protocol RSTACK Message

3.5.2.6.1. Action by the Sender

 The RSTACK is sent in response to various error conditions as
 indicated by the state tables.  In general, it leads to a restart of
 adjacency negotiations (although this takes a few steps when the
 original sender of the RSTACK is in ESTAB state).
 As indicated in Section 3.5.1, the Sender Name, Port, and Instance
 fields in the RSTACK MUST be copied from the Receiver, Name, Port,
 and Instance fields in the message that caused the RSTACK to be sent.
 Similarly, the Receiver identifier fields in the RSTACK MUST be
 copied from the corresponding Sender identifier fields in the message
 that triggered the RSTACK.
 If the sender has recorded adjacency state, the Version, Timer,
 PType, P Flag, Partition ID, and capability-related fields SHOULD be
 set based on the recorded adjacency state.  Otherwise, they SHOULD be
 the same as the sender would send in a SYN message.  The Message Type
 MUST be 10, the M flag MUST be 0, and Code MUST be 4 (RSTACK).

3.5.2.6.2. Action by the Receiver

 The receiver of an RSTACK MAY attempt to diagnose the problem that
 caused the RSTACK to be generated by comparing its own adjacency
 state with the contents of the RSTACK.  However, the primary purpose
 of the RSTACK is to trigger action as prescribed by Section 3.5.2.2.

3.5.2.7. Loss of Synchronization

 Loss of synchronization MAY be declared if after synchronization is
 achieved:
 o  no valid ANCP messages are received in any period of time in
    excess of three times the value of the Timer field negotiated in
    the adjacency protocol messages, or
 o  a mismatch in adjacency state is detected.
 In either case, the peer detecting the condition MUST send an RSTACK
 to the other peer, as directed in Section 3.5.2.6.1, in order to
 initiate resynchronization.
 While re-establishing synchronization with a controller, a switch
 SHOULD maintain its connection state, deferring the decision about
 resetting the state until after synchronization is re-established.

Wadhwa, et al. Standards Track [Page 28] RFC 6320 ANCP Protocol October 2011

 Once synchronization is re-established, the decision about resetting
 the connection state SHOULD be made based on the negotiated value of
 the P Flag.

3.6. ANCP General Message Formats

 This section describes the general format of ANCP messages other than
 the adjacency messages.  See Figure 7.
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Version    | Message Type  | Result|      Result Code      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Partition ID  |            Transaction Identifier             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |I|      SubMessage Number      |           Length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                          Message Payload                      ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 Figure 7: ANCP General Message Format

3.6.1. The ANCP Message Header

 A complete explanation of the ANCP general message header fields
 follows.

3.6.1.1. Version Field (8 bits)

 This field carries the version of ANCP that was agreed upon for the
 session during adjacency negotiation.

3.6.1.2. Message Type Field (8 bits)

 This field indicates the ANCP message type.  Message type values are
 registered in an IANA registry.

3.6.1.3. Result Field (4 bits)

 In request messages, the Result field indicates the circumstances
 under which a response is required.  ANCP specifies what Result value
 each request message type should have.  In responses, the Result
 field indicates either Success (0x3) or Failure (0x4), as the case
 may be.

Wadhwa, et al. Standards Track [Page 29] RFC 6320 ANCP Protocol October 2011

 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 Result Code
    field for a successful result is typically 0, but it 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
    Result Code value and any diagnostic data contained in a Status-
    Info TLV included in the response.

3.6.1.4. Result Code Field (12 bits)

 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 it can also be used to give further information
 in a success response message or an event message.  In a request
 message, the Result Code field is not used and MUST be set to 0x0 (No
 result).
 A number of Result Code values are specified below.  Specification of
 additional Result Code values in extensions or updates to this
 document MUST include the following information:
 o  Result Code value;
 o  One-line description;
 o  Where condition detected (control application or ANCP agent);
 o  Further description (if any);
 o  Required additional information in the response message;
 o  Target (control application or ANCP agent at the peer that sent
    the original request);

Wadhwa, et al. Standards Track [Page 30] RFC 6320 ANCP Protocol October 2011

 o  Action RECOMMENDED for the receiving ANCP agent.
 In addition to any suggested action in the text that follows, a count
 of the number of times a given non-zero Result Code value was
 received SHOULD be provided for management.  Where an action includes
 the re-sending of a request, a given request SHOULD NOT be re-sent
 more than once.
 This document specifies the following Result Code values.
 Result Code value: 0x2
  • One-line description: Invalid request message
  • Where condition detected: ANCP agent
  • Further description: The request was a properly formed message

that 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, 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.
 Result Code value: 0x6
  • One-line description: One or more of the specified ports are

down

  • Where condition detected: Control application
  • Further description (if any): This Result Code value indicates

a state mismatch between the NAS and AN control applications,

       possibly due to a race condition.

Wadhwa, et al. Standards Track [Page 31] RFC 6320 ANCP Protocol October 2011

  • 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.
 Result Code value: 0x13
  • One-line description: Out of resources
  • Where condition detected: ANCP protocol layer or control

application

  • Further description (e.g., memory exhausted): This Result Code

value MUST be reported only by the AN, and indicates a

       condition that is probably unrelated to specific access lines
       (although it may be related to the specific request).
  • Required additional information in the response message: None,

if the response message is of the same type as the request. As

       specified in Section 4.2, if the response message is a Generic
       Response message.
  • Target: ANCP agent at the peer that sent the original request
  • Action RECOMMENDED for the receiving ANCP agent: If the NAS

receives this Result 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 Result Code = 19.  It MAY retry individual
       requests.  If only a specific request is failing with Result
       Code = 19, the ANCP agent in the NAS MAY request the control
       application to decompose the request into simpler components if
       this is possible.
 Result Code value: 0x51
  • One-line description: Request message type not implemented
  • Where condition detected: ANCP agent

Wadhwa, et al. Standards Track [Page 32] RFC 6320 ANCP Protocol October 2011

  • Further description: This could indicate a mismatch in protocol

version or capability state. It is also possible that support

       of a specific message is optional within some ANCP capability.
  • Required additional information in the response message: None,

if the response message is of the same type as the request. As

       specified in Section 4.2, if the response message is a Generic
       Response message.
  • Target: ANCP agent at the peer that sent the original request
  • Action RECOMMENDED for the receiving ANCP agent: If the

receiver of this Result Code value expects that support of the

       message type concerned is mandatory according to the
       capabilities negotiated for the session, it MAY re-send the
       message in case the message was corrupted in transit the first
       time.  If that fails, and use of the message type cannot be
       avoided, the ANCP agent MAY reset the adjacency by sending an
       RSTACK adjacency message as described in Section 3.5.2.6.1,
       where Sender and Receiver Name, Port, and Instance are taken
       from recorded adjacency state.  If a reset does not eliminate
       the problem, the receiving ANCP agent SHOULD raise an alarm to
       management and then cease to operate.
 Result Code value: 0x53
  • One-line description: Malformed message
  • Where condition detected: ANCP agent
  • Further description: This could be the result of corruption in

transit, or an error in implementation at one end or the other.

  • Required additional information in the response message: None,

if the response message is of the same type as the request. As

       specified in Section 4.2, if the response message is a Generic
       Response message.
  • Target: ANCP agent at the peer that sent the original request
  • Action RECOMMENDED for the receiving ANCP agent: The request

SHOULD be re-sent once to eliminate the possibility of in-

       transit corruption.
 Result Code value: 0x54
  • One-line description: Mandatory TLV missing

Wadhwa, et al. Standards Track [Page 33] RFC 6320 ANCP Protocol October 2011

  • 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 4-byte TLV header is present).
  • Target: ANCP agent at the peer that sent the original request
  • Action RECOMMENDED for the receiving ANCP agent: Re-send 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).
 Result Code value: 0x55
  • 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 re-send 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).
 Result Code value: 0x500
  • One-line description: One or more of the specified ports do not

exist

  • Where condition detected: Control application

Wadhwa, et al. Standards Track [Page 34] RFC 6320 ANCP Protocol October 2011

  • Further description (if any): This may indicate a configuration

mismatch between the AN and the NAS or Authentication,

       Authorization, and Accounting (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.

3.6.1.5. Partition ID (8 bits)

 The Partition ID field MUST contain the value that was negotiated for
 Partition ID during the adjacency procedure as described above.

3.6.1.6. Transaction ID (24 bits)

 The Transaction ID is 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 by
 1 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 behavior 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 (1 + 15 bits)

 In GSMPv3, these provide a mechanism for message fragmentation.
 Because ANCP uses TCP transport, this mechanism is unnecessary.  An
 ANCP agent MUST set the I Flag and subMessage Number fields to 1 to
 signify "no fragmentation".

Wadhwa, et al. Standards Track [Page 35] RFC 6320 ANCP Protocol October 2011

3.6.1.8. Length (16 bits)

 This field MUST be set to the length of the ANCP message in bytes,
 including its header fields and message body but excluding the 4-byte
 encapsulating header defined in Section 3.2.

3.6.2. The ANCP Message Body

 The detailed contents of the message payload portion of a given ANCP
 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 8:
  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                              ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Figure 8: General TLV Format
 The fields of a TLV are defined as follows:
 Type (16 bits):  The TLV Type is an unsigned value identifying the
    TLV type and nature of its contents.  An IANA registry has been
    established for ANCP TLV Type codes.
 Length (16 bits):  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 (variable):  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.

Wadhwa, et al. Standards Track [Page 36] RFC 6320 ANCP Protocol October 2011

 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

 ANCP 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 Result 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, the second by specifications in Section 6.4.  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 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 behavior
 described in Section 3.6.1.
 The specification for a response message SHOULD indicate in all cases
 that the 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).

Wadhwa, et al. Standards Track [Page 37] RFC 6320 ANCP Protocol October 2011

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 9.  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                              ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             Figure 9: Format of the Provisioning Message
 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.  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 coexist and have all
 been negotiated during adjacency establishment.
 Message Type:  MUST be set to 93.
 Result:  MUST be set to 0x0 (Ignore).
 Result Code:  MUST be set to zero.

Wadhwa, et al. Standards Track [Page 38] RFC 6320 ANCP Protocol October 2011

 Transaction ID:  MUST be populated with a non-zero value chosen in
    the manner described in Section 3.6.1.6.
 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) 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 10.

Wadhwa, et al. Standards Track [Page 39] RFC 6320 ANCP Protocol October 2011

  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.
         Figure 10: Structure of the Generic Response Message
 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.
 Message Type:  MUST be set to 91.
 Result:  MUST be set to 0x3 (Success) or 0x4 (Failure).
 Result 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 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 Result Code field.

Wadhwa, et al. Standards Track [Page 40] RFC 6320 ANCP Protocol October 2011

 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 11 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).
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    TLV Type = 0x1000          |Length = Circuit-ID Length + 4 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Access-Loop-Circuit-ID=0x0001 |       Circuit-ID Length       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                    Access Loop Circuit ID                     ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Figure 11: Example of Target TLV for Single Access Line

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.  That is, the specification of

Wadhwa, et al. Standards Track [Page 41] RFC 6320 ANCP Protocol October 2011

    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 1-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 Result 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 (8 bits):  See Section 3.4 for handling of reserved
       fields.
    Msg Type (8 bits):  Message Type of the request for which this TLV
       is providing diagnostics.

Wadhwa, et al. Standards Track [Page 42] RFC 6320 ANCP Protocol October 2011

    Error Message Length (16 bits):  Number of bytes in the error
       message, excluding padding, but including the language tag and
       delimiter.  This MAY be zero if no error message is provided.
    Error Message:  Human-readable string providing information about
       the warning or error condition.  The initial characters of the
       string MUST be a language tag as described in [RFC5646],
       terminated by a colon (":").  The actual text string follows
       the delimiter.  The field is padded at the end with zeroes as
       necessary to extend it to a 4-byte word boundary.
    Section 3.6.1.4 provides recommendations for what TLVs to add in
    the Status-Info TLV for particular values of the message header
    Result Code field.
 Figure 12 illustrates the Status-Info TLV.
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    TLV Type = 0x0106          |              Length           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Reserved   |  Msg Type     |      Error Message Length     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Error Message (padded to 4-byte boundary)              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |           optional sub-TLVs...                                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Figure 12: The Status-Info TLV

5. Introduction to ANCP Capabilities for Digital Subscriber Lines

  (DSLs)
 DSL is a widely deployed access technology for Broadband Access for
 Next Generation Networks.  Specifications such as [TR-059], [TR-058],
 and [TR-092] 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.

Wadhwa, et al. Standards Track [Page 43] RFC 6320 ANCP Protocol October 2011

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] and provided
 for in the TLVs defined in this section:
 o  identification of an access line by its logical appearance on the
    user side of the Access Node;
 o  identification of an access line by its logical appearance on the
    NAS side of the Access Node; and
 o  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 ([RFC2131], [RFC3315]) transactions involving hosts
 served by DSL.  Either the AN or the NAS can serve as a DHCP relay
 node.  [TR-101] requires the AN or NAS in this role to add access
 line identification in Option 82 (Information) ([RFC3046], with its
 IPv6 equivalent in [RFC4649]) 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] 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 access line 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

Wadhwa, et al. Standards Track [Page 44] RFC 6320 ANCP Protocol October 2011

 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] 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 that 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].  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].

Wadhwa, et al. Standards Track [Page 45] RFC 6320 ANCP Protocol October 2011

 ANCP agents conforming to this section MUST satisfy the following
 requirements:
 o  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.
 o  ANCP agents MUST be able to receive all four TLV types, extract
    the relevant information, and pass it to the control application.
 o  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-ASCII TLV or Access-Aggregation-Circuit-ID-
    Binary 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-ASCII TLV or Access-Aggregation-
       Circuit-ID-Binary TLV with two VLAN identifiers may or may not
       identify an access line uniquely, but this is up to the control
       application to decide.
 o  If the Access-Aggregation-Circuit-ID-ASCII TLV or Access-
    Aggregation-Circuit-ID-Binary 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].

Wadhwa, et al. Standards Track [Page 46] RFC 6320 ANCP Protocol October 2011

 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]), the TLV
    contains two value fields.  Each field carries a 12-bit VLAN
    identifier (which is part of the VLAN tag defined by
    [IEEE802.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 Virtual Path Identifier (VPI) and Virtual Circuit
    Identifier (VCI) on the DSLAM uplink correspond uniquely to the
    DSL access 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 identifier 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 13.
 Length:  4 or 8 bytes
 Value:  One or two 32-bit binary fields.

Wadhwa, et al. Standards Track [Page 47] RFC 6320 ANCP Protocol October 2011

    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                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Figure 13: The Access-Aggregation-Circuit-ID-Binary TLV

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] 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] 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:
 o  when a new adjacency with the NAS is established, for each DSL
    loop that is synchronized at that time;

Wadhwa, et al. Standards Track [Page 48] RFC 6320 ANCP Protocol October 2011

 o  subsequent to that, whenever a DSL access line resynchronizes; and
 o  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:
 o  when a new adjacency with the NAS is established, for each DSL
    loop that is provisioned but not synchronized at that time;
 o  whenever a DSL access line that is equipped in an AN but
    administratively disabled is signaled as "IDLE"; and
 o  subsequent to that, whenever a DSL access line 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 access line attributes.
 In the case of bonded copper loops to the customer premise (as per
 DSL multi-pair bonding described by [G.998.1] and [G.998.2]), the 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
 access lines of which it is comprised.  The information relating to
 DSL access 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 access line
 state, performs any required accounting operations, and uses any
 included line attributes to adjust the operation of its queuing/
 scheduling mechanisms as they apply to data passing to and from that
 DSL access line.
 Figure 14 summarizes the interaction.

Wadhwa, et al. Standards Track [Page 49] RFC 6320 ANCP Protocol October 2011

 1.   Home            Access                          NAS
     Gateway           Node
  1. ———→ ————————–>

DSL Port Up (Event message)

               Signal        (default line parameters)
 2.   Home            Access                          NAS
     Gateway           Node
  1. ———→ ————————–>

DSL Port Up (Event message)

              Resynch        (updated line parameters)
 3.   Home            Access                          NAS
     Gateway           Node
  1. ———→ ————————–>

Loss of Port Down (Event message)

           DSL Signal       (selected line parameters)
        Figure 14: ANCP Message Flow for DSL Topology Discovery

6.2. Protocol Requirements

 The DSL topology discovery capability is assigned capability type
 0x0001.  No capability data is associated with this capability.

6.2.1. Protocol Requirements on the AN Side

 The AN-side ANCP agent MUST be able to create DSL-specific Port Up
 and Port Down messages according to the format specified in
 Section 6.3.
 The AN-side ANCP agent MUST conform to the normative requirements of
 Section 5.1.2.
 The AN-side ANCP agent MUST follow the AN-side procedures associated
 with DSL-specific Port Up and Port Down messages as they are
 specified in Section 6.4.

6.2.2. Protocol Requirements on the NAS Side

 The NAS-side ANCP agent MUST be able to receive and validate DSL-
 specific Port Up and Port Down messages according to the format
 specified in Section 6.3.

Wadhwa, et al. Standards Track [Page 50] RFC 6320 ANCP Protocol October 2011

 The NAS-side ANCP agent MUST conform to the normative requirements of
 Section 5.1.2.
 The NAS-side ANCP agent MUST follow the NAS-side procedures
 associated with DSL-specific Port Up and Port Down messages as they
 are specified in Section 6.4.

6.3. ANCP Port Up and Port Down Event Message Descriptions

 The format of the ANCP Port Up and Port Down Event messages is shown
 in Figure 15.
  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)                          +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                    Unused (20 bytes)                          ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |x|x|x|x|x|x|x|x| Message Type  |   Tech Type   |  Reserved     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     # of TLVs                 | Extension Block length (bytes)|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                 Access line identifying TLV(s)                ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                DSL-Line-Attributes TLV                        |
 ~        (MANDATORY in Port Up, OPTIONAL in Port Down)          ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 NOTE: TLVs MAY be in a different order from what is shown in this
 figure.
  Figure 15: Format of the ANCP Port Up and Port Down Event Messages
                      for DSL Topology Discovery
 See Section 3.6.1 for a description of the ANCP general message
 header.  The Message Type field MUST be set to 80 for Port Up, 81 for
 Port Down.  The 4-bit Result field MUST be set to zero (signifying
 Ignore).  The 12-bit Result Code field and the 24-bit Transaction

Wadhwa, et al. Standards Track [Page 51] RFC 6320 ANCP Protocol October 2011

 Identifier field MUST also be set to zeroes.  Other fields in the
 general header MUST be set a as described in Section 3.6.
 The five-word Unused field is a historical leftover.  The handling of
 unused/reserved fields is described in Section 3.4.
 The remaining message fields belong to the "extension block", and are
 described as follows:
 Extension Flags (8 bits):  The flag bits denoted by 'x' are currently
    unspecified and reserved.
 Message Type (8 bits):  Message Type has the same value as in the
    general header (i.e., 80 or 81).
 Tech Type (8 bits):  MUST be set to 0x05 (DSL).
 Reserved (8 bits):  set as described in Section 3.4.
 # of TLVs (16 bits):  The number of TLVs that follow, not counting
    TLVs encapsulated within other TLVs.
 Extension Block Length (16 bits):  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 access 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 creates and transmits 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.  It
 is RECOMMENDED that the Access Node use a dampening mechanism per DSL
 access line to control the rate at which state changes are
 communicated to the NAS.
 At the top level, the extension block within a DSL-specific Port Up
 or Port Down message MUST include TLVs from Section 5.1.2 to identify
 the DSL access line.
 TLVs presenting DSL access line attributes (i.e., the TLVs specified
 in Section 6.5) MUST be encapsulated within the DSL-Line-Attributes
 TLV.  When the DSL-Line-Attributes TLV is present in a message, it
 MUST contain at least one such TLV and will generally contain more

Wadhwa, et al. Standards Track [Page 52] RFC 6320 ANCP Protocol October 2011

 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.

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 access line 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 access line without an intervening Port Down message, and vice
 versa.
 The NAS-side ANCP agent SHOULD validate each message against the
 specifications given in Section 6.3 and the TLV specifications given
 in Sections 5.1.2 and 6.5.  If it finds an error, it MAY generate a
 Generic Response message containing an appropriate Result Code value.
 If it does so, the message MUST contain copies of all of the
 identifier TLVs from Section 5.1.2 that were present in the Port Up
 or Port Down message.  The message MUST also contain a Status-Info
 TLV that in turn contains other information appropriate to the
 message header Result Code value as described in Section 3.6.1.4.

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 access
    line serving a subscriber.
 Length:  Variable (up to 1023 bytes)
 Value:  One or more encapsulated TLVs corresponding to DSL access
    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.

Wadhwa, et al. Standards Track [Page 53] RFC 6320 ANCP Protocol October 2011

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 access 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 access line.
 Length:  4 bytes
 Value:  Rate in kbits/s as a 32-bit unsigned integer

Wadhwa, et al. Standards Track [Page 54] RFC 6320 ANCP Protocol October 2011

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 access 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 access line.
 Length:  4 bytes
 Value:  Rate in kbits/s as a 32-bit unsigned integer

Wadhwa, et al. Standards Track [Page 55] RFC 6320 ANCP Protocol October 2011

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

Wadhwa, et al. Standards Track [Page 56] RFC 6320 ANCP Protocol October 2011

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

Wadhwa, et al. Standards Track [Page 57] RFC 6320 ANCP Protocol October 2011

6.5.17. DSL-Line-State TLV

 Type:  0x008F
 Description:  The state of the DSL access 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 3 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

Wadhwa, et al. Standards Track [Page 58] RFC 6320 ANCP Protocol October 2011

       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 16.
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    TLV Type = 0x0090          |        Length = 3             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Data link     |    Encaps 1   |    Encaps 2   | Padding (=0)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             Figure 16: The Access-Loop-Encapsulation TLV

7. ANCP-Based DSL Line Configuration

 The use case for ANCP-based DSL Line Configuration is described in
 Section 3.2 of [RFC5851].

7.1. Control Context (Informative)

 Triggered by topology information reporting a new DSL access line or
 triggered by a subsequent user session establishment (via 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 17 summarizes the interaction.

Wadhwa, et al. Standards Track [Page 59] RFC 6320 ANCP Protocol October 2011

   Home            Access               NAS             RADIUS/AAA
  Gateway           Node                             Policy Server
  1. ———→ —————>

DSL Port Up message)

           Signal       (line parameters)
  1. ——————————→ ————–>

PPP/DHCP Session Authentication &

                                            authorization
                        <----------------
                          Port Management message
                          (line configuration)
 Figure 17: Message Flow - ANCP Mapping for Initial Line Configuration
 The NAS could update the line configuration as a result of a
 subscriber service change (e.g., triggered by the policy server).
 Figure 18 summarizes the interaction.
 User     Home            Access         NAS
         Gateway           Node
  1. ————————→

PPP/DHCP Session

  1. —————————————————> Web portal,

Service on demand OSS, etc.

                                                               |
                                           <-----------  RADIUS/AAA
                                           Change of     Policy Server
                                         authorization
                           <------------
                            Port Management
                                message
                            (new profile)
 OSS: Operations Support System
 Figure 18: Message Flow - ANCP Mapping for Updated Line Configuration

Wadhwa, et al. Standards Track [Page 60] RFC 6320 ANCP Protocol October 2011

7.2. Protocol Requirements

 The DSL access 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.
 The NAS-side ANCP agent MUST conform to the normative requirements of
 Section 5.1.2.
 The NAS-side ANCP agent MUST follow the NAS-side procedures
 associated with DSL-specific Port Management (line configuration)
 messages as they are specified in Section 7.4.

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.
 The AN-side ANCP agent MUST be able to receive and validate DSL-
 specific Port Management (line configuration) messages according to
 the format specified in Section 7.3.
 The AN-side ANCP agent MUST follow the AN-side procedures associated
 with DSL-specific Port Management (line configuration) messages as
 specified in Section 7.4.

Wadhwa, et al. Standards Track [Page 61] RFC 6320 ANCP Protocol October 2011

7.3. ANCP Port Management (Line Configuration) Message Format

 The ANCP Port Management message for DSL access line configuration
 has the format shown in Figure 19.
  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)                          +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                       Unused (12 bytes)                       ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Unused (2 bytes)       |  Function=8   | X-Function=0  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       Unused (4 bytes)                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |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.
     Figure 19: Port Management Message for DSL Line Configuration
 See Section 3.6 for a description of the ANCP general message header.
 The Message Type field MUST be set to 32.  The 12-bit Result Code
 field MUST be set to 0x0.  The 4-bit Result field MUST be set to
 either 0x1 (Nack) or 0x2 (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.

Wadhwa, et al. Standards Track [Page 62] RFC 6320 ANCP Protocol October 2011

 The handling of the various unused/reserved fields is described in
 Section 3.4.
 The remaining message fields are described as follows:
 Function (8 bits):  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 access line designated by the access line
    identifying TLVs.
 X-Function (8 bits):  Qualifies the action set by Function.  For DSL
    access line configuration, this field MUST be set to 0.
 Extension Flags (8 bits):  The flag bits denoted by 'x' before the
    Message Type field are reserved for future use.
 Message Type (8 bits):  Message Type has the same value as in the
    general header (i.e., 32).
 Reserved (16 bits):  Reserved for future use.
 # of TLVs (16 bits):  The number of TLVs that follow, not counting
    TLVs encapsulated within other TLVs.
 Extension Block Length (16 bits):  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 access 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 access line configuration MAY be used to carry
 TLVs relating to the other capabilities that apply to the same DSL
 access line.
 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.

Wadhwa, et al. Standards Track [Page 63] RFC 6320 ANCP Protocol October 2011

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.  The NAS MUST include one or more TLVs to configure
 line service parameters for that line.  Section 7.5 currently
 identifies only one such TLV, Service-Profile-Name, but other TLVs
 MAY be added by extensions to ANCP.

7.4.2. Procedures on the AN Side

 The AN-side ANCP agent MUST be prepared to receive Port Management
 (line configuration) messages for a given DSL access line or logical
 port at any time after negotiation of an adjacency has been
 completed.
 The AN-side ANCP agent SHOULD validate each message against the
 specifications given in Section 7.3 and the TLV specifications given
 in Sections 5.1.2 and 7.5.  If it finds an error it MUST return a
 Port Management response message that copies the Port Management
 request as it was received, but has the Result header field set to
 0x04 (Failure) and the Result Code field set to the appropriate
 value.  The AN-side agent MAY add a Status-Info TLV (Section 4.5) to
 provide further information on the error, particularly if this is
 recommended in Section 3.6.1.4 for the given Result Code value.  If
 it does so, the various length fields and the # of TLVs field within
 the message MUST be adjusted accordingly.

7.5. TLVs for DSL Line Configuration

 Currently, only the following TLV is specified for DSL access 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 access line (e.g., rates, interleaving delay, multicast
 channel entitlement access-list).

Wadhwa, et al. Standards Track [Page 64] RFC 6320 ANCP Protocol October 2011

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

8.1. Control Context (Informative)

 The NAS control application initiates a request for remote
 connectivity testing for a given access line.  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 (Operations,
 Administration, and Maintenance, 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 20 summarizes the interaction.

Wadhwa, et al. Standards Track [Page 65] RFC 6320 ANCP Protocol October 2011

 +-------------+    +-----+      +-------+          +----------------+
 |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)
 CPE: Customer Premises Equipment
 EFM: Ethernet First Mile
              Figure 20: Message Flow for ANCP-Based OAM

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.
 The NAS-side ANCP agent MUST conform to the normative requirements of
 Section 5.1.2.
 The NAS-side ANCP agent MUST follow the NAS-side procedures
 associated with DSL-specific Port Management (OAM) messages as they
 are specified in Section 8.4.

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

Wadhwa, et al. Standards Track [Page 66] RFC 6320 ANCP Protocol October 2011

 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.

8.3. Port Management (OAM) Message Format

 The Port Management message for DSL access line testing has the same
 format as for DSL access line configuration (see Section 7.3), with
 the following differences:
 o  The Result field in the request SHOULD be set to AckAll (0x2), to
    allow the NAS to receive the information contained in a successful
    test response.
 o  The Function field MUST be set to 9 (Remote Loopback).  (The
    X-Function field continues to be 0.)
 o  The appended TLVs in the extension value field include testing-
    related TLVs rather than subscriber service information.
 The Port Management (OAM) message is illustrated in Figure 21.

Wadhwa, et al. Standards Track [Page 67] RFC 6320 ANCP Protocol October 2011

  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)                          +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                       Unused (12 bytes)                       ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Unused (2 bytes)       |  Function=9   | X-Function=0  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       Unused (4 bytes)                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |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.
                Figure 21: Port Management Message for
                 DSL Line Remote Connectivity Testing

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 creates and sends
 a Port Management (OAM) request with the fixed fields set as
 described in the previous section.  The message MUST contain one or

Wadhwa, et al. Standards Track [Page 68] RFC 6320 ANCP Protocol October 2011

 more TLVs to identify an access line according the requirements of
 Section 5.1.2.  The NAS MAY include the Opaque-Data TLV and/or the
 OAM-Loopback-Test-Parameters TLV (defined in Section 8.5) to
 configure the loopback test for that line.

8.4.2. AN-Side Procedures

 The AN-side ANCP agent SHOULD validate each message against the
 specifications given in Section 8.3 and the TLV specifications given
 in Sections 5.1.2 and 8.5.  If it finds an error it MUST return a
 Port Management response message that copies the Port Management
 request as it was received, but has the Result header field set to
 0x04 (Failure) and the Result Code field set to the appropriate
 value.  Result Code value 0x509 as described below MAY apply, as well
 as the other Result Code values documented in Section 3.6.1.4.
 Result Code value 0x509 SHOULD be used if the OAM-Loopback-Test-
 Parameters TLV is present with an invalid value of the Count field.
 The AN-side agent MAY add a Status-Info TLV (Section 4.5) to provide
 further information on the error, particularly if this is recommended
 in Section 3.6.1.4 for the given Result 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
 extracts the information from the TLVs contained in the message and
 presents that information to the AN control application.  It MUST NOT
 generate an immediate response to the request, but it 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 creates and sends a
 Port Management (OAM) response to the original request.  The Result
 field MUST be set to Success (0x3) or Failure (0x4), and the Result
 Code field SHOULD be set to one of the following values, as indicated
 by the AN control application.
 0x500:  Specified access line does not exist.  See the documentation
    of Result Code 0x500 in Section 3.6.1.4 for more information.  The
    Result header field MUST be set to Failure (0x4).
 0x501:  Loopback test timed out.  The Result header field MUST be set
    to Failure (0x4).
 0x503:  DSL access line status showtime

Wadhwa, et al. Standards Track [Page 69] RFC 6320 ANCP Protocol October 2011

 0x504:  DSL access line status idle
 0x505:  DSL access line status silent
 0x506:  DSL access line status training
 0x507:  DSL access line integrity error
 0x508:  DSLAM resource not available.  The Result header field MUST
    be set to Failure (0x04).
 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 access 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 to indicate that the DSLAM MUST use a locally
       determined value for the timeout.

Wadhwa, et al. Standards Track [Page 70] RFC 6320 ANCP Protocol October 2011

 The OAM-Loopback-Test-Parameters TLV is illustrated in Figure 22.
    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)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Figure 22: The OAM-Loopback-Test-Parameters TLV

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

 This section documents the following IANA actions:
 o  establishment of the following new ANCP registries:
       ANCP Message Types;
       ANCP Result Codes;

Wadhwa, et al. Standards Track [Page 71] RFC 6320 ANCP Protocol October 2011

       ANCP Port Management Functions;
       ANCP Technology Types;
       ANCP Command Codes;
       ANCP TLV Types;
       ANCP Capabilities.
 o  establishment of a new joint GSMP/ANCP version registry;
 o  addition of ANCP as another user of TCP port 6068 in the port
    number registry available from http://www.iana.org.  The current
    user is GSMP.
 All of these actions are described in detail below except for the
 port registration, for which the final point above provides
 sufficient information.

10. IANA Actions

10.1. ANCP Message Type Registry

 IANA has created a new registry, ANCP Message Types.  Additions to
 that registry are permitted by Standards Action, as defined by
 [RFC5226].  The values for Message Type MAY range from 0 to 255, but
 new Message Types SHOULD be assigned values sequentially from 90
 onwards (noting that 91 and 93 are already assigned).  The initial
 contents of the ANCP Message Types registry are as follows:
           +--------------+--------------------+-----------+
           | Message Type | Message Name       | Reference |
           +--------------+--------------------+-----------+
           | 10           | Adjacency Protocol | RFC 6320  |
           | 32           | Port Management    | RFC 6320  |
           | 80           | Port Up            | RFC 6320  |
           | 81           | Port Down          | RFC 6320  |
           | 85           | Adjacency Update   | RFC 6320  |
           | 91           | Generic Response   | RFC 6320  |
           | 93           | Provisioning       | RFC 6320  |
           +--------------+--------------------+-----------+

Wadhwa, et al. Standards Track [Page 72] RFC 6320 ANCP Protocol October 2011

10.2. ANCP Result Code Registry

 IANA has created a new registry, ANCP Result Codes.  The
 documentation of new Result Codes MUST include the following
 information:
 o  Result Code value (as assigned by IANA);
 o  One-line description;
 o  Where condition detected (control application or ANCP agent);
 o  Further description (if any);
 o  Required additional information in the response message;
 o  Target (control application or ANCP agent at the peer that sent
    the original request);
 o  Action RECOMMENDED for the receiving ANCP agent.
 The values for Result Code are expressed in hexadecimal and MAY range
 from 0x0 to 0xFFFFFF.  The range 0x0 to 0xFFF is allocated by the
 criterion of IETF Review, as defined by [RFC5226].  IANA SHOULD
 allocate new Result Code values from this range sequentially
 beginning at 0x100.  The range 0x1000 onwards is allocated by the
 criterion of Specification Required, as defined by [RFC5226].  IANA
 SHOULD allocate new Result Code values from this range sequentially
 beginning at 0x1000.  The initial contents of the ANCP Message Types
 registry are as follows:

Wadhwa, et al. Standards Track [Page 73] RFC 6320 ANCP Protocol October 2011

 +------------+------------------------------------------+-----------+
 | Result     | One-line description                     | Reference |
 | Code       |                                          |           |
 +------------+------------------------------------------+-----------+
 | 0x0        | No result                                | RFC 6320  |
 | 0x2        | Invalid request message                  | RFC 6320  |
 | 0x6        | One or more of the specified ports are   | RFC 6320  |
 |            | down                                     |           |
 | 0x13       | Out of resources                         | RFC 6320  |
 | 0x51       | Request message type not implemented     | RFC 6320  |
 | 0x53       | Malformed message                        | RFC 6320  |
 | 0x54       | Mandatory TLV missing                    | RFC 6320  |
 | 0x55       | Invalid TLV contents                     | RFC 6320  |
 | 0x500      | One or more of the specified ports do    | RFC 6320  |
 |            | not exist                                |           |
 | 0x501      | Loopback test timed out                  | RFC 6320  |
 | 0x502      | Reserved                                 | RFC 6320  |
 | 0x503      | DSL access line status showtime          | RFC 6320  |
 | 0x504      | DSL access line status idle              | RFC 6320  |
 | 0x505      | DSL access line status silent            | RFC 6320  |
 | 0x506      | DSL access line status training          | RFC 6320  |
 | 0x507      | DSL access line integrity error          | RFC 6320  |
 | 0x508      | DSLAM resource not available             | RFC 6320  |
 | 0x509      | Invalid test parameter                   | RFC 6320  |
 +------------+------------------------------------------+-----------+

10.3. ANCP Port Management Function Registry

 IANA has created a new ANCP Port Management Function registry, with
 the following initial entries.  Additions to this registry will be by
 Standards Action, as defined by [RFC5226].  Values may range from 0
 to 255.  IANA SHOULD assign values sequentially beginning with 1,
 taking account of the values already assigned below.
    NOTE: Future extensions of ANCP may need to establish sub-
    registries of permitted X-Function values for specific values of
    Function.
  +----------------+-----------------------------------+-----------+
  | Function Value | Function Name                     | Reference |
  +----------------+-----------------------------------+-----------+
  | 0              | Reserved                          | RFC 6320  |
  | 8              | Configure Connection Service Data | RFC 6320  |
  | 9              | Remote Loopback                   | RFC 6320  |
  +----------------+-----------------------------------+-----------+

Wadhwa, et al. Standards Track [Page 74] RFC 6320 ANCP Protocol October 2011

10.4. ANCP Technology Type Registry

 IANA has created a new ANCP Technology Type registry, with additions
 by Expert Review, as defined by [RFC5226].  The Technology Type MUST
 designate a distinct access transport technology.  Values may range
 from 0 to 255.  IANA SHOULD assign new values sequentially beginning
 at 2, taking into account of the values already assigned below.  The
 initial entries are as follows:
    +-----------------+-------------------------------+-----------+
    | Tech Type Value | Tech Type Name                | Reference |
    +-----------------+-------------------------------+-----------+
    | 0               | Not technology dependent      | RFC 6320  |
    | 1               | Passive Optical Network (PON) | RFC 6320  |
    | 5               | Digital Subscriber Line (DSL) | RFC 6320  |
    | 255             | Reserved                      | RFC 6320  |
    +-----------------+-------------------------------+-----------+

10.5. ANCP Command Code Registry

 IANA has created a new ANCP Command Code registry, with additions by
 Standards Action, as defined by [RFC5226].  Values may range from 0
 to 255.  IANA SHOULD assign new values sequentially beginning with 1.
 The initial entry is as follows:
   +--------------------+-----------------------------+-----------+
   | Command Code Value | Command Code Directive Name | Reference |
   +--------------------+-----------------------------+-----------+
   | 0                  | Reserved                    | RFC 6320  |
   +--------------------+-----------------------------+-----------+

10.6. ANCP TLV Type Registry

 IANA has created a new ANCP TLV Type registry.  Values are expressed
 in hexadecimal and may range from 0x0000 to 0xFFFF.  Additions in the
 range 0x0000 to 0x1FFF are by IETF Review, as defined by [RFC5226].
 IANA SHOULD assign new values in this range sequentially beginning at
 0x100, taking account of the assignments already made below.
 Additions in the range 0x2000 to 0xFFFF are by Specification
 Required, again as defined by [RFC5226].  IANA SHOULD assign new
 values in this range sequentially beginning at 0x2000.  In both
 cases, the documentation of the TLV MUST provide:
 o  a TLV name following the convention used for the initial entries
    (capitalized words separated by hyphens);
 o  a brief description of the intended use;

Wadhwa, et al. Standards Track [Page 75] RFC 6320 ANCP Protocol October 2011

 o  a precise description of the contents of each fixed field,
    including its length, type, and units (if applicable);
 o  identification of any mandatory encapsulated TLVs;
 o  an indication of whether optional TLVs may be encapsulated, with
    whatever information is available on their identity (could range
    from a general class of information to specific TLV names,
    depending on the nature of the TLV being defined).
 The initial entries are as follows:
 +----------+--------------------------------------------+-----------+
 | Type Code| TLV Name                                   | Reference |
 +----------+--------------------------------------------+-----------+
 | 0x0000   | Reserved                                   | RFC 6320  |
 | 0x0001   | Access-Loop-Circuit-ID                     | RFC 6320  |
 | 0x0002   | Access-Loop-Remote-ID                      | RFC 6320  |
 | 0x0003   | Access-Aggregation-Circuit-ID-ASCII        | RFC 6320  |
 | 0x0004   | DSL-Line-Attributes                        | RFC 6320  |
 | 0x0005   | Service-Profile-Name                       | RFC 6320  |
 | 0x0006   | Access-Aggregation-Circuit-ID-Binary       | RFC 6320  |
 | 0x0007   | OAM-Loopback-Test-Parameters               | RFC 6320  |
 | 0x0008   | Opaque-Data                                | RFC 6320  |
 | 0x0009   | OAM-Loopback-Test-Response-String          | RFC 6320  |
 | 0x0011   | Command                                    | RFC 6320  |
 | 0x0081   | Actual-Net-Data-Rate-Upstream              | RFC 6320  |
 | 0x0082   | Actual-Net-Data-Rate-Downstream            | RFC 6320  |
 | 0x0083   | Minimum-Net-Data-Rate-Upstream             | RFC 6320  |
 | 0x0084   | Minimum-Net-Data-Rate-Downstream           | RFC 6320  |
 | 0x0085   | Attainable-Net-Data-Rate-Upstream          | RFC 6320  |
 | 0x0086   | Attainable-Net-Data-Rate-Downstream        | RFC 6320  |
 | 0x0087   | Maximum-Net-Data-Rate-Upstream             | RFC 6320  |
 | 0x0088   | Maximum-Net-Data-Rate-Downstream           | RFC 6320  |
 | 0x0089   | Minimum-Net-Low-Power-Data-Rate-Upstream   | RFC 6320  |
 | 0x008A   | Minimum-Net-Low-Power-Data-Rate-Downstream | RFC 6320  |
 | 0x008B   | Maximum-Interleaving-Delay-Upstream        | RFC 6320  |
 | 0x008C   | Actual-Interleaving-Delay-Upstream         | RFC 6320  |
 | 0x008D   | Maximum-Interleaving-Delay-Downstream      | RFC 6320  |
 | 0x008E   | Actual-Interleaving-Delay-Downstream       | RFC 6320  |
 | 0x008F   | DSL-Line-State                             | RFC 6320  |
 | 0x0090   | Access-Loop-Encapsulation                  | RFC 6320  |
 | 0x0091   | DSL-Type                                   | RFC 6320  |
 | 0x0106   | Status-Info                                | RFC 6320  |
 | 0x1000   | Target (single access line variant)        | RFC 6320  |
 | 0x1001 - | Reserved for Target variants               | RFC 6320  |
 | 0x1020   |                                            |           |
 +----------+--------------------------------------------+-----------+

Wadhwa, et al. Standards Track [Page 76] RFC 6320 ANCP Protocol October 2011

10.7. ANCP Capability Type Registry

 IANA has created a new ANCP Capability Type registry, with additions
 by Standards Action as defined by [RFC5226].  Values may range from 0
 to 255.  IANA SHOULD assign values sequentially beginning at 5.  The
 specification for a given capability MUST indicate the Technology
 Type value with which it is associated.  The specification MUST
 further indicate whether the capability is associated with any
 capability data.  Normally, a capability is expected to be defined in
 the same document that specifies the implementation of that
 capability in protocol terms.  The initial entries in the ANCP
 capability registry are as follows:
 +-------+------------------------+--------+-------------+-----------+
 | Value | Capability Type Name   | Tech   | Capability  | Reference |
 |       |                        | Type   | Data?       |           |
 +-------+------------------------+--------+-------------+-----------+
 | 0     | Reserved               |        |             | RFC 6320  |
 | 1     | DSL Topology Discovery | 5      | No          | RFC 6320  |
 | 2     | DSL Line Configuration | 5      | No          | RFC 6320  |
 | 3     | Reserved               |        |             | RFC 6320  |
 | 4     | DSL Line Testing       | 5      | No          | RFC 6320  |
 +-------+------------------------+--------+-------------+-----------+

10.8. Joint GSMP / ANCP Version Registry

 IANA has created a new joint GSMP / ANCP Version registry.  Additions
 to this registry are by Standards Action as defined by [RFC5226].
 Values may range from 0 to 255.  Values for the General Switch
 Management Protocol (GSMP) MUST be assigned sequentially beginning
 with 4 for the next version.  Values for the Access Network Control
 Protocol (ANCP) MUST be assigned sequentially beginning with 50 for
 the present version.  The initial entries are as follows:
               +---------+----------------+-----------+
               | Version | Description    | Reference |
               +---------+----------------+-----------+
               | 1       | GSMP Version 1 | RFC 1987  |
               | 2       | GSMP Version 2 | RFC 2297  |
               | 3       | GSMP Version 3 | RFC 3292  |
               | 50      | ANCP Version 1 | RFC 6320  |
               +---------+----------------+-----------+

11. Security Considerations

 Security of ANCP is discussed in [RFC5713].  A number of security
 requirements on ANCP are stated in Section 8 of that document.  Those
 applicable to ANCP itself are copied to the present document:

Wadhwa, et al. Standards Track [Page 77] RFC 6320 ANCP Protocol October 2011

 o  The protocol solution MUST offer authentication of the AN to the
    NAS.
 o  The protocol solution MUST offer authentication of the NAS to the
    AN.
 o  The protocol solution MUST allow authorization to take place at
    the NAS and the AN.
 o  The protocol solution MUST offer replay protection.
 o  The protocol solution MUST provide data-origin authentication.
 o  The protocol solution MUST be robust against denial-of-service
    (DoS) attacks.  In this context, the protocol solution MUST
    consider a specific mechanism for the DoS that the user might
    create by sending many IGMP messages.
 o  The protocol solution SHOULD offer confidentiality protection.
 o  The protocol solution SHOULD ensure that operations in default
    configuration guarantee a low number of AN/NAS protocol
    interactions.
 Most of these requirements relate to secure transport of ANCP.
 Robustness against denial-of-service attacks partly depends on
 transport and partly on protocol design.  Ensuring a low number of
 AN/NAS protocol interactions in default mode is purely a matter of
 protocol design.
 For secure transport, either the combination of IPsec with IKEv2
 (references below) or the use of TLS [RFC5246] will meet the
 requirements listed above.  However, the use of TLS has been
 rejected.  The deciding point is a detail of protocol design that was
 unavailable when [RFC5713] was written.  The ANCP adjacency is a
 major point of vulnerability for denial-of-service attacks.  If the
 adjacency can be shut down, either the AN clears its state pending
 reestablishment of the adjacency, or the possibility of mismatches
 between the AN's and NAS's view of state on the AN is opened up.  Two
 ways to cause an adjacency to be taken down are to modify messages so
 that the ANCP agents conclude that they are no longer synchronized,
 or to attack the underlying TCP session.  TLS will protect message
 contents but not the TCP connection.  One has to use either IPsec or
 the TCP authentication option [RFC5925] for that.  Hence, the
 conclusion that ANCP MUST run over IPsec with IKEv2 for
 authentication and key management.

Wadhwa, et al. Standards Track [Page 78] RFC 6320 ANCP Protocol October 2011

 In greater detail: the ANCP stack MUST include IPsec [RFC4301]
 running in transport mode, since the AN and NAS are the endpoints of
 the path.  The Encapsulating Security Payload (ESP) [RFC4303] MUST be
 used, in order to satisfy the requirement for data confidentiality.
 ESP MUST be configured for the combination of confidentiality,
 integrity, and anti-replay capability.  The traffic flow
 confidentiality service of ESP is unnecessary and, in fact,
 unworkable in the case of ANCP.
 IKEv2 [RFC5996] is also REQUIRED, to meet the requirements for mutual
 authentication and authorization.  Since the NAS and AN MAY be in
 different trust domains, the use of certificates for mutual
 authentication could be the most practical approach.  However, this
 is up to the operator(s) concerned.
 The AN MUST play the role of initiator of the IKEv2 conversation.

12. Contributors

 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.

13. Acknowledgements

 The authors would like to thank everyone who provided comments or
 inputs to this document.  The authors acknowledge the inputs provided
 by Wojciech Dec, Peter Arberg, Josef Froehler, Derek Harkness, Kim
 Hyldgaard, Sandy Ng, Robert Peschi, and Michel Platnic, and the
 further comments provided by Mykyta Yevstifeyev, Brian Carter, Ben
 Campbell, Alexey Melnikov, Adrian Farrel, Robert Sparks, Peter St.
 Andre, Sean Turner, Dan Romascanu, Brian Carter, and Michael Scott.

14. References

14.1. Normative References

 [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC3292]      Doria, A., Hellstrand, F., Sundell, K., and T.
                Worster, "General Switch Management Protocol (GSMP)
                V3", RFC 3292, June 2002.
 [RFC3629]      Yergeau, F., "UTF-8, a transformation format of ISO
                10646", STD 63, RFC 3629, November 2003.

Wadhwa, et al. Standards Track [Page 79] RFC 6320 ANCP Protocol October 2011

 [RFC4301]      Kent, S. and K. Seo, "Security Architecture for the
                Internet Protocol", RFC 4301, December 2005.
 [RFC4303]      Kent, S., "IP Encapsulating Security Payload (ESP)",
                RFC 4303, December 2005.
 [RFC5646]      Phillips, A. and M. Davis, "Tags for Identifying
                Languages", BCP 47, RFC 5646, September 2009.
 [RFC5996]      Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
                "Internet Key Exchange Protocol Version 2 (IKEv2)",
                RFC 5996, September 2010.

14.2. Informative References

 [G.993.2]      "ITU-T Recommendation G.993.2, Very high speed digital
                subscriber line transceivers 2 (VDSL2)", 2006.
 [G.998.1]      "ITU-T Recommendation G.998.1, ATM-based multi-pair
                bonding", 2005.
 [G.998.2]      "ITU-T Recommendation G.998.2, Ethernet-based multi-
                pair bonding,", 2005.
 [IEEE802.1Q]   IEEE, "IEEE 802.1Q-2005, IEEE Standard for Local and
                Metropolitan Area Networks - Virtual Bridged Local
                Area Networks - Revision", 2005.
 [IEEE802.1ad]  IEEE, "IEEE 802.1ad-2005, Amendment to IEEE 802.1Q-
                2005. IEEE Standard for Local and Metropolitan Area
                Networks - Virtual Bridged Local Area Networks -
                Revision - Amendment 4: Provider Bridges", 2005.
 [RFC2131]      Droms, R., "Dynamic Host Configuration Protocol",
                RFC 2131, March 1997.
 [RFC3046]      Patrick, M., "DHCP Relay Agent Information Option",
                RFC 3046, January 2001.
 [RFC3315]      Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,
                C., and M. Carney, "Dynamic Host Configuration
                Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
 [RFC4649]      Volz, B., "Dynamic Host Configuration Protocol for
                IPv6 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649,
                August 2006.

Wadhwa, et al. Standards Track [Page 80] RFC 6320 ANCP Protocol October 2011

 [RFC5226]      Narten, T. and H. Alvestrand, "Guidelines for Writing
                an IANA Considerations Section in RFCs", BCP 26,
                RFC 5226, May 2008.
 [RFC5246]      Dierks, T. and E. Rescorla, "The Transport Layer
                Security (TLS) Protocol Version 1.2", RFC 5246,
                August 2008.
 [RFC5713]      Moustafa, H., Tschofenig, H., and S. De Cnodder,
                "Security Threats and Security Requirements for the
                Access Node Control Protocol (ANCP)", RFC 5713,
                January 2010.
 [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", RFC 5851, May 2010.
 [RFC5925]      Touch, J., Mankin, A., and R. Bonica, "The TCP
                Authentication Option", RFC 5925, June 2010.
 [TR-058]       Broadband Forum, "TR-058, Multi-Service Architecture &
                Framework Requirements", September 2003.
 [TR-059]       Broadband Forum, "TR-059, DSL Evolution - Architecture
                Requirements for the Support of QoS-Enabled IP
                Services", September 2003.
 [TR-092]       Broadband Forum, "TR-092, Broadband Remote access
                server requirements document", 2005.
 [TR-101]       Broadband Forum, "TR-101, Architecture & Transport:
                Migration to Ethernet Based DSL Aggregation", 2005.
 [TR-147]       Broadband Forum, "TR-147, Layer 2 Control Mechanism
                For Broadband Multi-Service Architectures", 2008.
 [US_ASCII]     American National Standards Institute, "Coded
                Character Set - 7-bit American Standard Code for
                Information Interchange", ANSI X.34, 1986.

Wadhwa, et al. Standards Track [Page 81] RFC 6320 ANCP Protocol October 2011

Authors' Addresses

 Sanjay Wadhwa
 Alcatel-Lucent
 701 E Middlefield Rd
 Mountain View, CA  94043-4079
 USA
 EMail: sanjay.wadhwa@alcatel-lucent.com
 Jerome Moisand
 Juniper Networks
 10 Technology Park Drive
 Westford, MA  01886
 USA
 EMail: jmoisand@juniper.net
 Thomas Haag
 Deutsche Telekom
 Heinrich-Hertz-Strasse 3-7
 Darmstadt  64295
 Germany
 EMail: haagt@telekom.de
 Norbert Voigt
 Nokia Siemens Networks
 Siemensallee 1
 Greifswald  17489
 Germany
 EMail: norbert.voigt@nsn.com
 Tom Taylor (editor)
 Huawei Technologies
 1852 Lorraine Ave
 Ottawa
 Canada
 EMail: tom111.taylor@bell.net

Wadhwa, et al. Standards Track [Page 82]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6320.txt · Last modified: 2011/10/06 00:07 (external edit)