Network Working Group                                         S.  Wadhwa
Internet-Draft                                                J. Moisand                                            Alcatel-Lucent
Intended status: Standards Track                        Juniper Networks                              J. Moisand
Expires: February 25, July 8, 2011                                   Juniper Networks
                                                                T.  Haag
                                                        Deutsche Telekom
                                                                N. Voigt
                                                  Nokia Siemens Networks
                                                          T. Taylor, Ed.
                                                     Huawei Technologies
                                                         August 24, 2010
                                                         January 4, 2011

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

Abstract

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

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

Status of this Memo

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

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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."
   This Internet-Draft will expire on February 25, July 8, 2011.

Copyright Notice

   Copyright (c) 2010 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.  Specification Requirements  Introduction . . . . . . . . . . . . . . . . . .  5
   2.  Introduction . . . . . . .  5
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  5
     2.1.  6
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  7
   2.  Broadband Access Aggregation . . . . . . . . . . . . . . . . .  7
     3.1.  8
     2.1.  ATM-based broadband aggregation Broadband Aggregation  . . . . . . . . . . . . .  7
     3.2.  Ethernet-based broadband aggregation  8
     2.2.  Ethernet-Based Broadband Aggregation . . . . . . . . . . .  9
   4. 10
   3.  Access Node Control Protocol -- General Aspects  . . . . . . .  9
     4.1. 10
     3.1.  Protocol Version . . . . . . . . . . . . . . . . . . . . . 11
     4.2. 10
     3.2.  ANCP Transport . . . . . . . . . . . . . . . . . . . . . . 11
     4.3.
     3.3.  Encoding of Text Fields  . . . . . . . . . . . . . . . . . 12
     4.4.
     3.4.  Treatment of Reserved and Unused Fields  . . . . . . . . . 12
     4.5.
     3.5.  Use of the GSMPv3 Adjacency Protocol . . . . . . . . . . . 12
       4.5.1.
       3.5.1.  ANCP Adjacency Message Format  . . . . . . . . . . . . 13
       4.5.2. 12
       3.5.2.  ANCP Adjacency Procedures  . . . . . . . . . . . . . . 15
     4.6.
     3.6.  ANCP General Message Formats . . . . . . . . . . . . . . . 17
       4.6.1.
       3.6.1.  The ANCP Message Header  . . . . . . . . . . . . . . . 17
       4.6.2.
       3.6.2.  The ANCP Message Body  . . . . . . . . . . . . . . . . 20
   5. 25
     3.7.  General Principles for the Design of ANCP Capabilities For Digital Subscriber Lines (DSL) Messages . . . . 26
   4.  Generally Useful ANCP Messages and TLVs  . 22
     5.1.  Overview . . . . . . . . . . 27
     4.1.  Provisioning Message . . . . . . . . . . . . . . . 22
       5.1.1.  ATM-Specific Considerations . . . . 27
     4.2.  Generic Response Message . . . . . . . . . 22
       5.1.2.  Ethernet-Specific Considerations . . . . . . . . 28
     4.3.  Target TLV . . . 23
     5.2.  ANCP Based DSL Topology Discovery . . . . . . . . . . . . 24
       5.2.1.  Goals . . . . . . . . . 30
     4.4.  Command TLV  . . . . . . . . . . . . . . . 24
       5.2.2.  Message Flow . . . . . . . . 30
     4.5.  Status-Info TLV  . . . . . . . . . . . . . 24
       5.2.3.  Specification of the ANCP DSL Topology Discovery
               Capability . . . . . . . . 31
   5.  Introduction To ANCP Capabilities For Digital Subscriber
       Lines (DSL)  . . . . . . . . . . . . . . 25
     5.3.  ANCP based DSL Line Configuration . . . . . . . . . . . 32
     5.1.  DSL Access Line Identification . 40
       5.3.1.  Goals . . . . . . . . . . . . . 33
       5.1.1.  Control Context (Informative)  . . . . . . . . . . . 40
       5.3.2.  Message Flow . 33
       5.1.2.  TLVs For DSL Access Line Identification  . . . . . . . 34
   6.  ANCP Based DSL Topology Discovery  . . . . . . . . . . . . . 40
       5.3.3.  Specification of the ANCP DSL Line Configuration
               Capability . 37
     6.1.  Control Context (Informative)  . . . . . . . . . . . . . . 37
     6.2.  Protocol Requirements  . . . . . . . 42
     5.4.  ANCP Based DSL Line Testing Capability . . . . . . . . . . 46
       5.4.1.  Message Flow . 39
       6.2.1.  Protocol Requirements On the AN Side . . . . . . . . . 39
       6.2.2.  Protocol Requirements On the NAS Side  . . . . . . . . 40
     6.3.  ANCP Port UP and Port DOWN Event Message Descriptions  . . 40
     6.4.  Procedures . 46
       5.4.2.  Specification of the ANCP DSL Line  Testing
               Capability . . . . . . . . . . . . . . . . . . . . . . 47
   6.  Additional ANCP Messages and TLVs . 42
       6.4.1.  Procedures On the AN Side  . . . . . . . . . . . . . 51
     6.1.  Additional Messages and General Messaging Principles . 42
       6.4.2.  Procedures On the NAS Side . . . . 51
       6.1.1.  General Principles for the  Design of ANCP Messages . 51
       6.1.2.  Provisioning Message . . . . . . . . . 43
     6.5.  TLVs For DSL Line Attributes . . . . . . . . 52
       6.1.3.  Generic Response Message . . . . . . . 43
       6.5.1.  DSL-Line-Attributes TLV  . . . . . . . . . 53
     6.2.  TLVs For General Use . . . . . . 43
       6.5.2.  DSL-Type TLV . . . . . . . . . . . . . 54
       6.2.1.  Target . . . . . . . . 44
       6.5.3.  Actual-Net-Data-Rate-Upstream TLV  . . . . . . . . . . 44
       6.5.4.  Actual-Net-Data-Rate-Downstream TLV  . . . . . . . . . 44
       6.5.5.  Minimum-Net-Data-Rate-Upstream TLV . . . . . . 54
       6.2.2.  Command . . . . 45
       6.5.6.  Minimum-Net-Data-Rate-Downstream TLV . . . . . . . . . 45
       6.5.7.  Attainable-Net-Data-Rate-Upstream TLV  . . . . . . . . 45
       6.5.8.  Attainable-Net-Data-Rate-Downstream TLV  . . . . . . . 55
       6.2.3.  Status-Info 45
       6.5.9.  Maximum-Net-Data-Rate-Upstream TLV . . . . . . . . . . 46
       6.5.10. Maximum-Net-Data-Rate-Downstream TLV . . . . . . . . . 46
       6.5.11. Minimum-Net-Low-Power-Data-Rate-Upstream TLV . . . . . 46
       6.5.12. Minimum-Net-Low-Power-Data-Rate-Downstream TLV . . . 56
   7.  IANA Considerations . 46
       6.5.13. Maximum-Interleaving-Delay-Upstream TLV  . . . . . . . 47
       6.5.14. Actual-Interleaving-Delay-Upstream TLV . . . . . . . . 47
       6.5.15. Maximum-Interleaving-Delay-Downstream TLV  . . . . . 57
     7.1.  Summary . 47
       6.5.16. Actual-Interleaving-Delay-Downstream . . . . . . . . . 47
       6.5.17. DSL-Line-State TLV . . . . . . . . . . . . . . . . . 57 . 47
       6.5.18. Access-Loop-Encapsulation TLV  . . . . . . . . . . . . 48
   7.  ANCP based DSL Line Configuration  . . . . . . . . . . . . . . 49
     7.1.  Control Context (Informative)  . . . . . . . . . . . . . . 49
     7.2.  IANA Actions  Protocol Requirements  . . . . . . . . . . . . . . . . . . 50
       7.2.1.  Protocol Requirements On the NAS Side  . . . . . 58
   8.  Security Considerations . . . 51
       7.2.2.  Protocol Requirements On the AN Side . . . . . . . . . 51
     7.3.  ANCP Port Management (Line Configuration) Message
           Format . . . . . . . 62
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . 51
     7.4.  Procedures . . . . 62
   10. References . . . . . . . . . . . . . . . . . . . . 54
       7.4.1.  Procedures On the NAS Side . . . . . . 62
     10.1. Normative References . . . . . . . . 54
       7.4.2.  Procedures On the AN Side  . . . . . . . . . . . 62
     10.2. Informative References . . . 54
     7.5.  TLVs For DSL Line Configuration  . . . . . . . . . . . . . 55
       7.5.1.  Service-Profile-Name TLV . . 63
   Authors' Addresses . . . . . . . . . . . . . 55
   8.  ANCP-Based DSL Remote Line Connectivity Testing  . . . . . . . 55
     8.1.  Control Context (Informative)  . . . . 64

1.  Specification Requirements

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

2. . . . . . . . . . . 55
     8.2.  Protocol Requirements  . . . . . . . . . . . . . . . . . . 56
       8.2.1.  Protocol Requirements On the NAS Side  . . . . . . . . 56
       8.2.2.  Protocol Requirements On the AN Side . . . . . . . . . 57
     8.3.  Port Management (OAM) Message Format . . . . . . . . . . . 57
     8.4.  Procedures . . . . . . . . . . . . . . . . . . . . . . . . 58
       8.4.1.  NAS-Side Procedures  . . . . . . . . . . . . . . . . . 58
       8.4.2.  AN-Side Procedures . . . . . . . . . . . . . . . . . . 59
     8.5.  TLVs For the DSL Line Remote Connectivity Testing
           Capability . . . . . . . . . . . . . . . . . . . . . . . . 60
       8.5.1.  OAM-Loopback-Test-Parameters TLV . . . . . . . . . . . 60
       8.5.2.  Opaque-Data TLV  . . . . . . . . . . . . . . . . . . . 61
       8.5.3.  OAM-Loopback-Test-Response-String TLV  . . . . . . . . 61
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 61
     9.1.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . 61
     9.2.  IANA Actions . . . . . . . . . . . . . . . . . . . . . . . 62
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 67
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 69
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 69
     12.2. Informative References . . . . . . . . . . . . . . . . . . 69
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70

1.  Introduction

   This draft defines a new protocol, the Access Node Control Protocol
   (ANCP), to realize a control plane between a service-oriented layer 3
   edge device (the Network Access Server, NAS) and a layer 2 Access
   Node (e.g., Digital Subscriber Line Access Module, DSLAM)
   (ANCP), to realize a control plane between a service-oriented layer 3
   edge device (the Network Access Server, NAS) and a layer 2 Access
   Node (e.g., Digital Subscriber Line Access Module, DSLAM) in order to
   perform QoS-related, service-related and subscriber-related
   operations.  The requirements for ANCP and the context within which
   it operates are described in [RFC5851].

   The protocol specification takes GSMPv3 [RFC3292] as a starting
   point, and the implementor is directed to parts of [RFC3292] for the
   specification of some aspects of the protocol.  However, ANCP
   introduces so many extensions and modifications to GSMPv3 that the
   two protocols are not interoperable.

   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 order to
   perform QoS-related, service- related this document, information flows between the
   control applications and subscriber-related
   operations. ANCP are described.  The protocol specification takes GSMPv3 [RFC3292] as a
   starting point and specifies modifications and extensions to GSMPv3 purpose of such
   descriptions is to achieve ANCP requirements.  Although ANCP clarify the boundary between this specification
   and, for example, [TR-147].  There is based no intention to place limits on GSMPv3,
   the
   two protocols degree to which the control application and the protocol
   implementation are not interoperable. integrated.

   This specification assumes specifies ANCP transport over TCP/IP. TLS/TCP/IP.  TCP
   encapsulation for ANCP is as defined for GSMPv3 in [RFC3293].  ANCP  The
   alternative GSMPv3 encapsulation directly over Ethernet and ATM as
   defined for GSMPv3 in [RFC3293] is not considered.

   ANCP uses a subset of GSMPv3 messages, message content, and
   procedures to implement currently defined use cases.  Additional ANCP
   messages, message content, and procedures are specified in this
   document and may also be specified in other documents extending considered for ANCP.

   The organization of this document is as follows:

   o  The next sub-section introduces two sub-sections introduce some terminology that will be
      useful in understanding the rest of the document.

   o  Section 3 2 provides a description of the access networks within
      which ANCP will typically be deployed.

   o  Section 4 3 specifies generally applicable aspects of the ANCP
      protocol.

   o  Section 4 specifies some messages and TLVs intended for use by
      multiple capabilities spanning multiple technologies.

   o  Section 5 describes and specifies 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 line testing (OAM).

   o  Section 6 provides a set of specifications expected to be useful
      when defining extensions to the base protocol. topology discovery, line
      configuration, and remote line connectivity testing.

   o  Section 7 9 is the IANA Considerations section.  Some codepoints are
      added to existing GSMPv3 registries set up by [RFC3292], but a
      number of new ANCP-specific registries are also defined.

   o  Section 8 10 addresses security considerations relating to ANCP,
      beginning with
      heavy reliance on the requirements stated in [RFC5713].

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

   At the time of writing of this specification some implementations of
   the ANCP protocol based on pre-standards drafts are already
   available.  These early-draft implementations use protocol version/
   sub-version 3.1.  The standard ANCP protocol will use version/
   sub-version 3.2 Adopting a new sub-version value provides a way to
   disambiguate the two protocols and provides support for running a
   pre-standard and a standards compliant ANCP implementation on any
   given ANCP node.  The mechanism used to identify the protocol
   version/sub-version is part of the adjacency negotiation process and
   it is described in detail in Section 4.5. 3.5.  NOTE: this mechanism does
   not guarantee backwards compatibility of the published ANCP
   specification with those early-draft implementations.

2.1.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

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

1.2.  Terminology

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

   Access Node (AN):  [RFC5851] Network device, usually located at a
      service provider central office or street cabinet that terminates
      access (local) loop connections from subscribers.  In case the
      access loop is a Digital Subscriber Line (DSL), the Access Node
      provides DSL signal termination, and is referred to as a DSL
      Access Multiplexer (DSLAM).

   Network Access Server (NAS):  [RFC5851] Network element which
      aggregates subscriber traffic from a number of Access Nodes.  The
      NAS is an
      injection enforcement point for policy management and IP QoS in
      the access network.  It is also referred to as a Broadband Network
      Gateway (BNG) or Broadband Remote Access Server (BRAS).

   Home Gateway (HGW):  Network element that connects subscriber devices
      to the Access Node and the access network.  In the case of DSL,
      the Home Gateway is a DSL network termination that may operate
      either as a layer 2 bridge or as a layer 3 router.  In the latter
      case, such a device is also referred to as a Routing Gateway (RG).

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

   Access Node control adjacency:  (modified from [RFC5851]) the
      relationship between the AN-side ANCP agent and the NAS-side ANCP
      agent for the purpose of exchanging Access Node Control Protocol
      messages.  The adjacency may either be up or down, depending on
      the result of the Access Node Control adjacency protocol
      operation.

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

   Type-Length-Value (TLV):  a data structure consisting of a sixteen-
      bit type field, a sixteen-bit length field, and a variable-length
      value field padded to the nearest 32-bit word boundary, as
      described in Section 3.6.2.  The 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: 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 of the DSL line that can be used to
      transmit actual user information (e.g. (e.g., ATM cells
      of or Ethernet frames).
      It excludes overhead that pertains to the physical transmission
      mechanism (e.g. (e.g., trellis coding in the case of DSL).  This  It includes
      TPS-TC (Transport Protocol Specific - Transmission Convergence)
      encapsulation; this is zero for ATM encapsulation, and non-zero
      for 64/65 encapsulation.

   Line rate:  [RFC5851] defined in section 3.39 of by ITU-T G.993.2.

   DSL line (synch) rate:  the total data rate of the DSL line,
      including  It contains the
      complete overhead attributable to the physical transmission
      mechanism. including Reed-Solomon and trellis coding.

   DSL multi-pair bonding:  method for bonding (or aggregating) multiple
      xDSL lines into a single bi-directional logical link, henceforth
      referred to in this draft as "DSL bonded circuit".  DSL "multi-
      pair" bonding allows an operator to combine the data rates on two
      or more copper pairs, and deliver the aggregate data rate to a
      single customer.  ITU-T recommendations G.998.1 and G.998.2
      respectively describe ATM and Ethernet based multi-pair bonding.

   Type-Length-Value (TLV):  a data structure consisting

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 sixteen-
      bit type field, DSLAM in the central office, or a sixteen-bit length field, remote DSLAM, or a Remote Access
   Multiplexer (RAM).  The Access Node is the first point in the network
   where traffic on multiple DSL lines will be aggregated onto a single
   network.

   The NAS performs multiple functions in the network.  The NAS is the
   aggregation point for subscriber traffic.  It provides aggregation
   capabilities (e.g.  IP, PPP, ATM) between the Regional/Access Network
   and the NSP or ASP.  These include traditional ATM-based offerings
   and newer, more native IP-based services.  This includes support for
   Point-to-Point Protocol over ATM (PPPoA) and a variable-length
      value field padded to the nearest 32-bit word boundary, PPP over Ethernet
   (PPPoE), as
      described in Section 4.6.2.  The value field of a TLV can contain
      other TLVs.  An IANA registry well as direct IP services encapsulated over an
   appropriate layer 2 transport.

   Beyond aggregation, the NAS is maintained for values of also the ANCP
      TLV Type field.

   ANCP Protocol Capability:  A detailed specification of ANCP messages,
      message content, enforcement point for policy
   management and procedures required to implement a specific
      use case or set of use cases.  ANCP capabilities may be specific
      to one IP QoS in the regional/access networks.  To allow IP
   QoS support over an existing non-IP-aware layer 2 access technology or technology independent.  The set of
      capabilities applicable to network
   without using multiple layer 2 QoS classes, a given ANCP session are negotiated
      during session startup.

   ANCP session (also called an adjacency):  A session mechanism based on
   hierarchical scheduling is used.  This mechanism, defined in
   [TR-059], preserves IP QoS over the ATM network between a the NAS and
      an Access Node, beginning with
   the initiation routing gateway (RG) at the edge of the transport
      connection subscriber network, by
   carefully controlling downstream traffic in the AN, passing through adjacency negotiation,
      discovery and provisioning stages, and continuing with service
      control NAS, so that
   significant queuing and possible OAM operations until congestion does not occur further down the transport connection
   ATM network.  This is terminated.  There may be more than one ANCP session active
      between 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 and a given AN due to partitioning.

3.   Broadband   : Network Access Server

               Figure 2: ATM Broadband Aggregation

3.1.  ATM-based broadband Topology

2.2.  Ethernet-Based Broadband Aggregation

   The Ethernet aggregation network architecture builds on the Ethernet
   bridging/switching concepts defined in IEEE 802.  The end to end DSL Ethernet
   aggregation network consists provides traffic aggregation, class of network service provider (NSP)
   and application service provider (ASP) networks, regional/access
   network,
   distinction, and customer premises network.  Figure 1 shows ATM broadband
   access network components.

   The regional/access network consists of the regional network, Network
   Access Server (NAS), separation and the access network as shown traceability.  VLAN tagging
   defined in Figure 1.

   Its primary function IEEE 802.1Q and being enhanced by IEEE 802.1ad is to provide end-to-end transport between used as
   standard virtualization mechanism in the
   customer premises Ethernet aggregation
   network.  The aggregation devices are "provider edge bridges" defined
   in IEEE 802.ad.

   Stacked VLAN tags provide one possible way to create equivalent of
   "virtual paths" and "virtual circuits" in the NSP or ASP. aggregation network.
   The Access Node terminates the DSL signal.  It may "outer" vlan can be in the used to create a form of "virtual path"
   between a given DSLAM in the central office, or and a remote DSLAM, or given NAS.  "Inner" VLAN tags create a Remote Access
   Multiplexer (RAM).  The Access Node
   form of "virtual circuit" on a per DSL line basis.  This is the first point in the network
   where traffic on 1:1
   VLAN allocation model.  An alternative model is to bridge sessions
   from multiple DSL lines will be aggregated onto subscribers behind a DSLAM into a single
   network.

   The NAS performs multiple functions VLAN in the
   aggregation network.  The NAS  This is the
   aggregation point for subscriber traffic.  It N:1 VLAN allocation model.  Section
   1.6 of [TR-101] provides aggregation
   capabilities (e.g.  IP, PPP, ATM) between 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 Regional/Access Network Access Node Control Protocol
   (ANCP) that are generally applicable.  As indicated above, ANCP is
   derived from GSMPv3 [RFC3292].  Reference to [RFC3292] is made where
   this is applicable, but ANCP introduces numerous modifications and
   extensions to the NSP or ASP.  These include traditional ATM-based offerings basic GSMPv3 protocol.  Moreover, ANCP uses only a
   subset of the messages, message contents, and newer, more native IP-based services.  This includes support procedures defined for
   Point-to-Point Protocol over ATM (PPPoA)
   GSMPv3, and PPP over Ethernet
   (PPPoE), as well as direct IP services encapsulated over defines additional messages, message contents, and
   procedures that are specific to ANCP.

3.1.  Protocol Version

   GSMPv3 messages contain an
   appropriate layer 2 transport.

   Beyond aggregation, 8-bit protocol version field.  As
   described below, ANCP subdivides this into two 4-bit sub-fields, for
   version and sub-version.  Implementations of this version of the NAS is also ANCP
   specification MUST set the injection point for policy
   management version sub-field to 3 and IP QoS the sub-version
   sub-field to 1.  That is, the hexadecimal representation of the value
   of the complete protocol version field MUST be 0x31.

   RFC EDITOR'S NOTE: please change the value of sub-version in the regional/access networks.  To allow IP
   QoS support over an existing non-IP-aware layer 2 access network
   without using multiple layer
   above paragraph to 2 QoS classes, (respectively a mechanism based on
   hierarchical scheduling is used.  This mechanism, defined version field value of 0x32) in
   [TR_059], preserves IP QoS over the ATM network between
   the NAS and published specification.  For an explanation see the routing gateway (RG) at Introduction
   above.

3.2.  ANCP Transport

   This document specifies the edge use of the subscriber network, by
   carefully controlling downstream traffic TCP/IP for transport of ANCP
   messages.  Other specifications may introduce additional transports
   in the NAS, so that
   significant queuing and congestion does not occur further down future.

      In the case of ATM network.  This is achieved by using access, a diffserv-aware hierarchical
   scheduler in the separate PVC (control channel)
      capable of transporting IP MAY be configured between NAS that will account for downstream trunk
   bandwidths and DSL synch rates.

   [RFC5851] provides detailed definition and functions of each network
   element in the broadband reference architecture.

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

                       +------------------+ +--------------------------+
   +---------+   +---+ | +-----+ +------+ | |+-----+ +---+ +---------+ |
NSP|         | +-|NAS|-| |ATM  |-|Access| --||DSL  |-|HGW|-|Subscriber||
---+ Regional| | +---+ | +-----+ |
      AN for ANCP messages.

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

   When transported over TCP, ANCP messages MUST use the encapsulation
   specified for GSMPv3 messages carried over TCP in [RFC3293].  This
   encapsulation consists of a four-byte header field prepended to the
   ANCP message as shown in Figure 3.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Identifier (0x880C)        | ||Modem| +---+ |Devices   ||
   |Broadband| | +---+ |         +------+ | |+-----+       +----------+|
ASP|Network  |-+-|NAS| +--------------|---+ +--------------------------+
---+         | | +---+           Length              |     +--------------------------+
      |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                         ANCP Message                          ~
      | +---+                                                               |     |+-----+ +---+ +----------+|
   +---------+ +-|NAS|                +-----|| DSL |-|HGW|-|Subscriber||
                 +---+                      ||Modem| +---+ |Devices   ||
                                            |+-----+       +----------+|
                                            +--------------------------+
 HGW   : Home Gateway
 NAS   : Network Access Server
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 1: ATM Broadband Aggregation Topology

3.2.  Ethernet-based broadband aggregation

   The Ethernet aggregation network architecture builds on the Ethernet
   bridging/switching concepts defined in IEEE 802. 3: Encapsulation of ANCP Messages Over TCP/IP

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

   Stacked VLAN tags provide one possible way to create equivalent of
   "virtual paths" as follows:

   Identifier:  This 2-byte field identifies a GSMP or ANCP message.
      The type code for GSMP and "virtual circuits" in ANCP messages is 0x880C (i.e., the aggregation network. same
      as GSMP's Ethertype).

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

   The "outer" vlan can be used Access Node MUST initiate the TCP session to create a form of "virtual path"
   between a given DSLAM and a given the NAS.  "Inner" VLAN tags create a
   form of "virtual circuit" on  This is a per DSL line basis.
   deviation from [RFC3293], which requires the controller to initiate
   the TCP connection to the switch.

      This is necessary to avoid static address provisioning on the 1:1
   VLAN allocation model.  An alternative model NAS
      for all the ANs that are being served by the NAS.  It is easier to bridge sessions
   from multiple subscribers behind a DSLAM into
      configure a given AN with the single VLAN in IP address of the
   aggregation network.  This NAS that
      serves the AN.

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

   In the N:1 VLAN allocation model.
   Architectural and topological models event of an Ethernet aggregation
   network in context of DSL aggregation are defined in [TR_101].

4.  Access Node Control Protocol -- General Aspects

   This section specifies aspects 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 Access Node Control Protocol
   (ANCP) ANCP agent MUST NOT
   assume that the fields are generally applicable.  As indicated above, zero-terminated.

3.4.  Treatment of Reserved and Unused Fields

   ANCP is
   derived messages contain a number of fields that are unused or reserved.
   Some fields are always unused (typically because they were inherited
   from GSMPv3 [RFC3292].  Reference to [RFC3292] is made where
   this is applicable, but ANCP introduces numerous modifications and
   extensions to are not useful in the basic GSMPv3 protocol.  Moreover, ANCP uses only a
   subset of the messages, message contents, and procedures defined for
   GSMPv3.

   The following context).  Others are
   reserved in the only GSMPv3 [RFC3292] messages that current specification, but are
   currently used by provided for
   flexibility in future extensions to ANCP.

   Event Messages

      *  Port UP Message

      *  Port DOWN Message

      These messages are used  Both reserved and unused
   fields MUST be set to zeroes by the ANCP "DSL topology discovery"
      capability.

   Port Management Messages  These messages are used sender and MUST be ignored by the ANCP "DSL
      line configuration" and ANCP "DSL line testing" capabilities.

   Adjacency Protocol Messages  These messages
   receiver.

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

3.5.  Use of the GSMPv3 Adjacency Protocol

   Section 11 of [RFC3292] defines the GSMPv3 adjacency between a NAS and an AN. protocol.  ANCP modifies and extends some basic
   reuses the GSMPv3 procedures.  These
   modifications adjacency protocol to synchronize the NAS and extensions are summarized below,
   Access Nodes and described in
   more detail maintain the ANCP session.  After the TCP connection
   is established, adjacency protocol messages MUST be exchanged as
   specified in Section 11 of [RFC3292], subject to the succeeding sections.

   o  ANCP provides support for a capability negotiation mechanism
      between additional
   specifications of this section.  ANCP peers by extending messages other than adjacency
   protocol messages MUST NOT be sent until the GSMPv3 adjacency protocol.
      This mechanism and corresponding protocol has
   achieved synchronization.

3.5.1.  ANCP Adjacency Message Format

   The GSMPv3 adjacency message extensions are format defined in section Section 4.5.

   o  The TCP connection establishment procedure in 11 of
   [RFC3292] is modified and extended for ANCP deviates
      slightly from connection establishment in GSMPv3 as specified in
      [RFC3293].  This is described shown in section Section 4.2.

   o  ANCP adds content to GSMPv3 messages Figure 4
   below.  The 8-bit "version" field in the form of additional
      fixed fields and Type-Length-Value (TLV) structures.  TLVs also
      provide flexibility to both GSMPv3 and ANCP-specific adjacency protocol
   messages
      because their order in the message and whether or not specific
      TLVs are present can vary from one message instance is modified to carry the next.

4.1.  Protocol Version

   GSMPv3 messages contain an 8-bit protocol version field.  As
   described below, ANCP subdivides this into two 4-bit sub-fields, for version (four bits) and sub-version.  Implementations of this sub-
   version of (four bits).  See Section 3.1 for the ANCP
   specification MUST values to set the for
   version sub-field to 3 and the sub-version
   sub-field to 1.  That is, for the hexadecimal representation present version of this
   specification.

   The semantics and suggested values for the Code, Sender Name,
   Receiver Name, Sender Instance, and Receiver Instance fields are as
   defined in Section 11 of [RFC3292].  The Sender Port, and Receiver
   Port SHOULD be set to 0 by both ends.  The pType field MAY be set to
   0 (No Partition) or another value depending on local configuration.
   The pFlag SHOULD be set to 1 (New Adjacency).

   In addition to the value modification of the complete protocol version field MUST be 0x31.

   RFC EDITOR'S NOTE: please change the value of sub-version in field, ANCP adds
   several new fields.  These are described below the
   above paragraph to figure.

       0                   1                   2 (respectively a version field value                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Ver |  Sub  | Message Type  |     Timer     |M|     Code    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Sender Name                          |
      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      |                         Receiver Name                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Sender Port                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Receiver Port                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | PType | PFlag |               Sender Instance                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Partition ID  |              Receiver Instance                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Reserved      | # of 0x32) in
   the published specification.  For an explanation see the Introduction
   above.

4.2. Caps     | Total Length                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                   Capability Fields                           ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 4: ANCP Transport

   This document specifies the Adjacency Message Format

   The fields added by ANCP are as follows:

   Reserved (8 bits):  reserved for use by a future version of TCP/IP for transport this
      specification.

   # of ANCP
   messages.  Other specifications may introduce additional transports
   in the future.

      In Caps:  indicates the case number of ATM access, a separate PVC (control channel)
      capable capability fields that follow.

   Total Length:  indicates the total number of transporting IP may be configured between NAS and bytes occupied by the
      AN for
      capability fields that follow.

   Capability Fields:  Each capability field indicates one ANCP messages.

      In
      capability supported by the case sender of the adjacency message.
      Negotiation of an Ethernet access/aggregation network, a typical
      practice is common set of capabilities to send be supported within
      the Access Node Control Protocol messages over
      a dedicated Ethernet virtual LAN (VLAN) using a separate VLAN
      identifier (VLAN ID).

   When transported over TCP, ANCP messages MUST use the encapsulation
   specified for GSMPv3 messages carried over TCP session is described in [RFC3293].  This
   encapsulation consists Section 3.5.2.  The detailed
      format of a four-byte header capability field prepended to the
   ANCP message as is shown in Figure 2. 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Identifier (0x880C)     Capability Type           |   Capability Length           |
      |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                         ANCP Message                                                               ~
      |                                                               |
      ~                   Capability Data                             ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 2: Encapsulation of ANCP Messages Over TCP/IP 5: Capability Field

   The fields sub-fields of the encapsulating header this structure are as follows:

   Identifier:  This 2-byte field identifies a GSMP or ANCP message.
      The type code for GSMP and ANCP messages is 0x880C (i.e., the same
      as GSMP's Ethertype).

   Length:  This 2-byte unsigned integer

   Capability Type:  indicates the total length specific capability supported.  An
      IANA registry exists for values of
      the ANCP message.  It does not include the 4-byte encapsulating
      header. this sub-field.  The Access Node MUST initiate values
      specified by this document are listed below.

   Capability Length:  the TCP session to number of bytes of data contained in the NAS.  This is a
   deviation from [RFC3293], which requires
      Capability Data sub-field, excluding padding.  If the controller to initiate definition
      of a particular capability includes no capability data, the TCP connection to value
      of the switch.

      This Capability Length sub-field is necessary to avoid static provisioning on zero.

   Capability Data:  contains data associated with the NAS capability as
      specified for all that capability.  If the ANs that are being served by definition of a particular
      capability includes no capability data, the NAS.  It Capability Data sub-
      field is easier absent (has zero length).  Otherwise, the Capability Data
      sub-field MUST be padded with zeroes as required to
      configure terminate on a given AN with the single IP address
      4-byte word boundary.  The possibility of specifying capability
      data provides the NAS that
      serves flexibility to advertise more than the AN. mere
      presence or absence of a capability if needed.

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

   In the event of an ANCP transport protocol failure, all pending ANCP
   messages destined as applied to DSL
   access:

   o  Capability Type : DSL Topology Discovery = 0x01

         Access technology: DSL

         Length (in bytes) : 0

         Capability Data : NULL

      For the disconnected recipient SHOULD be discarded
   until the transport connection is re-established.

4.3.  Encoding detailed protocol specification of Text Fields

   In ANCP, all text fields use UTF-8 encoding [RFC3629].  Note that US
   ASCII characters have this capability see
      Section 6.

   o  Capability Type : DSL Line Configuration = 0x02

         Access technology: DSL

         Length (in bytes) : 0

         Capability Data : NULL

      For the same representation when coded as UTF-8 as
   they do when coded according to [US_ASCII].

4.4.  Treatment of Reserved and Unused Fields

   ANCP messages contain a number detailed protocol specification of fields that are unused or reserved.
   Some fields are always unused (typically because they were inherited
   from GSMPv3 but are not useful in 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.

3.5.2.  ANCP context.  Others are
   unused in Adjacency Procedures

   Before beginning adjacency negotiation, the current specification, but are provided for flexibility
   in future extensions to ANCP.  Both reserved ANCP agent and unused fields MUST
   be set to zeroes by the sender and MUST be ignored by
   control application "must" agree on the receiver.

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

4.5.  Use of capabilities that they
   support.  This agreement "must" include the GSMPv3 Adjacency Protocol

   Section 11 transfer of [RFC3292] defines any
   application-level information required to build the GSMPv3 adjacency protocol.  ANCP
   reuses Capability Data
   fields within the GSMPv3 adjacency protocol to synchronize Capability structures.  Note that none of the
   capabilities specified in this document require any such information.

   The NAS and
   Access Nodes and maintain MUST set the ANCP session.  After M-flag in the TCP connection SYN message (signifying it is the
   master).  Once the adjacency is established, periodic adjacency protocol
   messages (type ACK) MUST be exchanged as
   specified in Section 11 of [RFC3292], subject to exchanged.  The default for the additional
   specifications of this section.  ANCP messages other than adjacency
   protocol messages MUST NOT ACK
   interval to be sent until advertised in the adjacency protocol has
   achieved synchronization.

4.5.1.  ANCP Adjacency Message Format

   The GSMPv3 adjacency message format defined in Section 11 of
   [RFC3292] messages is modified and extended 25 seconds for ANCP as shown in Figure 3
   below.
   ANCP.  The 8-bit "version" field in the GSMPv3 adjacency protocol
   messages actual value SHOULD be configurable and is a deployment
   choice.  It is modified RECOMMENDED that both ends specify the same timer
   value; to carry achieve this, each end SHOULD compare the ANCP version (four bits) and sub-
   version (four bits).  See Section 4.1 for timer value in
   the values to set for
   version first adjacency message it receives with its own preferred value
   and sub-version for agree to use the present version higher of this
   specification. the two values.  That is, the node
   that receives a higher timer value than its own SHOULD reply in its
   subsequent adjacency messages (such as SYNACK, ACK) with the higher
   timer value.

   In addition to the modification of adjacency protocol the version field,
   ANCP adds several new fields.  These are described below the figure.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Ver |  Sub  | Message Type  |     Timer     |M|     Code    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Sender Name                          |
      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      |                         Receiver Name                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Sender Port                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Receiver Port                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | PType | PFlag |               Sender Instance                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Partition ID  |              Receiver Instance                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Reserved      | # of Caps     | Total Length                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                   Capability Fields                           ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 3

   The and sub-version fields added by ANCP are as follows:

   Reserved:  reserved used
   for use by a future version of this
      specification.

         Note: this was the Tech Type field in pre-standard versions of
         ANCP, but was determined to negotiation.  The version negotiation MUST be unnecessary.

   # of Caps:  indicates completed
   before synchronisation is achieved.  In a SYN message the number of capability version/
   sub-version fields that follow.

   Total Length:  indicates always contain the total number of bytes occupied highest version understood by
   the
      capability fields sender.  A receiver receiving a SYN message with a version/
   sub-version higher than it understands MUST silently discard that follow.

   Capability Fields:  Each capability field indicates one ANCP
      capability supported by the sender of the adjacency
   message.
      Negotiation of  A receiver receiving a common set of capabilities to be supported SYN message with a version/
   sub-version within the ANCP session is described in Section 4.5.2.  The detailed
      format of a capability field is described below.

   The format range of versions that it understands MUST
   reply with a capability field is shown SYNACK with the version/sub-version from the received
   SYN in Figure 4:

       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 4: Capability Field

   The sub-fields of this structure are as follows:

   Capability Type:  indicates its ANCP version/sub-version fields.  This defines the specific capability supported.  An
      IANA registry exists for values
   version/sub-version of this sub-field.  The values
      specified by this document are listed below.

   Capability Length: the number of bytes of data contained ANCP protocol to be used while the
   adjacency remains synchronized.  All other ANCP messages within the
   session MUST use the agreed version in the
      Capability Data sub-field, excluding padding.  If version/sub-version
   fields.

   Both the definition NAS and the Access Node MUST advertise supported
   capabilities in the adjacency messages they send.  The same message
   MAY advertise capabilities for any mixture of access technologies.
   If a particular capability includes received adjacency message indicates no support for a capability data,
   that is supported by the value
      of receiving device, it MUST disable the Capability Length sub-field is zero.

   Capability Data:  contains data associated
   capability locally and MUST send an updated adjacency message with
   the corresponding capability as
      specified for that capability.  If field omitted to match the definition received
   capability set.  This process will eventually result in both sides
   agreeing on the maximal common set of supported capabilities.  The
   adjacency MUST NOT come up if that common set is empty.

   Subsequent to adjacency startup, if the adjacency times out on either
   end, due to not receiving an adjacency message for a particular
      capability includes no capability data, duration of (3 *
   Timer value), where the Capability Data sub-
      field timer value is absent (has zero length).  Otherwise, negotiated as described above,
   all the Capability Data
      sub-field MUST state received from the ANCP peer SHOULD be padded with zeroes as required cleaned up, and
   the TCP connection SHOULD be closed.  The NAS MUST continue to terminate on a
      4-byte word boundary. listen
   for new connection requests.  The possibility of specifying AN MUST try to re-establish the TCP
   connection and both sides MUST attempt to re-establish the adjacency.

   After initial synchronization, if at any time a capability
      data provides mismatch
   is detected, the adjacency MUST be brought down (RSTACK MUST be
   generated by the device detecting the flexibility to advertise more than mismatch), and synchronization
   MUST be re-attempted.

   The ANCP agent "must" notify the mere
      presence control application whenever an
   adjacency is either synchronized or absence lost.  When an adjacency is
   synchronized, the notification "must" include the set of a capability if needed.

   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
   negotiated with the peer along with any application-level information
   conveyed in Capability Data : NULL

      For fields.

3.6.  ANCP General Message Formats

   This section describes the detailed protocol specification general format of this capability see
      Section 5.2.

   o  Capability Type : DSL Line Configuration = 0x02

         Access technology: DSL

         Length (in bytes) : 0

         Capability Data : NULL

      For ANCP messages other than
   the detailed adjacency messages.

   The GSMPv3 general message format, used by all GSMP messages other
   than adjacency protocol specification messages, is defined in Section 3.1.1 of
   GSMPv3 [RFC3292].  ANCP modifies this capability see
      Section 5.3.

   o  Capability base GSMPv3 message format as
   shown in Figure 6.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Vers  |  Sub  | Message Type : DSL Line Testing = 0x04

         Access technology: DSL  | Result|        Code           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Partition ID  |            Transaction Identifier             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |I|      SubMessage Number      |           Length (in bytes) : 0

         Capability Data : NULL

      For the detailed protocol specification of this capability see
      Section 5.4.

4.5.2.              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                          Message Payload                      ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 6: ANCP Adjacency Procedures General Message Format

3.6.1.  The NAS MUST set ANCP Message Header

   The immediately visible differences from GSMPv3 are the M-flag in subdivision
   of the SYN message (signifying it is Version field into version and sub-version, and the
   master).  Once
   reallocation of space between Result and Code to enlarge the adjacency is established, periodic adjacency
   messages (type ACK) MUST be exchanged.  The default range
   for the ACK
   interval to be advertised Code.  The 8-bit version field in the adjacency messages base GSMPv3 message header
   is 25 seconds split into two 4 bit fields for
   ANCP.  The actual value SHOULD be configurable and is an
   implementation choice.  It is RECOMMENDED that both ends specify carrying the
   same timer value; to achieve this, each end SHOULD compare version and a sub-
   version of the timer
   value ANCP protocol.  The Result field in the first adjacency message it receives with its own
   preferred value and agree header
   has been modified to use be 4 bits long, and the higher Code field to be 12 bits
   long.

   A complete explanation of the two values.  That
   is, header fields follows.

3.6.1.1.  Version and Sub-Version Fields

   Together these fields reproduce the node that receives a higher timer value than its own SHOULD
   reply in its subsequent adjacency messages (such as SYNACK, ACK) with version of the higher timer value.

   In ANCP protocol that
   was agreed for the session during adjacency protocol negotiation.  See
   Section 3.1 for the values to set for version and sub-version fields are used for version negotiation.  The version negotiation is performed before
   synchronisation is achieved.  In a SYN message the version/
   sub-version fields always contain the highest
   present version understood by of this specification.

3.6.1.2.  Message Type Field

   This field indicates the sender.  A receiver receiving a SYN ANCP message with type.  Message type values are
   registered in a version/
   sub-version higher than it understands MUST silently discard that
   message.  A receiver receiving common GSMPv3/ANCP IANA registry.

3.6.1.3.  Result Field

   The Result field is derived from GSMPv3 [RFC3292].  Ignore (0x0) is a SYN message with
   new value added by ANCP.  The remaining Result values listed below
   are a version/
   sub-version within subset of those defined for GSMPv3.  GSMPv3 expected the range sender
   of versions that it understands MUST
   reply with a SYNACK with request to choose between NAck (0x1) and AckAll (0x2) according
   to its needs.  ANCP specifies what Result value each request should
   have.  Responses indicate either Success (0x3) or Failure (0x4) as
   the version/sub- version from case may be.

   Ignore:  Res = 0x0 - Treat this field as a "no operation" and follow
      the response procedures specified for the received
   SYN in its ANCP version/sub-version fields.  This defines message type.

   Nack:  Res = 0x1 - Result value indicating that a response is
      expected to the
   version/sub-version request only in cases of failure caused during the ANCP protocol to be used while
      processing of the
   adjacency remains synchronised.  All other ANCP messages within message contents or of the
   session MUST use contained
      directive(s).

   AckAll:  Res = 0x2 - Result value indicating that a response to the agreed version
      message is requested in all cases.

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

   Failure:  Res = 0x4 - Result value indicating that this is a response
      and suggested values for that the Code, Sender Name,
   Receiver Name, Sender Instance, and Receiver Instance fields are as
   defined in Section 11 of [RFC3292]. request was not executed successfully.  The Sender Port, and Receiver
   Port receiver
      of the response SHOULD be set to 0 take further action as indicated by both ends.  The pType the
      Code value and any diagnostic data contained in a Status-Info TLV
      included in the response.

3.6.1.4.  Code Field

   This field SHOULD be set
   to 0 (No Partition).  The pFlag SHOULD be set to 1 (New Adjacency).

   If gives further information concerning the adjacency times out on either end, due result in a
   response message.  It is mostly used to not receiving pass an
   adjacency message for error code in a duration of (3 * Timer value), where the
   timer value is specified
   failure response but can also be used to give further information in the adjacency
   a success response message or an event message.  In a request
   message, all the state
   received from the ANCP neighbor SHOULD be cleaned up, Code field is not used and the TCP
   connection SHOULD be closed.  The NAS MUST continue be set to listen for new
   connection requests.  The AN MUST try zero.

   A number of code values are specified below.  Specification of
   additional Code values in extensions or updates to re-establish the TCP
   connection and both sides this document MUST attempt to re-establish
   include the adjacency.

   The handling defined above will need some modifications when following information:

   o  Code value;

   o  One-line description;

   o  Where condition detected: (control application or ANCP
   graceful restart procedures are defined.  These procedures will be
   defined agent);

   o  Further description (if any);

   o  Required additional information in a separate document.

   Both the NAS and response message;

   o  Target (control application or ANCP agent at the Access Node MUST advertise supported
   capabilities in peer that sent
      the adjacency messages they send.  The same message
   MAY advertise capabilities for any mixture of access technologies.
   If a received adjacency message indicates no support original request);

   o  Action RECOMMENDED for a capability
   that is supported by the receiving device, it MUST turn off the
   capability locally and MUST send an updated adjacency message with
   the corresponding capability field omitted ANCP agent

   In addition to match the received
   capability set.  This process will eventually result any suggested action in both sides
   agreeing on the maximal common set text which follows, the
   Code value SHOULD be logged in a MIB.  Where an action includes
   resending of supported capabilities.  The
   adjacency MUST a request, a given request SHOULD NOT come up if that common set is empty.

   After initial synchronization, if at be re-sent more
   than once.

   ANCP agents MAY use any time a capability mismatch
   is detected, of the adjacency MUST be brought down (RSTACK MUST be
   generated by Code values specified in the device detecting IANA
   registry "Global Switch Management Protocol version 3 (GSMPv3)
   Failure Response Message Name Space" if they appear applicable.  In
   particular, the mismatch), values 2, 3, 4, 6, 7, and synchronization
   MUST 19 appear to be reusable
   and are therefore documented below along with a few new ANCP-specific
   values.  Values 30 and 31 are also reusable, but are more
   appropriately documented in a multicast extension document.

   Code value: 2

      *  One-line description: Invalid request message

      *  Where condition detected: ANCP agent

      *  Further description: The request was a properly formed message
         which violates the protocol through its timing or direction of
         transmission.  The most likely reason for this outcome in the
         field will be re-attempted.

4.6.  ANCP General Message Formats

   This section describes a race condition.

      *  Required additional information in the general format of ANCP messages other than response message: none,
         if the adjacency messages.

   The GSMPv3 general response message format, used by all GSMP messages other
   than adjacency protocol messages, is defined in Section 3.1.1 of
   GSMPv3 [RFC3292].  ANCP modifies this base GSMPv3 message format the same type as
   shown the request.  As
         specified in Figure 5.

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

                   Figure 5: Section 4.2 if the response message is a Generic
         Response message.

      *  Target: ANCP General Message Format

4.6.1.  The agent at the peer that sent the original request

      *  Action RECOMMENDED for the receiving ANCP Message Header agent: The immediately visible differences from GSMPv3 are original
         request MAY be re-sent once only after a short delay.  Inform
         the subdivision control application with appropriate identification of the Version field into version and sub-version, and
         failed transaction if the
   reallocation second attempt fails or no second
         attempt is made.

   Code value: 6

      *  One-line description: One or more of space the specified ports are
         down

      *  Where condition detected: control application

      *  Further description (if any): This Code value indicates a state
         mismatch between Result the NAS and Code AN control applications, possibly
         due to enlarge the range
   for Code.  The 8-bit version field a race condition.

      *  Required additional information in the base GSMPv3 message header response message: if the
         request identified multiple access lines or the response is split into two 4 bit fields for carrying a
         Generic Response message, then the version and response MUST contain a sub-
   version
         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 protocol.  The Result field in agent: indicate the message header
   has been modified to be 4 bits long,
         error and forward the Code field line identifier(s) to be 12 bits
   long.

   A complete explanation of the header fields is as follows:

   Version and Sub-version:  The version of the control
         application.

   Code value: 7

      *  One-line description: Invalid Partition ID

      *  Where condition detected: ANCP protocol agent

      *  Further description: This indicates that was
      agreed for the session during adjacency negotiation.  For the
      values that must be placed into these fields, see Section 4.1.

   Message Type:  The ANCP message type.  Message type values are
      registered in a common GSMPv3/ANCP IANA registry.

   Result:  The Result field is derived from GSMPv3 [RFC3292].  Ignore
      (0x0) is request used a new
         Partition ID value added by ANCP.  The remaining Result values
      below are a subset of those defined different from what was determined for GSMPv3.  GSMPv3 expected
      the sender of this
         partition during adjacency negotiation, implying a request to choose state
         mismatch between NAck (0x1) and AckAll
      (0x2) according to its needs.  ANCP specifies what Result value
      each request should have.  Responses indicate either Success (0x3)
      or Failure (0x4) as the case may be.

      Ignore:  Res = 0x0 - Ignore this field on receipt and follow the
         procedures specified for ANCP agents.

      *  Required additional information in the received message type.

      Nack:  Res = 0x1 - Result code indicating that no response is
         expected to message: none,
         if the response message other than in cases is of failure caused
         during the processing of same type as the message contents or of request.  As
         specified in Section 4.2 if the
         contained directive(s).

      AckAll:  Res = 0x2 - Result code indicating that a response to the message is requested in all cases.

      Success:  Res = 0x3 - Set in a response message by Generic
         Response message.

      *  Target: ANCP agent at the receiver of
         a request to indicate successful execution of all directives in peer that sent the corresponding original request message.

      Failure:  Res = 0x4 - Set in a response message by

      *  Action RECOMMENDED for the receiver receiving ANCP agent: If multiple
         instances of
         a request this error occur, the requestor SHOULD cause the
         adjacency for the partition to indicate either that there was be reset and renegotiated by
         sending an error adjacency message with pType = 0 and Code = RSTACK
         as described in Section 11.3 of [RFC3292].

         NOTE: This specification provides no way for the
         content NAS to do a
         complete audit of the request message or that one or more directives
         in current state stored on the corresponding request could not AN.  Hence
         renegotiation of the adjacency with pFlag = 2 (connection state
         retained at the AN) MAY be executed
         successfully.

   Code: attempted, but entails some risk of
         state mismatch.

   Code value: 19

      *  One-line description: Out of resources

      *  Where condition detected: ANCP protocol layer or control
         application

      *  Further description: (e.g., memory exhausted, etc.).  This field gives further information concerning Code
         value MUST be reported only by the result in
      a response message.  It is mostly used to pass an error code in AN, and indicates a
      failure response but can also
         condition that is probably unrelated to specific access lines
         (although it may be used related to give further the specific request).

      *  Required additional information in a success the response message or an event message.  In a request
      message, message: none,
         if the Code field response message is not used and MUST be set to zero.

      ANCP implementations MAY use any of the Code values same type as the request.  As
         specified in
      the IANA registry "Global Switch Management Protocol version 3
      (GSMPv3) Failure Response Message Name Space" Section 4.2 if they appear
      applicable.  In particular, the values:

      2  Invalid request response message (i.e., is a properly formed message which
         violates the protocol through its timing or direction of
         transmission)

      4  One or more of Generic
         Response message.

      *  Target: ANCP agent at the specified ports do not exist

      6  One or more of peer that sent the specified ports are down

      7  Invalid Partition ID

      19 Out of resources (e.g. memory exhausted, etc.)

      30 The limit on original request

      *  Action RECOMMENDED for the maximum number of point-to-multipoint
         connections that receiving ANCP agent: If the switch can support has been reached

      31 The limit on NAS
         receives this Code value from multiple requests for the maximum number of branches that same AN
         in a short interval, it SHOULD reduce the specified
         point-to-multipoint connection can support has been reached

      may unfortunately apply to ANCP usage, where "Port" is interpreted rate at which it
         sends requests in proportion to mean an access line or the rate at which requests are
         failing with Code = 19.  It MAY retry individual requests.  If
         only a Target as defined specific request is failing with Code = 19, the ANCP
         agent in Section 6.2.1.

      Instead of the value:

      3  The specified NAS MAY request is not implemented on this switch

      specified by [RFC3292], this specification defines a new the control application to
         decompose the request into simpler components if this is
         possible.

   Code value: 81

      *  One-line description: Request message type not implemented

      *  Where condition detected: ANCP agent

      *  Further description: This value MAY be sent could indicate a mismatch in protocol
         version or capability state.  It is also possible that support
         of a failure specific message is optional within some ANCP capability.

      *  Required additional information in the response from either message: none,
         if the AN or response message is of the NAS.  This specification also defines same type as the additional values:

      82 Transaction identifier out of sequence

      83 Malformed request.  As
         specified in Section 4.2 if the response message

      84 TLV or value not supported by negotiated capability set is a Generic
         Response message.

      *  Target: ANCP extensions defining new code values SHOULD use agent at the range 256
      (0x100) through 511 (0x1FF) peer that sent the original request

      *  Action RECOMMENDED for the receiving ANCP agent: If the
         receiver of this purpose.

      The range Code value expects that support of values from 256 to 4095 the message
         type concerned is reserved mandatory according to the capabilities
         negotiated for IETF use.

   Partition ID:  This field is a 8 bit number which signifies a
      partition on the AN.

      The AN and NAS may agree on session, it SHOULD cause the partition ID using one of adjacency for
         the
      following possible options:

      1 -  The partition ID may to be configured on the AN reset and learned renegotiated by sending an
         adjacency message with pType = 0 and Code = RSTACK as described
         in Section 11.3 of [RFC3292].

   Code value: 83

      *  One-line description: Malformed message

      *  Where condition detected: ANCP agent

      *  Further description: This could be the NAS result of corruption in
         transit, or an error in implementation at one end or the adjacency message;

      2 -  The partition ID may be statically configured on other.

      *  Required additional information in the response message: none,
         if the response message is of the NAS same type as
         part of configuring the neighbor information.

   Transaction ID:  24-bit field set by request.  As
         specified in Section 4.2 if the sender of a request message
      to associate a response message with is a Generic
         Response message.

      *  Target: ANCP agent at the peer that sent the original request message.
      Unless otherwise specified

      *  Action RECOMMENDED for a given message type, the
      Transaction ID in receiving ANCP agent: The request messages MUST
         SHOULD be set re-sent once to a value in eliminate the
      range (1, 2^24 - 1).  When used possibility of in-
         transit corruption.

   Code value: 84

      *  One-line description: Mandatory TLV missing

      *  Where condition detected: ANCP agent

      *  Further description: none.

      *  Required additional information in this manner, the Transaction ID
      sequencing response message: the
         response message MUST be maintained independently for contain a Status-Info message that
         encapsulates an instance of each ANCP
      adjacency missing mandatory TLV, where
         the length is set to zero and per message type.  Furthermore, it SHOULD be
      incremented linearly the value field is empty (i.e.,
         only the four-byte TLV header is present).

      *  Target: ANCP agent at the peer that sent the original request

      *  Action RECOMMENDED for each new the receiving ANCP agent: resend the
         message of with the given type,
      cycling back to 1 after running missing TLV(s), if possible.  Otherwise,
         report the full range.  Each Transaction
      ID sequence SHOULD be reinitialized error to a random non-zero value
      when the control application with an adjacency is negotiated.  For event messages, indication
         of the
      Transaction ID SHOULD be set missing information required to zero.

      Unless otherwise specified, construct the default behaviour for all missing
         TLV(s).

   Code value: 85

      *  One-line description: Invalid TLV contents

      *  Where condition detected: ANCP
      responses is that agent

      *  Further description: the value 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 Transaction ID MUST be
         erroneous TLVs copied from the corresponding request message.

   I flag and SubMessage Number:  An original request.

      *  Target: ANCP implementation SHOULD set agent at the
      I Flag and subMessage Number fields to 1 to signify no
      fragmentation.

   Length:  Length of peer that sent the original request

      *  Action RECOMMENDED for the receiving ANCP message including its header fields agent: correct the
         error and
      defined ANCP message body.

4.6.2.  The ANCP Message Body

   The detailed contents of resend the message payload portion of a given ANCP
   message may vary with request, if possible.  Otherwise, report
         the capability in error to the context control application with an indication of which it is
   being used.  However, the general format consists of zero
         erroneous information associated with the invalid TLV(s).

   Code value: 1280

      *  One-line description: One 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 6:

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

                       Figure 6: General TLV Format

   The fields of a TLV are defined as follows:

   Type:  The TLV Type is specified ports do not
         exist

      *  Where condition detected: control application

      *  Further description (if any): this may indicate a 16-bit unsigned value identifying configuration
         mismatch between the TLV
      type AN and nature of its contents.  An IANA registry has been
      established for ANCP TLV Type codes.

   Length:  The number of bytes of data the NAS or AAA.

      *  Required additional information in the Value field of response message: if the TLV,
      excluding any padding required to bring this TLV to
         request identified multiple access lines or the response is a 4-byte word
      boundary (see "Value" below).  If
         Generic Response message, then the response MUST contain a
         Status-Info TLV contains other TLVs, any
      padding in encapsulating TLV(s) containing the contained TLVs MUST be included in rejected
         line identifier(s).

      *  Target: control application at the value of
      Length.

         If peer that sent the TLV contains another TLV followed by other data, original
         request

      *  Action RECOMMENDED for the
         outer TLV will not be properly parsable unless Length is set as
         indicated; if receiving ANCP agent: indicate the interior padding is omitted from Length, as
         many bytes of data at
         error and forward the end of line identifiers to the outer TLV will be missed.
         If control
         application.

   ANCP extensions defining new code values SHOULD use the outer TLV contains another TLV as its final field it
         requires no padding range 256
   (0x100) through 511 (0x1FF) for this purpose.  The range of its own (since values
   from 256 to 4095 is reserved for allocation by IETF consensus.

3.6.1.5.  Partition ID

   The Partition ID field is a 8 bit number which signifies a partition
   on the contained TLV
         including padding ends AN.  The AN and NAS MAY agree on a 4-byte boundary).  In this case the
         issue is partition ID using one of consistency rather than parsability, since
   the
         padding of that final TLV could following possible options:

   o  The partition ID MAY be omitted from Length without
         loss of data.

      Depending configured on the specification of the TLV, the value of Length may
      be zero, a constant for all instances of the TLV, or a varying
      quantity.

   Value  The actual data carried AN and learned by the TLV, if any.  The value field
      NAS in each TLV MUST the adjacency message; or

   o  The partition ID MAY be padded with zeroes statically configured on the NAS as required to align with a
      4-byte word boundary. part
      of configuring the neighbor information.

3.6.1.6.  Transaction ID

   The Value Transaction ID is a 24-bit field set by the sender of a TLV may include fixed
      fields and/or other TLVs.

   Unless otherwise specified, TLVs MAY be added request
   message to associate a response message in any
   order.  If with the recipient of original request
   message.  Unless otherwise specified for a given message does not understand a
   particular TLV, it type, the
   Transaction ID in request messages MUST silently ignore it.

   A number of TLVs are specified be set to a value in the remainder of
   range (1, 2^24 - 1).  When used in this document.

5.  ANCP Capabilities For Digital Subscriber Lines (DSL)

5.1.   Overview

   DSL is a widely deployed access technology manner, the Transaction ID
   sequencing MUST be maintained independently for Broadband Access each message type
   within each ANCP adjacency.  Furthermore, it SHOULD be incremented
   linearly for
   Next Generation Networks.  Specifications such as [TR_059], [TR_058],
   and [TR_092] describe possible architectures each new message of the given type, cycling back to 1
   after running the full range.  For event messages, the Transaction ID
   SHOULD be set to zero.

   Unless otherwise specified, the default behaviour for these access
   networks.  The scope all ANCP
   responses is that the value of the Transaction ID MUST be copied from
   the corresponding request message.

3.6.1.7.  I flag and SubMessage Number

   In GSMPv3 these specifications includes provide a mechanism for message fragmentation.
   Because ANCP uses TCP transport, this mechanism is unnecessary.  An
   ANCP agent SHOULD set the delivery of
   voice, video, I Flag and data services.

   When deploying value-added services across DSL access networks,
   special attention is required subMessage Number fields to assure quality of service and
   service control, which implies a tighter coordination between network
   elements in the broadband access network without burdening the OSS
   layer. 1 to
   signify "no fragmentation".

3.6.1.8.  Length

   This document specifies basic ANCP capabilities for use specifically
   in controlling Access Nodes serving DSL access (Tech Type = 0x05).
   The same ANs could field MUST be serving other access technologies (e.g.  Metro-
   Ethernet, Passive Optical Networking, WiMax), in which case the AN
   will also have set to support the corresponding other-technology-specific
   capabilities.  These additional capabilities are not specified here,
   but may be specified in other documents.

   The DSL capabilities specified in this section are:

   DSL Topology Discovery:  Dynamic discovery length of access topology and DSL
      line attributes by the NAS, to support tight QOS control ANCP message in the
      access network.

   DSL Line Configuration:  Pushing subscriber bytes,
   including its header fields and service data
      retrieved by the NAS from an OSS system (e.g., RADIUS server) to message body but excluding the Access Nodes, to simplify OSS infrastructure for service
      management.

   DSL Line Testing:  NAS controlled, on-demand access- line test
      capability (rudimentary end-to-end OAM).

5.1.1.  ATM-Specific Considerations

   Topology discovery and line configuration involve four-
   byte encapsulating header defined in Section 3.2.

3.6.2.  The ANCP Message Body

   The detailed contents of the DSL line
   attributes.  For ATM based access networks, message payload portion of a given ANCP
   message can vary with the DSL line on capability in the DSLAM context of which it is identified by
   being used.  However, the port and PVP/PVC corresponding to general format consists of zero or more
   fixed fields, followed by a variable amount of data in the
   subscriber. form of
   Type-Length-Value (TLV) data structures.

   The general format of a TLV is shown in 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type (IANA registered)    |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                            Value                              ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 7: General TLV Format

   The DSLAMs fields of a TLV are connected to the NAS via an ATM access
   aggregation network.  Since, the DSLAM (Access Node) defined as follows:

   Type:  The TLV Type is not directly
   connected to the NAS, the NAS needs a mechanism to learn 16-bit unsigned value identifying the DSL line
   identifier (more generally referred to as "access loop circuit ID")
   corresponding to a subscriber.  The access loop circuit ID TLV
      type and nature of its contents.  An IANA registry has no
   local significance on the NAS.  The ANCP messages been
      established for topology
   discovery and line configuration carry opaque Access-Loop-Circuit-ID
   values which have only local significance on the DSLAMs. ANCP TLV Type codes.

   Length:  The access loop circuit identifier can be carried as a UTF-8-encoded
   string number of bytes of data in the ANCP messages.  This allows ANCP to be decoupled from
   the specifics Value field of the underlying access technology being controlled.
   On the other hand, TLV,
      excluding any padding required to bring this requires TLV to a NAS mechanism by which each such
   identifier can 4-byte word
      boundary (see "Value" below).  If a TLV contains other TLVs, any
      padding in the contained TLVs MUST be correlated to included in the context value of an aggregation-
   network-facing IP interface (corresponding to the subscriber)
      Length.  Depending on the
   NAS.  This will typically require local configuration of such IP
   interfaces, or of the underlying ATM interfaces.

5.1.2.  Ethernet-Specific Considerations

   One possible way of approaching the use specification of Ethernet technology in the
   access aggregation network is to recreate TLV, the equivalent value of Virtual
   Paths (VPs) and Virtual Circuits (VCs) by using stacked Virtual LAN
   tags.  As an example, one
      Length can use an "outer" VLAN to create be zero, a form constant for all instances of
   "virtual path" between a given DSLAM and the TLV, or a given NAS, and then use
   "inner" VLAN tags
      varying quantity.

   Value  The actual data carried by the TLV, if any.  The value field
      in each TLV MUST be padded with zeroes as required to create align with a form
      4-byte word boundary.  The Value field of "virtual circuit" on a per DSL
   line basis.  In this case, VLAN tags conveyed TLV MAY include fixed
      fields and/or other TLVs.

   Unless otherwise specified, TLVs MAY be added to a message in topology discovery
   and line configuration messages will allow unique identification of any
   order.  If the DSL line in recipient of a straightforward manner, assuming the VLAN tags are message does not translated understand a
   particular TLV, it MUST silently ignore it.

   A number of TLVs are specified in some way by the aggregation network, remainder of this document.

3.7.  General Principles for the Design of ANCP Messages

   The GSMPv3 protocol [RFC3292] allows for two messaging constructs to
   support request/response interaction:

   a.  The same message type is used for both the request message and
       the response message.  The Result and Code field settings are unique
   across physical ports.

   However, some carriers do not wish
       used to differentiate between request and response messages.

   b.  The request and response messages use this "connection oriented"
   approach.  Therefore, an alternative model is to bridge sessions from
   multiple subscribers behind a DSLAM to a single VLAN in the
   aggregation network.  This two different message
       types.

   The first approach is illustrated by the N:1 model.  In this model, or protocol specifications in
   Section 8.4, the case where user traffic second by specifications in Section 6.4.  The
   purpose of this section is sent untagged, the Access Node needs to insert the exact identity of provide more details about the DSL line second
   approach in order to allow the topology
   discovery and line configuration messages, and then have a mechanism
   by which use of this can be correlated to messaging construct for
   the context development of an aggregation-
   network-facing IP interface (for additional ANCP extensions.

   As Section 3.6 indicated, all ANCP messages other than adjacency
   messages share a common header format.  When the subscriber) on response message
   type is different from that of the NAS.  This
   can either be based on local configuration on request, the NAS, or on specification of the fact
   that a DSLAM (Access Node)
   request message will typically inserts indicate that the access loop circuit
   ID in subscriber signaling messages relayed Result field is set
   to Ignore (0x0) and provide procedures indicating explicitly when the NAS (i.e.  DHCP or
   PPPoE discovery messages).

   Section 5.2.3.3 defines TLVs
   receiver should generate a response and what message type it should
   use.

   The Transaction ID field is used to represent distinguish between multiple
   request messages of the "access loop circuit
   ID".

5.2. same type and to associate a response message
   to a request.  Specifications of ANCP Based DSL Topology Discovery

5.2.1.   Goals

   [TR_059] discusses various queuing/scheduling mechanisms messages for applications not
   requiring response correlation SHOULD indicate that the Transaction
   ID MUST be set to avoid
   congestion zero in the access network while dealing with multiple flows
   with distinct QoS requirements.  Such mechanisms require requests.  Applications that require
   response correlation SHOULD refer to the NAS
   gains knowledge about the topology Transaction ID behaviour
   described in Section 3.6.1.

   The specification for a response message SHOULD indicate in all cases
   that value of the access network, the various
   links being used and their respective net data rates.  Some Transaction Identifier MUST be set to that of the
   information required is somewhat dynamic in nature (e.g.  DSL sync
   rate, and therefore also
   corresponding request message.  This allows the net data rate), hence cannot come from requester to
   establish whether or not correlation is needed (by setting a
   provisioning and/or inventory management OSS system.  Some of non-zero
   or zero value for the
   information varies less frequently (e.g. capacity of Transaction ID).

4.  Generally Useful ANCP Messages and TLVs

   This section defines two messages and a DSLAM uplink),
   but nevertheless needs to number of TLVs that could be kept strictly
   useful in sync between multiple capabilities.  In some cases the actual
   capacity of content is under-
   specified, with the uplink and intention that particular capabilities spell out
   the image remaining details.

4.1.  Provisioning Message

   The Provisioning message is sent by the NAS has of it.

   The following section describes ANCP messages that allow to the Access
   Node (e.g., DSLAM) AN to communicate access network topology provision
   information
   and any corresponding updates to of global scope (i.e., not associated with specific
   access lines) on the NAS.

   Some AN.  The Provisioning message has the format
   shown in Figure 8.  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 8: Format of the parameters that can Provisioning Message

   The message header field settings given below are REQUIRED in the
   Provisioning message.  The remaining message header fields MUST be communicated from the DSLAM
   set as specified in Section 3.6.1.  Which TLVs to carry in the
   NAS include DSL line state, actual upstream and downstream net data
   rates of a synchronized DSL link, maximum attainable upstream and
   downstream net data rates, interleaving delay etc.  Topology
   discovery
   Provisioning message is specifically important when specified as part of the net data rate specification of the DSL
   line changes over time.
   capabilities that use that message.  The DSL net data rate may Provisioning message MAY be different every
   time the DSL modem is turned on.  Additionally, during the time the
   DSL modem is active,
   used to carry data rate changes can occur due relating to environmental
   conditions (the DSL line more than one capability at once,
   assuming that the capabilities concerned can get "out of sync" co-exist and can retrain have all
   been negotiated during adjacency establishment.

   Message Type:  MUST be set to 93.

   Result:  MUST be set to 0x0 (Ignore).

   Code:  MUST be set to zero.

   Transaction ID:  MUST be populated with a
   lower value).

5.2.2.  Message Flow

   To provide expected service levels, non-zero value chosen in
      the NAS needs to learn manner described in Section 3.6.1.6.

   If the
   initial attributes of AN can process the DSL line before message successfully and accept all the subscriber can log
   provisioning directives contained in
   and access it, the services provisioned 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 subscription.  When appropriate response to a DSL
   line initially comes up or resynchronizes
   message defined in an extension to ANCP, instead of a different rate, more specific
   response message.  As a general guideline, specification of the
   DSLAM generates and transmits an ANCP Port UP Event
   Generic Response message as a response is appropriate where no data
   needs to be returned to the
   NAS.  The extension field peer other than a result (success or
   failure), plus, in the message carries case of a failure, a code indicating the TLVs containing
   DSL line specific parameters.  Upon loss
   reason for failure and a limited amount of signal diagnostic data.
   Depending on the DSL line,
   an ANCP Port DOWN message is generated by particular use case, the DSLAM and Generic Response message
   MAY be sent to the
   NAS.  Figure 7 summarizes by either the interaction.

   1.  NAS ------------------------ Access -----  Home ----- Subscriber
                                     Node        Gateway

            <----- Port UP(Event Message)  <----- DSL
                 (default line parameters)       Signal

   2.  NAS ------------------------ Access -----  Home ----- Subscriber
                                     Node        Gateway

            <----- Port UP (Event Message) <----- DSL
                  (updated line parameters)     Resynch

   3. NAS ------------------------ Access -----  Home ----- Subscriber
                                     Node        Gateway

           <--- Port DOWN (Event Message)  <---- DSL
                                             Loss of Signal

          Figure 7: ANCP Message Flow For DSL Topology Discovery

   The Event message with Port UP message type (80) is used for
   conveying DSL line attributes to the NAS.  This message with relevant
   extensions is defined in or the next section.

5.2.3.  Specification AN.

   Support of the Generic Response message, both as sender and as
   receiver, is REQUIRED for all ANCP DSL Topology Discovery Capability

5.2.3.1.  Protocol Requirements agents, regardless of what
   capabilities they support.

   The DSL topology discovery capability is assigned capability type
   0x01.  No capability data is associated with this capability.
   Implementations AN or NAS MAY send a Generic Response message indicating a
   failure condition independently of a specific request before closing
   the DSL topology discovery capability MUST support
   the following ANCP protocol elements:

   o  ANCP Port UP and Port DOWN Event messages, which are based on the
      GSMPv3 [RFC3292] messages adjacency as a consequence of that failure condition.  In this
   case, the same name but include capability-
      specific modifications and extensions (Section 5.2.3.2).

   o  The procedures associated with these messages and their contents
      (Section 5.2.3.2.1).

   o  Access-Loop-Circuit-ID TLV;

   o  Access-Loop-Remote-Id TLV;

   o  Access-Aggregation-Circuit-ID-ASCII TLV;
   o  Access-Aggregation-Circuit-ID-Binary TLV;

   o  DSL-Line-Attributes TLV;

   o  DSL-Type TLV;

   o  Actual-Net-Data-Upstream TLV;

   o  Actual-Net-Data-Rate-Downstream TLV;

   o  Minimum-Net-Data-Rate-Upstream TLV;

   o  Minimum-Net-Data-Rate-Downstream TLV;

   o  Attainable-Net-Data-Rate-Upstream TLV;

   o  Attainable-Net-Data-Rate-Downstream TLV;

   o  Maximum-Net-Data-Rate-Upstream TLV;

   o  Maximum-Net-Data-Rate-Downstream TLV;

   o  Minimum-Net-Low-Power-Data-Rate-Upstream TLV;

   o  Minimum-Net-Low-Power-Data-Rate-Downstream TLV;

   o  Maximum-Interleaving-Delay-Upstream TLV;

   o  Maximum-Interleaving-Delay-Downstream TLV;

   o  Actual-Interleaving-Delay-Upstream TLV;

   o  Actual-Interleaving-Delay-Downstream TLV;

   o  DSL-line-state TLV;

   o  Access Loop Encapsulation TLV.

   The TLVs listed above are specified sender MUST set the Transaction ID field in Section 5.2.3.3.

5.2.3.2.  ANCP Port UP the header and Port DOWN Event
   the Message Descriptions Type field within the Status-Info TLV to zeroes.  The ANCP Port UP and Port DOWN Event messages are derived from
   receiver MAY record the
   GSMPv3 Event message shown information contained in Section 9 of [RFC3292]. the Status-Info TLV
   for management use.

   The modified format used for DSL topology discovery of the Generic Response message is shown in Figure 8. 9
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           TCP/IP Encapsulating Header (Section 4.2) 3.2)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                ANCP General Message Header                    |
   +                      (Section 4.4) 3.6.1)                            +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Port                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Port Session Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Event Sequence Number                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Access line identifying TLV(s)                 |
   +                             Label                (copied from original request)                 +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |x|x|x|x|x|x|x|x| Message Type  |   Tech Type   | Block Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     # of TLVs                 | Extension Block length (bytes)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                            TLVs                               ~
   ~                                                               ~
   |
   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 8: Format Of the ANCP Port UP  and Port DOWN Event Messages
                        For DSL Topology Discovery

   See Section 4.6 for                    Status-Info TLV                            |
   ~                    (Section 6.2.3)                            ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

            Figure 9: Structure of the ANCP general message header.
   The Generic Response Message Type field MUST be set to 80 for Port UP, 81 for Port
   DOWN.  The 12 bit Code field MUST be set to 0.  The 4 bit Result
   field MUST be set to 0 (signifying Ignore).

   This document specifies the following header fields.  The 24-bit Transaction
   Identifier field MUST be set to 0.  Other remaining
   fields in the ANCP general message header MUST be set as described in Section 4.6.

   The Port, Port Session Number, and Event Sequence Number fields are
   not used by the DSL Topology Discovery capability.  The Label field
   (including the Stacked Label Indicator and the unused flags at the
   start of the Label field), is also unused, and MUST be treated as an
   unused fixed 8-byte field.  The handling of unused/reserved fields is
   described specified in
   Section 4.4.

   The remaining message fields are described as follows:

   Extension Flags:  The flag bits denoted by 'x' are currently
      unspecified and reserved. 3.6.1.

   Message Type:  Message Type has the same value as in the general
      header (i.e., 80 or 81).

   Tech Type:  MUST be set to 0x05 (DSL).

   Block Length:  unused, see Section 4.4.  This field was defined in
      early implementations, but limits what follows to 255 bytes, which
      is not sufficient.

   # of TLVs:  the number of TLVs that follow, not counting TLVs
      encapsulated within other TLVs.

   Extension Block Length:  the total length of the TLVs carried in the
      extension block in bytes, including any padding within individual
      TLVs.

   TLVs:  two 91.

   Result:  MUST be set to 0x3 (Success) or more TLVs 0x4 (Failure).

   Code:  MUST be set to identify a DSL line and define its
      characteristics.

5.2.3.2.1.  Procedures

   The GSMP Event zero for success or an appropriate non-zero
      value for failure.

   Transaction ID:  MUST be copied from the message with Port UP to which this
      message type (80) is used for
   conveying DSL line attributes to a response.

   If the NAS.  The message SHOULD be
   generated when original request applied to a specific access line first comes UP, or any of the attributes set of
   lines, the
   line change e.g. TLVs identifying the line re-trains to a different rate or one or
   more of line(s) and possibly the configured line attributes are administratively modified.
   Also, when user MUST be
   copied into the ANCP session first comes up, Generic Response message at the DSLAM SHOULD transmit top level.

   The Status-Info TLV MAY be present in a Port UP message success response, to the NAS provide
   a warning as defined for each line that is up.  When a DSL
   line goes down (idle or silent), the DSLAM SHOULD transmit an Event
   message with Port DOWN specific request message type (81) to the NAS. type.  It is
   recommended that the DSLAMs use MUST be
   present in a dampening mechanism per DSL line to
   control the rate failure response.  See Section 4.5 for a detailed
   description of state changes per DSL line, communicated to the
   NAS.

   If a Port UP Status-Info TLV.  The actual contents will depend
   on the request message type this message with a Result field set to 0 is received by the
   NAS responding to and the NAS is able to process
   value of the Code field.

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

4.3.  Target TLV

   Type:  0x1000 to 0x1020 depending on the Port UP.  If
   the Port UP message received cannot be processed correctly by the NAS
   (e.g. specific content.  Only
      0x1000 has been assigned in this specification (see below).
      Support of any specific variant of the message Target TLV is malformed) OPTIONAL
      unless the NAS MAY respond with an ANCP
   Generic Response message (Section 6.1.3) containing the reason 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 failure.

   In the case specific object type.

   Value:  Target information as defined for each object type.  The
      Value field MAY consist of bonded copper loops sub-TLVs.

   TLV Type 0x1000 is assigned to a variant of the customer premise (as per
   the DSL multi-pair bonding described by [G.988.1] Target TLV
   representing a single access line and [G.988.2]), encapsulating one or more sub-
   TLVs identifying the
   DSLAM MUST report target.  Figure 10 is an example illustrating
   the aggregate net data rate and other attributes TLV format for the DSL bonded circuit (represented as a single logical port) to
   the NAS in a Port UP message.  Any change in the aggregate net data
   rate 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 10: Example of the DSL bonded circuit (due Target TLV For Single Access Line

4.4.   Command TLV

   Type:  0x0011

   Description:  The Command TLV (0x0011) is intended to be a change in net data rate or
   state general
      means of individual constituent DSL lines) MUST be reported by the
   DSLAM to the NAS encapsulating one or more command directives in a Port UP TLV
      oriented message.  The DSLAM MUST also report
   the aggregate state semantics of the DSL bonded circuit to command can be specified
      for each message type using it.  I.e., the NAS via Port UP
   and Port DOWN messages.

   The definition specification of TLVs in each
      message type that can carry the next section contains some additional
   procedural information.

5.2.3.3.  TLVs For DSL Topology Discovery

   The following TLVs are currently defined for DSL Topology Discovery,
   but may be reused for other capabilities.

5.2.3.3.1.  Access-Loop-Circuit-ID Command TLV

   Name:  Access-Loop-Circuit-ID

   Type:  0x0001

   Description:  a locally administered human-readable string generated
      by or configured on is expected to define
      the Access Node, identifying meaning of the corresponding
      access loop logical port.  The access loop circuit ID has local
      significance at content of the Access Node.  The exact usage on payload, although re-use of
      specifications is, of course, permissible when appropriate.
      Support of any specific variant of the NAS Command TLV is
      beyond OPTIONAL
      unless the scope of this document.  The format used for local loop
      identification in ANCP messages MUST be identical to what is used
      by the Access Nodes in subscriber signaling messages when agent claims support for a capability that
      requires its use.

   Length:  Variable, depending on the
      Access Nodes act as signaling relay agents specific contents.

   Value:  Command information as outlined in
      [RFC3046] and [TR_101]. defined for each message type.  The
      field MAY include sub-TLVs.  The local loop can contents of this TLV MUST be ATM based
      specified as one "command" or Ethernet based.  Section 3.9 alternatively a sequence of
      [TR_101] recommends default formats for either case, one or
      more "commands", each beginning with the
      intention that the Access Node automatically generates the
      identifier for a given access line using one-byte Command Code and
      possibly including other data following the default format unless
      an identifier Command Code.  An IANA
      registry has been configured by established for Command Code values.  This
      document reserves the operator.  The
      recommended default format begins with a locally-configured Access
      Node identifier.  For Command Code value 0 as an ATM based local loop the remainder of initial entry in
      the
      string consists of slot/port and VPI/VCI information corresponding registry.

4.5.  Status-Info TLV

   Name:  Status-Info

   Type:  0x0106

   Description:  The Status-Info-TLV is intended to the subscriber's DSL connection.  In ABNF notation [RFC5234],
      the recommended syntax is:

         Access-Node-Identifier SP "atm" SP slot "/" port ":" vpi "."
         vci

      where the meanings of the terms should be obvious from their
      names.

      For a local loop which general
      container for warning or error diagnostics relating to commands
      and/or requests.  It is Ethernet based (and tagged), the
      remainder of the string consists of slot/port and incoming VLAN
      tag (if any) describing a supplement to the access line appearance on Code field in the Access
      Node. ANCP
      general header.  The syntax of specifications for individual message types
      MAY indicate the recommended default format in ABNF
      notation is:

         Access-Node-Identifier SP "eth" SP slot "/" port [":" vlan-id]

      This is a mandatory TLV.

   Length:  up to 63 bytes

   Value:  ASCII string

5.2.3.3.2.  Access-Loop-Remote-Id use of this TLV

   Name:  Access-Loop-Remote-Id

   Type:  0x0002

   Description:  This is an optional TLV.  This contains as part of responses,
      particularly for failures.  As mentioned above, the Generic
      Response message will usually include an operator-
      configured string that uniquely identifies instance of the user on Status-
      Info TLV.  Support of the
      associated access line, Status-Info TLV, both as described in Section 3.9.2 sender and as
      receiver, is REQUIRED for all ANCP agents, regardless of [TR_101].
      The exact usage what
      capabilities they support.

   Length:  Variable, depending on the NAS is out specific contents.

   Value:  The following fixed fields.  In addition, sub-TLVs MAY be
      appended to provide further diagnostic information.

      Reserved (one byte):  see Section 3.4 for handling of scope reserved
         fields.

      Msg Type:  Message Type of this document.  It
      is desirable that the format used request for which this TLV is
         providing diagnostics.

      Error Message Length:  Number of bytes in the field error message,
         excluding padding.  This MAY be similar to what zero if no error message is used by the Access Nodes in subscriber signaling messages when
         provided.

      Error Message:  Human-readable string providing information about
         the Access Nodes act as signaling relay agents warning or error condition.  Padded with zeroes as outlined in
      [RFC3046] and [TR_101].

   Length:  up
         necessary to extend to 63 bytes

   Value:  ASCII string

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

   Name:  Access-Aggregation-Circuit-ID-Binary

   Type:  0x0006

   Description:  For ethernet access aggregation, where a per-subscriber
      (stacked) VLAN can be applied (1:1 model defined in [TR_101]), the
      VLAN stack four-byte word boundary.

      Section 3.6.1.4 provides a convenient way recommendations for what TLVs to uniquely identify add in
      the DSL
      line. Status-Info TLV for particular values of the message header
      Code field.

   Figure 11 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 11: The outer VLAN Status-Info TLV

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

   DSL is equivalent to virtual path between a
      DSLAM 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 NAS delivery of
   voice, video, and inner VLAN is equivalent to a virtual
      circuit on a per DSL line basis.  In this scenario, any subscriber data received by the Access Node and transmitted out the uplink to
      the aggregation network will be tagged with the VLAN stack
      assigned by the Access Node. services.

   The Access-Aggregation-Circuit-ID-Binary is illustrated next three sections of this document specify basic ANCP
   capabilities for use specifically in
      Figure 9 (below).  This TLV carries the VLAN tags assigned by the controlling Access Nodes serving
   DSL access node in the ANCP messages. (Tech Type = 0x05).  The VLAN tags can uniquely
      identify the DSL line being referred to same ANs could be serving other
   access technologies (e.g.  Metro-Ethernet, Passive Optical
   Networking, WiMax), in which case the ANCP messages,
      assuming AN will also have to support
   the VLAN tags corresponding other-technology-specific capabilities.  Those
   additional capabilities are not in any way translated in outside the
      aggregation network and are unique across physical ports.  Each 32
      bit unsigned integer contains scope of the present
   document.

5.1.  DSL Access Line Identification

   Most ANCP messages involve actions relating to a 12 bit VLAN identifier (which specific access
   line.  Thus it is
      part 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 VLAN tag TLVs defined by IEEE 802.1Q).

      Also, in case this section:

   o  identification of an ATM aggregation network, where access line by its logical appearance on the DSLAM is
      directly connected to
      user side of the NAS (without Access Node;

   o  identification of an intermediate ATM
      switch), the two values can contain VPI and VCI access line by its logical appearance on the DSLAM
      uplink (and correspond uniquely
      NAS side of the Access Node; and

   o  identification down to the DSL user or host level as a supplement to
      access line on identification in one of the DSLAM).

      This TLV is optional.

   Length:  8 bytes

   Value: other two 32 bit unsigned integers

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    TLV Type = 0x0006          |        Length = 8             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Inner VLAN tag or VCI                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Outer VLAN tag or VPI                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 9: forms.

   All of these identifiers originate with the AN control application,
   during the process of DSL topology discovery.  The Access-Aggregation-Circuit-ID-Binary TLV

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

   Name:  Access-Aggregation-Circuit-ID-ASCII

   Type:  0x0003

   Description:  This field contains information pertaining control
   application chooses which identifiers to an uplink use and the values to place
   into them on a line-by-line basis, based on AN configuration and
   deployment considerations.

   Aside from its use in ANCP signalling, access line identification is
   also used in DHCP transactions involving hosts served by DSL.  Either
   the Access Node.  For Ethernet AN or the NAS can serve as a DHCP relay node.  [TR-101] requires
   the AN or NAS in this role to add access aggregation, assuming line identification in
   Option 82 (Information) to each DHCP request it forwards to the
      Access Node assigns VLAN tags (1:1 model), typical ABNF format DHCP
   server.  It is desirable for efficiency that the string is:

         Access-Node-Identifier SP "eth" SP slot "/" port [":" inner-
         vlan-id] [":" outer-vlan-id]

      The slot/port corresponds to identification used
   in this signalling should be the ethernet uplink on same as the Access
      Node towards identification used in
   ANCP messages.

   From the NAS.

      For an ATM aggregation network, point of view of ANCP itself, the typical format for identifiers are opaque.
   From the string
      is:

         Access-Node-Identifier SP "atm" SP slot "/" port ":" vpi "."
         vci

      This TLV allows point of view of the NAS to associate AN control application, the information contained 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 ANCP messages to
   ASCII form of the DSL NAS-side access line identifier will be similar.

   Access line identification by logical appearance on the user side of
   the Access Node.

      If Node will always identify a DSL loop uniquely.
   Identification by the logical appearance on the NAS side of the
   Access Node inserts this string in is unique only if there is a one-to-one mapping between
   the ANCP messages, when
      referring to local loop characteristics (e.g.  DSL line 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
      a DSLAM), then it should be able to map 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 contained
      in allowing
   the string uniquely NAS to build up a picture of the local loop (e.g.  DSL line).

      On aggregation network topology.

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

      Sections 3.8 and 3.9 of [TR-101] are contradictory on this string can be used point.
      It is assumed here that Section 3.9 is meant to derive an aggregation-network-facing construct (e.g. be authoritative.

   The user-level identification takes the form of an IP
      interface) corresponding to administered
   string which again is opaque at the local loop (e.g.  DSL line). ANCP level.

   The
      association could be based on local configuration on NAS control application will use the NAS.

      The Access Node can also convey to identifying information it
   receives from the NAS AN directly for some purposes.  For examples, see
   the characteristics
      (e.g., bandwidth) introductory part of Section 3.9 of [TR-101].  For other
   purposes, the uplink on NAS will build a mapping between the Access Node.  This TLV then
      serves unique access line
   identification provided by the purpose AN, the additional identification of uniquely identifying
   the uplink whose
      characteristics are being defined. 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 version section provides a normative specification of the present
      document does not specify the TLVs needed that ANCP
   provides to convey carry the uplink
      characteristics, in types of identification just described.  The
   Access-Loop-Circuit-ID TLV identifies an access line by its logical
   appearance on the same way that user side of the DSL-Line-Attributes Access Node.  Two alternatives,
   the Access-Aggregation-Circuit-ID-ASCII TLV and the TLVs encapsulated within it convey the characteristics of
      the subscriber Access-
   Aggregation-Circuit-ID-Binary TLV, identify an access line.

      This TLV is optional.

   Length:  up to 63 bytes

   Value:  ASCII string

5.2.3.3.5.  DSL-Line-Attributes TLV (Mandatory)
   Name:  DSL-Line-Attributes

   Type:  0x0004

   Description:  This is a mandatory TLV providing attribute values for
      a DSL line serving a subscriber.

   Length:  variable (up to 1024 bytes)

   Value:  one or more encapsulated TLVs corresponding to DSL line
      attributes.  The DSL-Line-Attributes TLV MUST contain by its
   logical appearance on the
      mandatory TLVs described below when it is present in a Port UP
      message.  It MAY contain NAS side of the optional TLVs described below when it
      is present in Access Node.  It is
   unlikely that a Port UP message.

      When given AN uses both of these TLVs, either for the DSL-Line-Attributes same
   line or for different lines, since they carry equivalent information.
   Finally, the Access-Loop-Remote-Id TLV is present contains an operator-
   configured string that uniquely identifies the user on the associated
   access line, as described in a Port DOWN message
      it SHOULD NOT include any TLVs other than DSL-Type Sections 3.9.1 and DSL-Line-
      State.

5.2.3.3.6.  TLVs Delivering Line Attributes

   The TLVs which follow convey DSL line attributes.  They 3.9.2 of [TR-101].

   As normative requirements on ANCP agents conforming to this section:

   o  ANCP agents MUST be
   encapsulated within able to build and send the DSL-Line-Attributes Access-Loop-
      Circuit-ID TLV, the Access-Loop-Remote-Id TLV, and either the
      Access-Aggregation-Circuit-ID-ASCII TLV when they are carried
   in a Port UP or Port DOWN message.

5.2.3.3.6.1.  DSL-Type TLV (Mandatory)

   Name:  DSL-Type

   Type:  0x0091

   Description:  Indicates the type of transmission system in use.  This
      is a mandatory TLV.

   Length:  4 bytes

   Value:  32 bit unsigned integer

         ADSL1 = 1

         ADSL2 = 2

         ADSL2+ = 3

         VDSL1 = 4

         VDSL2 = 5
         SDSL = 6

         UNKNOWN = 7

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

   Name:  Actual-Net-Data-Rate-Upstream

   Type:  0x0081

   Description:  Actual upstream net data rate on a DSL line.  This is a
      mandatory TLV.

   Length:  4 bytes

   Value:  Rate in Kbits/s as a 32 bit unsigned integer

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

   Name:  Actual-Net-Data-Rate-Downstream

   Type:  0x0082

   Description:  Actual downstream net data rate on a DSL line.  This is
      a mandatory TLV.

   Length:  4 bytes

   Value:  Rate in Kbits/s as a 32 bit unsigned integer

5.2.3.3.6.4.  Minimum-Net-Data-Rate-Upstream Access-Aggregation-
      Circuit-ID-Binary TLV

   Name:  Minimum-Net-Data-Rate-Upstream

   Type:  0x0083

   Description:  Minimum upstream net data rate desired by (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 operator.
      This relevant information, and pass it to the control application.

   o  If the Access-Loop-Remote-Id TLV is an optional TLV.

   Length:  4 bytes

   Value:  Rate present in Kbits/s as a 32 bit unsigned integer

5.2.3.3.6.5.  Minimum-Net-Data-Rate-Downstream TLV
   Name:  Minimum-Net-Data-Rate-Downstream

   Type:  0x0084

   Description:  Minimum downstream net data rate desired message, it MUST
      be accompanied by the
      operator.  This is an optional TLV.

   Length:  4 bytes

   Value:  Rate in Kbits/s as a 32 bit unsigned integer

5.2.3.3.6.6.  Attainable-Net-Data-Rate-Upstream Access-Loop-Circuit-ID TLV

   Name:  Attainable-Net-Data-Rate-Upstream

   Type:  0x0085

   Description:  Maximum net upstream rate that can be attained on the
      DSL line.  This is and/or an optional TLV.

   Length:  4 bytes

   Value:  Rate in Kbits/s as a 32 bit unsigned integer

5.2.3.3.6.7.  Attainable-Net-Data-Rate-Downstream Access-
      Aggregation-Circuit-ID-xxx TLV

   Name:  Attainable-Net-Data-Rate-Downstream

   Type:  0x0086

   Description:  Maximum net downstream rate that can be attained with two VLAN identifiers.

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

   o  If the Access-Aggregation-Circuit-ID-xxx TLV is an optional TLV.

   Length:  4 bytes

   Value:  Rate present in Kbits/s as a 32 bit unsigned integer

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

   Name:  Maximum-Net-Data-Rate-Upstream

   Type:  0x0087

   Description:  Maximum net upstream data rate desired
      message with just one VLAN identifier, it MUST be accompanied by the operator.
      This is
      an optional Access-Loop-Circuit-ID TLV.

   Length:  4 bytes

   Value:  Rate in Kbits/s as a 32 bit unsigned integer

5.2.3.3.6.9.  Maximum-Net-Data-Rate-Downstream

5.1.2.1.  Access-Loop-Circuit-ID TLV

   Name:  Maximum-Net-Data-Rate-Downstream

   Type:  0x0088  0x0001

   Description:  Maximum net downstream data rate desired  a locally administered human-readable string generated
      by or configured on the
      operator.  This is an optional TLV. Access Node, identifying the corresponding
      access loop logical port on the user side of the Access Node.

   Length:  4  up to 63 bytes

   Value:  Rate in Kbits/s as a 32 bit unsigned integer

5.2.3.3.6.10.  Minimum-Net-Low-Power-Data-Rate-Upstream  ASCII string

5.1.2.2.  Access-Loop-Remote-Id TLV

   Name:  Minimum-Net-Low-Power-Data-Rate-Upstream

   Type:  0x0089  0x0002

   Description:  Minimum net upstream data rate desired by  an operator-configured string that uniquely identifies
      the operator user on the associated access line, as described in low power state.  This is an optional TLV. Sections
      3.9.1 and 3.9.2 of [TR-101].

   Length:  4  up to 63 bytes

   Value:  Rate in Kbits/s as a 32 bit unsigned integer

5.2.3.3.6.11.  Minimum-Net-Low-Power-Data-Rate-Downstream  ASCII string

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

   Name:  Minimum-Net-Low-Power-Data-Rate-Downstream

   Type:  0x008A  0x0006
   Description:  Minimum net downstream data rate desired  This TLV identifies or partially identifies a specific
      access line by means of its logical circuit identifier on the
      operator in low power state.  This is an optional TLV.

   Length:  4 bytes

   Value:  Rate in Kbits/s as NAS
      side of the Access Node.

      For Ethernet access aggregation, where a 32 bit unsigned integer

5.2.3.3.6.12.  Maximum-Interleaving-Delay-Upstream per-subscriber (stacked)
      VLAN can be applied (1:1 model as defined in [TR-101]), the TLV
   Name:  Maximum-Interleaving-Delay-Upstream

   Type:  0x008B

   Description:  maximum
      contains two value fields.  Each field carries a 12-bit VLAN
      identifier (which is part of the VLAN tag defined by IEEE 802.1Q).
      The first field MUST carry the inner VLAN identifier, while the
      second field MUST carry the outer VLAN identifier.

      When the N:1 VLAN model is used, only one way interleaving delay.  This VLAN tag is an
      optional TLV.

   Length:  4 bytes

   Value:  Time in ms as a 32 bit unsigned integer

5.2.3.3.6.13.  Actual-Interleaving-Delay-Upstream available.
      For the N:1 model, the Access-Aggregation-Circuit-ID-Binary TLV

   Name:  Actual-Interleaving-Delay-Upstream

   Type:  0x008C

   Description:  Value corresponding to
      contains a single value field, which MUST carry the 12-bit VLAN
      identifier derived from the single available VLAN tag.

      In the interleaver setting.  This
      is case of an optional TLV.

   Length:  4 bytes

   Value:  Time in ms as a 32 bit unsigned integer

5.2.3.3.6.14.  Maximum-Interleaving-Delay-Downstream TLV

   Name:  Maximum-Interleaving-Delay-Downstream

   Type:  0x008D

   Description:  maximum one way interleaving delay.  This ATM aggregation network, where the DSLAM is
      directly connected to the NAS (without an
      optional TLV.

   Length:  4 bytes

   Value:  Time intermediate ATM
      switch), the VPI and VCI on the DSLAM uplink correspond uniquely
      to the DSL line on the DSLAM.  The Access-Aggregation-Circuit-ID-
      Binary TLV MAY be used to carry the VPI and VCI.  The first value
      field of the TLV MUST carry the VCI, while the second value field
      MUST carry the VPI.

      Each identifier MUST be placed in ms as a 32 bit unsigned integer

5.2.3.3.6.15.  Actual-Interleaving-Delay-Downstream

   Name:  Actual-Interleaving-Delay-Downstream

   Type:  0x008E

   Description:  Value corresponding the low-order bits of its
      respective 32-bit field, with the higher-order bits set to zero.
      The ordering of the interleaver setting.  This bits of the identifer MUST be the same as when
      the identifier is transmitted on the wire to identify an optional TLV. Ethernet
      frame or ATM cell.

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

   Length:  4 or 8 bytes

   Value:  Time in ms as a 32 bit unsigned integer

5.2.3.3.6.16.  DSL-Line-State  one or two 32-bit binary fields.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    TLV Type = 0x0006          |        Length = 4 or 8        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Single VLAN Identifier, inner VLAN identifier, or VCI        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                Outer VLAN identifier or VPI                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          Figure 12: The Access-Aggregation-Circuit-ID-Binary TLV

5.1.2.4.  Access-Aggregation-Circuit-ID-ASCII TLV (Mandatory for Port DOWN)

   Name:  DSL-Line-State

   Type:  0x008F  0x0003

   Description:  The state  This TLV transmits the ASCII equivalent of the DSL line.  For Access-
      Aggregation-Circuit-ID-Binary TLV.  As mentioned in the Port UP message, previous
      section, the AN control application will use a format similar to
      that specified in
      this specification, Section 3.9.3 of [TR-101] for the TLV is optional (since format of the message type
      implicitly conveys
      "circuit-id".

      As an extension to the state present document, the Access Node could
      convey to the NAS the characteristics (e.g., bandwidth) of the line).  For Port DOWN,
      uplink on the Access Node.  This TLV
      is mandatory, since it further communicates or the state binary equivalent
      defined above then serves the purpose of uniquely identifying the line
      as IDLE or SILENT.
      uplink whose characteristics are being defined.  The present
      document does not specify the TLVs needed to convey the uplink
      characteristics.

   Length:  4  up to 63 bytes

   Value:  32 bit unsigned integer

         SHOWTIME = 1

         IDLE = 2

         SILENT = 3

5.2.3.3.6.17.  Access-Loop-Encapsulation TLV

   Name:  Access-Loop-Encapsulation

   Type:  0x0090

   Description:  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 data link protocol and, optionally, AN control application in the
      encapsulation overhead on DSLAM requests ANCP to send a DSL-
   specific Port Up message to the access loop.  This is an optional
      TLV.  However, NAS under the following
   circumstances:

   o  when this TLV a new adjacency with the NAS is present, established, for each DSL
      loop that is synchronized at that time;

   o  subsequent to that, whenever a DSL loop resynchronizes; and

   o  whenever the data link protocol
      MUST minimally be indicated.  The encapsulation overhead MAY be
      indicated. AN control application wishes to signal that a line
      attribute has changed.

   The Access Node can choose AN control application in the DSLAM requests ANCP to send a DSL-
   specific Port Down message to not convey the
      encapsulation on NAS under the access loop by specifying following
   circumstances:

   o  when a value of 0 (NA)
      for new adjacency with the two encapsulation fields

   Length:  3 bytes

   Value:  The three bytes (most to least significant) and valid set of
      values NAS is established, for each byte are defined below.

         Byte 1: Data Link
            ATM AAL5 = 0

            ETHERNET = 1

         Byte 2: Encapsulation 1

            NA = 0

            Untagged Ethernet = 1

            Single-tagged Ethernet = 2

         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 DSL
      loop that is illustrated provisioned but not synchronized at that time;

   o  whenever a DSL loop that is equipped in Figure 10.

      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 10: an AN but administratively
      disabled is signalled as "IDLE"; and

   o  subsequent to that, whenever a DSL loop loses synchronization.

   The Access-Loop-Encapsulation TLV

5.3. AN control application passes information to identify the DSL
   loop to ANCP based to include in the Port Up or Port Down message, along
   with information relating to DSL Line Configuration

5.3.1.   Goals

   Following dynamic discovery of access topology (identification loop attributes.

   In the case of bonded copper loops to the customer premise (as per
   DSL
   line multi-pair bonding described by [G.988.1] and its attributes) [G.988.2]), the AN
   control application requests that ANCP send DSL-specific Port Up and
   Port Down messages for the aggregate "DSL bonded circuit"
   (represented as assisted a single logical port) as well as the individual DSL
   loops of which it is comprised.  The information relating to DSL line
   attributes that is passed by the mechanism described in AN control application is aggregate
   information.

   ANCP generates the previous section (topology discovery), DSL-specific Port Up or Port Down message and
   transfers it to the NAS.  ANCP on the NAS may query side passes an indication
   to the NAS control application that a
   subscriber management OSS system (e.g., RADIUS server) DSL Port Up or Port Down
   message has been received along with the information contained in the
   message.

   The NAS control application updates its view of the DSL loop state,
   performs any required accounting operations, and uses any included
   line attributes to retrieve
   subscriber authorization data (service profiles).  Most adjust the operation of such
   service its queueing/scheduling
   mechanisms are typically enforced by as they apply to data passing to and from that DSL loop.

   Figure 13 summarizes the interaction.

   1.   Home            Access                          NAS itself, but
   there are a few cases where it may
       Gateway           Node

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

   2.   Home            Access                          NAS
       Gateway           Node

             ----------->     -------------------------->
                  DSL           Port Up (Event message)
                Resynch        (updated line parameters)

   3.   Home            Access                          NAS
       Gateway           Node

             ----------->     -------------------------->
             Loss of          Port Down (Event message)
             DSL Signal       (selected line parameters)

          Figure 13: ANCP Message Flow For DSL Topology Discovery

6.2.  Protocol Requirements

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

6.2.1.  Protocol Requirements On the AN Side

   The AN-side ANCP agent MUST be useful able to push such service
   parameters create DSL-specific Port Up
   and Port Down messages according to the DSLAM for local enforcement of a mechanism (e.g.
   DSL-related) on format specified in
   Section 6.3.

   The AN-side ANCP agent MUST conform to the corresponding subscriber line.

   One such example normative requirements of a service parameter that can
   Section 5.1.2.

   The AN-side ANCP agent "must" be pushed to the
   DSLAM for local enforcement is DSL "interleaving delay".  Longer
   interleaving delay (and hence stringent error correction) is required
   for a video service able to ensure better video "quality of experience",
   whereas for a VoIP service or for "shoot first" gaming service, a
   very short interleaving delay is more appropriate.  Another relevant
   application is downloading per subscriber multicast channel
   entitlement accept any information in IPTV applications where the DSLAM is
   performing IGMP snooping or IGMP proxy function.  Using ANCP, the NAS
   can achieve the goal of pushing line configuration to the DSLAM by an
   interoperable and standardized protocol.

   If a subscriber wants
   passed to choose a different service, it by the AN control application that can require
   an operational-expense-intensive reconfiguration validly be
   included in any of the line via a
   network operator, possibly implying a business-to-business
   transaction between an ISP attribute TLVs specified in Section 6.5,
   MUST package that information as TLVs, and an access provider.  Using ANCP for
   line configuration from MUST include these TLVs,
   encapsulated in the NAS dramatically simplifies DSL-Line-Attributes TLV, within the OSS
   infrastructure for service management, allowing fully centralized
   subscriber-related service data (e.g., RADIUS server back-end) Port Up or
   Port Down message.

   The AN-side ANCP agent MUST follow the AN-side procedures associated
   with DSL-specific Port Up and
   avoiding complex cross-organization business-to-business
   interactions. Port Down messages as they are
   specified in Section 6.4.

6.2.2.  Protocol Requirements On the NAS Side

   The best way NAS-side ANCP agent MUST be able to receive and validate DSL-
   specific Port Up and Port Down messages according to change line parameters is by using profiles.  These
   profiles (DSL profiles for different services) are pre-configured on the DSLAMs. format
   specified in Section 6.3.

   The NAS can then send a reference NAS-side ANCP agent MUST conform to the right DSL
   profile via ANCP.  Alternatively, discrete DSL parameters can also be
   conveyed by normative requirements of
   Section 5.1.2.

   The NAS-side ANCP agent MUST follow the NAS NAS-side procedures
   associated with DSL-specific Port Up and Port Down messages as they
   are specified in ANCP.

5.3.2.  Message Flow

   Triggered by topology information reporting a new DSL line or
   triggered by a subsequent user session establishment (PPP or DHCP), Section 6.4.

   The NAS-side ANCP agent MUST be able to extract the NAS may send line configuration information (e.g. reference
   contained in any of the TLVs specified in Section 6.5 and "must" be
   able to a
   DSL profile) make that information available to the DSLAM using NAS control
   application.

6.3.  ANCP Port Management messages. UP and Port DOWN Event Message Descriptions

   The
   NAS may get such line configuration data ANCP Port UP and Port DOWN Event messages are derived from a policy server (e.g.,
   RADIUS).  Figure 11 summarizes the interaction.

   +----------+   +-----+     +-----+    +-------+    +-----------+
   |Radius/AAA|---| NAS |-----| AN  |----|  Home |----|Subscriber
   GSMPv3 Event message shown in Section 9 of [RFC3292].  The modified
   format used for DSL topology discovery is shown in Figure 14.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |
   |Policy           TCP/IP Encapsulating Header (Section 3.2)           |   +-----+     +-----+    |Gateway|    +-----------+
   |Server
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                ANCP General Message Header                    |
   +                      (Section 3.6.1)                          +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          +-------+
   +----------+

                                  1.DSL Signal
                                   <-----------
           2.                         Port UP (Event Message)
          (Access Topology Discovery)
                  <----------------
                              3. PPP/DHCP Session
                    <--------------------------------
     4. Authorization
    & Authentication
     <------------------- (unused)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Port Management Message
                    (Line Configuration)
                  5. -------->

   Figure 11: Message Flow - ANCP Mapping For Initial Line Configuration

   The NAS may update the line configuration due to a subscriber service
   change (e.g. triggered by the policy server).  Figure 12 summarizes
   the interaction.

                      +------+     +-------+   +---------+  +----------+ Session Number (unused)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Event Sequence Number (unused)                | NAS  |-----|  AN   |---|  Home   |--|Subscriber|
                      +------+     +-------+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Gateway                                                               |  +----------+
                                               +---------+

                                              1. PPP/DHCP Session
                       <------------------------------------------

     +-----------+                      2. Service On Demand
   +---                 Label (8 bytes, unused)                 ---+
   |           |<-----------------------------------------------                                                               | Web portal|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |x|x|x|x|x|x|x|x| Message Type  |   Tech Type   |  Reserved     |  OSS etc
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 3.Change     # of TLVs                 | Extension Block length (bytes)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               | Authorization
     |Radius AAA
   ~                 Access line identifying TLV(s)                ~
   |                                                               | --------> 4.Port Management
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Policy                DSL-Line-Attributes TLV                        |              Message
   ~        (MANDATORY in Port Up, OPTIONAL in Port Down)          ~
   |                                                               |          ------------->
     +-----------+       (Updated Line Config - New Profile)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

    Figure 12: Message flow - 14: Format Of the ANCP Mapping Port Up and Port Down Event Messages
                        For Updated Line Configuration

   The format of relevant extensions to port management message is
   defined in section DSL Topology Discovery

   See Section 5.3.3.  The line configuration models
   could be viewed as 3.6.1 for a form of delegation description of authorization from the NAS ANCP general message
   header.  The Message Type field MUST be set to 80 for Port Up, 81 for
   Port Down.  The 12 bit Code field MUST be set to 0.  The 4 bit Result
   field MUST be set to 0 (signifying Ignore).  The 24-bit Transaction
   Identifier field MUST be set to 0.  Other fields in the DSLAM.

5.3.3.  Specification of the ANCP DSL Line Configuration Capability

5.3.3.1.  Protocol Requirements general
   header MUST be set as described in Section 3.6.

   The DSL line configuration capability is assigned capability type
   0x02.  No capability data is associated with this capability.
   Implementations of Port, Port Session Number, and Event Sequence Number fields are
   not used by the DSL line configuration capability MUST support Topology Discovery capability.  The Label field
   (including the following ANCP protocol elements:

   o  ANCP Port Management message, which is based on Stacked Label Indicator and the GSMPv3
      [RFC3292] message unused flags at the
   start of the same name but includes capability-
      specific modifications Label field), is also unused, and extensions (Section 5.3.3.2).

   o MUST be treated as an
   unused fixed 8-byte field.  The procedures associated with this message and its contents
      (Section 5.3.3.3).

   o  Access-Loop-Circuit-ID TLV (as defined in Section 5.2.3.3);

   o  Access-Aggregation-Circuit-ID-Binary TLV (as defined in
      Section 5.2.3.3);

   o  Access-Aggregation-Circuit-ID-ASCII TLV (as defined in
      Section 5.2.3.3);

   o  Service-Profile-Name TLV (as defined handling of unused/reserved fields is
   described in Section 5.3.3.4).

5.3.3.2.  ANCP Port Management Message Format For DSL Line Configuration 3.4.

   The ANCP Port Management remaining message for DSL line configuration has fields belong to the
   format shown in Figure 13.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           TCP/IP Encapsulating Header (Section 4.2)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                ANCP General "extension block" added to
   the original GSMPv3 message by ANCP, and are described as follows:

   Extension Flags:  The flag bits denoted by 'x' are currently
      unspecified and reserved.

   Message Header                    |
   +                      (Section 4.4)                            +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Port                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Port Session Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Event Sequence Number                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|x|x|x|x|x|x|x|   Duration    |    Function   | X-Function    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Event Flags         |        Flow Control Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |x|x|x|x|x|x|x|x| Type:  Message Type  | has the same value as in the general
      header (i.e., 80 or 81).

   Tech Type   | Block Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type:  MUST be set to 0x05 (DSL).

   # of TLVs:  the number of TLVs               | that follow, not counting TLVs
      encapsulated within other TLVs.

   Extension Block length (bytes)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~ Length:  the total length of the TLVs                              ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 13

   See Section 4.6 for carried in the
      extension block in bytes, including any padding within individual
      TLVs.

   TLVs:  one or more TLVs to identify a description of DSL line and zero or more TLVs
      to define its characteristics.

6.4.  Procedures

6.4.1.  Procedures On the ANCP general message header. AN Side

   The Message Type field AN-side ANCP agent MUST be set create and transmit a DSL-specific Port
   Up or Port Down message when requested by the AN control application
   and presented with the information needed to 32.  The 12 bit Code field build a valid message,
   except if transmission is inhibited by a rate-dampening mechanism.
   It is RECOMMENDED that the Access Node use a dampening mechanism per
   DSL loop to control the rate at which state changes are communicated
   to the NAS.

   At the top level, the extension block within a DSL-specific Port Up
   or Port Down message MUST
   be set include TLVs from Section 5.1.2 to 0.  The 4 bit Result field identify
   the DSL loop.

   TLVs presenting DSL line attributes (i.e., the TLVs specified in
   Section 6.5) MUST be set to either 1 (NAck)
   or 2 (AckAll), as determined by policy on encapsulated within the NAS.  The 24-bit
   Transaction Identifier field DSL-Line-Attributes TLV.
   When the DSL-Line-Attributes TLV is present in a message, it MUST
   contain at least one such TLV and will generally contain more than
   one.  In the Port Up message, the DSL-Line-Attributes TLV MUST be set
   present.  In the Port Down message, the DSL-Line-Attributes TLV MAY
   be present.

   If the AN-side ANCP agent is unable to satisfy a positive value.  Other
   fields request from the AN
   control application because it detects an error in the general header MUST be set as described request or
   because it receives a Generic Response message indicating an error in Section 4.6.

   The
   a Port Management Up or Port Down message format defined in [RFC3292] that it has been
   modified sent and is unable to contain additional data
   recover from that error at the end of protocol level, it "must" inform the message.  Also,
   application, including any available diagnostic information.

6.4.2.  Procedures On the original two byte Function field has been modified NAS Side

   The NAS-side ANCP agent MUST be prepared to contain one
   byte receive Port Up and Port
   Down messages for the Function field indicating a specific action to be taken
   by the recipient given DSL loop or logical port at any time after
   negotiation of the message, and one byte an adjacency has been completed.  It is possible for X-Function field,
   which further qualifies the action specified
   two Port Up messages in the Function field.
   Any Function specific data MUST succession to be carried in TLVs in the extension
   block.

   The Port, Port Session Number, and Event Sequence Number fields are
   not used by received for the same DSL Line Configuration capability
   loop without an intervening Port Down message, and MUST be
   considered reserved.  The handling of unused/reserved fields is
   described in Section 4.4. vice versa.

   The remaining NAS-side ANCP agent SHOULD validate each message fields are described as follows:

   R Flag:  not used by ANCP.

   Additional Port Management flags:  the flag bits marked 'x' following
      the R flag are not used by ANCP.

   Duration:  not used for DSL line configuration.

   Function:  action to be performed.  For DSL line configuration,
      Function MUST be set to 8 (Configure Connection Service Data).
      This action type requests against the Access Node (i.e., DSLAM) to apply
      service configuration data contained
   specifications given in Section 6.3 and the extension value (TLVs)
      to TLV specifications given
   in Section 5.1.2 and Section 6.5.  If it finds an error it MAY
   generate a Generic Response message containing an appropriate Result
   Code value.  If it does so, the DSL line (identified by one message MUST contain copies of all of
   the identifier TLVs from Section 5.1.2 that were present in the extension
      value).

   X-Function:  qualifies the action set by Function.  For DSL line
      configuration, this field MUST be set Port
   Up or Port Down message.  The message SHOULD also contain a Status-
   Info TLV which in turn contains other information appropriate to 0.

   Event Flags:  not used by ANCP.

   Flow Control Flags:  not used by ANCP.

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

   Message Type:  Message Type has the same
   message header Code value as described in Section 3.6.1.4.

   If the general
      header (i.e., 32).

   Tech Type:  MUST be set to 0x05 (DSL).

   Block Length:  unused.

   # of TLVs: received message passes validation, the NAS-side ANCP agent
   "must" extract the information from the number of TLVs contained in the message
   and present that follow, not counting TLVs
      encapsulated within other TLVs.

   Extension Block Length: information along with an indication of reported
   event type to the total length NAS control application.  If validation of
   individual TLVs fails but the message as a whole can be processed,
   the NAS-side ANCP agent "may" pass the valid message contents to the
   NAS control application.

6.5.  TLVs carried in For DSL Line Attributes

   As specified above, the
      extension block in bytes, including any padding 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 individual
      TLVs.

   TLVs:  two the DSL-Line-Attributes TLV.

6.5.1.  DSL-Line-Attributes TLV

   Type:  0x0004

   Description:  This TLV encapsulates attribute values for a DSL line
      serving a subscriber.

   Length:  variable (up to 1024 bytes)

   Value:  one or more encapsulated TLVs corresponding to identify a DSL line and configure its
      service data.

5.3.3.3.  Procedures

   Section 5.3.2 Describes the circumstances under which the NAS sends
      attributes.  The DSL-Line-Attributes TLV MUST contain at least one
      TLV when it is present in a Port Management message to Up or Port Down message.  The
      actual contents are determined by the AN to configure DSL service parameters
   for a specific subscriber line.  To identify the line, control application.

6.5.2.  DSL-Type TLV

   Type:  0x0091

   Description:  Indicates the NAS MUST
   include one type of Access-Loop-Circuit-ID TLV, Access-Aggregation-
   Circuit-ID-Binary TLV, or Access-Aggregation-Circuit-ID-ASCII transmission system in use.

   Length:  4 bytes

   Value:  32 bit unsigned integer

         ADSL1 = 1

         ADSL2 = 2

         ADSL2+ = 3

         VDSL1 = 4

         VDSL2 = 5

         SDSL = 6

         OTHER = 0

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

   Type:  0x0081

   Description:  Actual upstream net data rate on a DSL line.

   Length:  4 bytes

   Value:  Rate in Kbits/s as a 32 bit unsigned integer

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

   Type:  0x0082
   Description:  Actual downstream net data rate on a DSL line.

   Length:  4 bytes

   Value:  Rate in Kbits/s as a 32 bit unsigned integer

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

   Type:  0x0083

   Description:  Minimum upstream net data rate desired by the Port Management message, depending upon 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 deployment scenario.
   The NAS MUST include one or more TLVs to configure line service
   parameters for
      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 line.  Section 5.3.3.4 currently identifies only
   one such TLV, Service-Profile-Name, but other TLVs may can be added by
   extensions to ANCP.

   If the NAS sets Result to AckAll (0x1) and the AN processes the Port
   Management message successfully, attained on the AN MUST return a Port Management
   message
      DSL line.

   Length:  4 bytes

   Value:  Rate in reply, containing Kbits/s as a Result field set to Success (0x3).
   All other fields of the returned message MUST 32 bit unsigned integer

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

   Type:  0x0086

   Description:  Maximum net downstream rate that can be identical to those
   received in the request.

   If an error occurs during the processing of the Port Management
   message, then attained on the AN MUST always return
      DSL line.

   Length:  4 bytes

   Value:  Rate in Kbits/s as a Port Management message
   with 32 bit unsigned integer

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

   Type:  0x0087

   Description:  Maximum net upstream data rate desired by the Result field set to Failure (0x4).  The Code field MUST be
   set to indicate 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 reason for failure.  The remainder of
      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 message
   MUST be copied from 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 request.  The AN MAY add
      operator in low power state.

   Length:  4 bytes
   Value:  Rate in Kbits/s as a 32 bit unsigned integer

6.5.13.  Maximum-Interleaving-Delay-Upstream TLV

   Type:  0x008B

   Description:  maximum one way interleaving delay.

   Length:  4 bytes

   Value:  Time in ms as a Status-Info 32 bit unsigned integer

6.5.14.  Actual-Interleaving-Delay-Upstream TLV
   (Section 6.2.3)

   Type:  0x008C

   Description:  Value corresponding to provide further information on the error, in which
   case the various length fields and the # of TLVs field within the
   message MUST be adjusted accordingly.

5.3.3.4.  TLVs For DSL Line Configuration

   Currently only the following TLV is specified for DSL line
   configuration.  More TLVs may be defined interleaver setting.

   Length:  4 bytes

   Value:  Time in ms as a future version of this
   specification or 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 ANCP extensions for individual service attributes
   of ms as a DSL line (e.g. rates, interleaving delay, multicast channel
   entitlement access-list).

   Name:  Service-Profile-Name 32 bit unsigned integer

6.5.16.  Actual-Interleaving-Delay-Downstream

   Type:  0x0005  0x008E

   Description:  Reference  Value corresponding to a pre-configured profile on the DSLAM that
      contains service specific data for the subscriber. interleaver setting.

   Length:  up to 64  4 bytes

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

5.4.  ANCP Based DSL Line Testing Capability

   In  Time in ms as a mixed Ethernet and ATM access network (including 32 bit unsigned integer

6.5.17.  DSL-Line-State TLV
   Type:  0x008F

   Description:  The state of the local
   loop), it is desirable to provide similar mechanisms for connectivity
   checks and fault isolation, as those used in an ATM based
   architecture.  This can be achieved using an ANCP based mechanism
   until end-to-end Ethernet OAM mechanisms are more widely implemented
   in various network elements.

   A simple solution based DSL line.

   Length:  4 bytes

   Value:  32 bit unsigned integer

         SHOWTIME = 1

         IDLE = 2

         SILENT = 3

6.5.18.  Access-Loop-Encapsulation TLV

   Type:  0x0090

   Description:  The data link protocol and, optionally, the
      encapsulation overhead on ANCP can provide the NAS with an access
   line test capability and to some extent fault isolation.  Controlled
   by a local management interface the NAS can use an ANCP operation to
   trigger 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 perform a loopback test not convey the encapsulation on the local access loop
   (between by
      specifying values of 0 (NA) for the Access Node two encapsulation fields.

   Length:  3 bytes

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

         Byte 1: Data Link

            ATM AAL5 = 0

            ETHERNET = 1

         Byte 2: Encapsulation 1

            NA = 0

            Untagged Ethernet = 1

            Single-tagged Ethernet = 2

            Double-tagged Ethernet = 3

         Byte 3: Encapsulation 2

            NA = 0

            PPPoA LLC = 1

            PPPoA NULL = 2

            IPoA LLC = 3

            IPoA NuLL = 4

            Ethernet over AAL5 LLC with FCS = 5

            Ethernet over AAL5 LLC without FCS = 6

            Ethernet over AAL5 NULL with FCS = 7

            Ethernet over AAL5 NULL without FCS = 8

   The Access-Loop-Encapsulation TLV is illustrated in Figure 15.

      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 15: The Access Node can respond
   via another Access-Loop-Encapsulation TLV

7.  ANCP operation with the result of the triggered loopback
   test.  In the case of ATM based local loop the ANCP operation can
   trigger the Access Node to generate ATM (F4/F5) loopback cells on the
   local loop.  In the DSL Line Configuration

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

7.1.  Control Context (Informative)

   Triggered by topology information reporting a new DSL line or
   triggered by a subsequent user session establishment (PPP or DHCP),
   RADIUS/AAA sends service parameters to the Access Node can trigger an
   Ethernet loopback message(per EFM OAM) NAS control application
   for configuration on the local loop.

5.4.1.  Message Flow access line.  The Port Management message can be used by the NAS to control application
   passes the request Access
   Node to trigger a remote loopback test on to the local loop.  The result
   of the loopback test can be asynchronously conveyed by NAS-side agent, which sends the Access
   Node
   information to the NAS in AN by means of a Port Management response (line
   configuration) message.  The formats
   of AN-side agent passes this information up
   to the relevant extensions AN control application, which applies it to the line.

   Figure 16 summarizes the interaction.

     Home            Access               NAS             RADIUS/AAA
    Gateway           Node                             Policy Server

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

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

                          <----------------
                            Port Management message are defined
   in Section 5.4.2.2.
                            (line configuration)

   Figure 16: 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 14 17 summarizes the interaction.

 +-------------+    +-----+       +-------+           +----------------+
 |Radius/AAA   |----|NAS  |-------| DSLAM |-----------|    CPE         |
 |Policy Server|    +-----+       +-------+           | (DSL Modem +

User     Home            Access         NAS
        Gateway           Node

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

   -------------------------------------------------------> Web portal,
               Service on demand                              OSS, etc.
                                                                 |
 +-------------+                                      |Routing Gateway)|
                                                      +----------------+
                  Port Management Message
                  (Remote Loopback          ATM loopback
                   Trigger Request)         OR EFM Loopback
                1.  ---------------->     2. --------->
                                             <--------+
                     3. <---------------
                                           <--------------  RADIUS/AAA
                                             Change of     Policy Server
                                           authorization

                             <------------
                              Port Management Message
                (Remote Loopback Test Response)
                                  message
                              (new profile)

   Figure 14: 17: Message Flow For ANCP based OAM

5.4.2.  Specification of the flow - ANCP DSL Mapping For Updated Line  Testing Capability

5.4.2.1. Configuration

7.2.  Protocol Requirements

   The DSL line testing configuration capability is assigned capability type 0x04.
   0x0002.  No capability data is associated with this capability.  Implementations
   of the DSL line testing capability MUST support

7.2.1.  Protocol Requirements On the following ANCP
   protocol elements:

   o NAS Side

   The NAS-side ANCP agent MUST be able to create DSL-specific Port
   Management message, which is based on the GSMPv3
      [RFC3292] message of (line configuration) messages according to the same name but includes capability-
      specific modifications and extensions (Section 5.4.2.2).

   o  The procedures associated with this message and its contents
      (Section 5.4.2.3).

   o  Access-Loop-Circuit-ID TLV (as defined format
   specified in Section 5.2.3.3);

   o  Access-Aggregation-Circuit-ID-Binary TLV (as defined in 7.3.

   The NAS-side ANCP agent MUST conform to the normative requirements of
   Section 5.2.3.3);

   o  Access-Aggregation-Circuit-ID-ASCII TLV (as defined 5.1.2.

   The NAS-side ANCP agent "must" be able to accept any information
   passed to it by the NAS control application that may validly be
   included in
      Section 5.2.3.3);

   o  OAM-Loopback-Test-Parameters TLV;

   o  Opaque-Data TLV;

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

   If not otherwise indicated, any of the TLVs listed above are defined specified in Section 5.4.2.4.

5.4.2.2.  Message Format 7.5.

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

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

   The NAS-side ANCP agent MUST follow the same format
   as for DSL line configuration (see Section 5.3.3.2), NAS-side procedures
   associated with the
   following differences:

   o  The Result field DSL-specific Port Management (line configuration)
   messages as they are specified in Section 7.4.

7.2.2.  Protocol Requirements On the request SHOULD be set to AckAll (0x1), to
      allow the NAS AN Side

   The AN-side ANCP agent MUST conform to receive the information contained in a successful
      test response.

   o normative requirements of
   Section 5.1.2.

   The Function field AN-side ANCP agent MUST be set able to 9 (Remote Loopback).  (The
      X-Function field continues receive and validate DSL-
   specific Port Management (line configuration) messages according to be 0.)

   o  The appended TLVs in
   the extension value field include testing-
      related TLVs rather than subcriber service information.

5.4.2.3.  Procedures format specified in Section 7.3.

   The AN-side ANCP agent MUST follow the AN-side procedures associated
   with DSL-specific Port Management message (line configuration) messages as described
   specified in Section 5.4.2.2 MAY 7.4.

   The NAS-side ANCP agent MUST be used by the NAS able to trigger extract the Access Node information
   contained in any of the TLVs listed in Section 7.2.1 and "must" make
   that information available to run a loopback test
   on the local loop.  To identify NAS control application.

7.3.  ANCP Port Management (Line Configuration) Message Format

   The ANCP Port Management message for DSL line configuration has the
   format shown in Figure 18.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           TCP/IP Encapsulating Header (Section 3.2)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                ANCP General Message Header                    |
   +                      (Section 3.6.1)                          +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Port (unused)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Port Session Number (unused)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Event Sequence Number  (unused)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|x|x|x|x|x|x|x| Dur. (unused) |  Function=8   | X-Function=0  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Event Flags  (unused)       | Flow Control Flags  (unused)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |x|x|x|x|x|x|x|x| Message Type  |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     # of TLVs               | Extension Block length (bytes)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                 Access line to identifying TLV(s)                ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                Line configuration TLVs                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   NOTE: TLVs MAY be tested, the NAS MUST
   include one of Access-Loop-Circuit-ID TLV, Access-Aggregation-
   Circuit-ID-Binary TLV, or Access- Aggregation-Circuit-ID-ASCII TLV in
   the a different order from what is shown in this
   figure.

       Figure 18: Port Management message, depending upon the deployment scenario.
   The NAS MAY include the OAM-Loopback-Test-Parameters and/or Opaque-
   Data TLVs (defined in Message For DSL Line Configuration

   See Section 5.4.2.4) to configure the loopback test 3.6 for that line.

   The Access Node SHOULD generate a Port Management response when it
   deems the loopback test to be complete.  (The exception is described
   with reference to the Timeout field in description of the OAM-Loopback-Test-
   Parameters TLV in Section 5.4.2.4.) ANCP general message header.
   The Result Message Type field MUST be set to
   Success (0x3) or Failure (0x4) as applicable. 32.  The 12 bit Code field SHOULD MUST
   be set to one of the following values if applicable.

   1280 (0x500):  Specified access line does not exist

   1281 (0x501):  Loopback test timed out

   1282 (0x502):  Reserved

   1283 (0x503):  DSL line status showtime
   1284 (0x504):  DSL line status idle

   1285 (0x505):  DSL line status silent

   1286 (0x506):  DSL line status training

   1287 (0x507):  DSL line integrity error

   1288 (0x508):  DSLAM resource not available

   1289 (0x509):  Invalid test parameter

   All other fields including the appended TLVs 0.  The 4 bit Result field MUST be copied from the
   request, except that the OAM-Loopback-Test-Parameters TLV MUST NOT
   appear in the response and the OAM-Loopback-Test-Response-String TLV
   SHOULD appear in the response.

   Section 5.4.2.4 contains additional procedures relating set to specific
   TLVs.

5.4.2.4.  TLVs For either 1 (NAck)
   or 2 (AckAll), as determined by policy on the DSL Line Test Capability NAS.  The following TLVs have been defined for use with the DSL line
   testing capability.

5.4.2.4.1.  OAM-Loopback-Test-Parameters TLV

   Name:  OAM-Loopback-Test-Parameters

   Type:  0x0007

   Description:  Parameters related 24-bit
   Transaction Identifier field MUST be set to a loopback test.  This is an
      optional TLV.  If this TLV is not present positive value.  Other
   fields in the request message,
      the DSLAM SHOULD use locally determined default values for the
      test parameters.

   Length:  2 bytes

   Value:  two 1 byte fields general header MUST be set as described below (listed in order of most Section 3.6.

   The Port Management message format defined in [RFC3292] has been
   modified to
      least significant).

         Byte 1: Count.  Number of loopback cells/messages that should
         be generated on contain additional data at the local loop as part end of the loopback test.
         The NAS SHOULD restrict message.  Also,
   the "count" to be greater than 0 and
         less than or equal original two byte Function field has been modified to 32.  The DSLAM SHOULD discard a request contain one
   byte for the Function field indicating a loopback test, if specific action to be taken
   by the received test parameters contain an
         out recipient of range value the message, and one byte for X-Function field,
   which further qualifies the "count" field.  The AN MAY include a
         Code value of 0x509 "Invalid test parameter" action specified in the resulting
         failure response to Function field.
   Any Function specific data MUST be carried in TLVs in the NAS.

         Byte 2: Timeout.  Upper bound on extension
   block.

   The Port, Port Session Number, and Event Sequence Number fields are
   not used by the time DSL Line Configuration capability.  The handling of
   unused/reserved fields is described in seconds that the
         NAS will wait for a response from Section 3.4.

   The remaining message fields are described as follows:

   R Flag:  not used by ANCP.

   Additional Port Management flags:  the DSLAM.  If flag bits marked 'x' following
      the total time
         taken R flag are not used by the DSLAM ANCP.

   Duration:  not used for DSL line configuration.

   Function:  action to complete a test with requested
         parameters, exceeds the specified "timeout" value, it MAY
         choose be performed.  For line configuration, Function
      MUST be set to omit 8 (Configure Connection Service Data).  This action
      type requests the generation of a response Access Node (i.e., DSLAM) to apply service
      configuration data contained in the NAS.  The
         DSLAM SHOULD use a locally determined extension value for Timeout, if (TLVs) to the
         received value
      DSL line (identified by one of the Timeout parameter is 0.

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

              Figure 15: The OAM-Loopback-Test-Parameters TLV

5.4.2.4.2.  Opaque-Data TLV

   Name:  Opaque-Data

   Type:  0x0008

   Description:  This is an optional TLV.  If it is present TLVs in the
      request message, the DSLAM SHOULD reflect it back in extension value).

   X-Function:  qualifies the response
      unmodified.

   Length:  8 bytes

   Value:  Two 32 bit unsigned integers inserted action set by the NAS (not to Function.  For DSL line
      configuration, this field MUST be
      interpreted set to 0.

   Event Flags:  not used by ANCP.

   Flow Control Flags:  not used by ANCP.

   Extension Flags:  the DSLAM, but just reflected back in the
      response).

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

   Name:  OAM-Loopback-Test-Response-String

   Type:  0x0009

   Description:  Suitably formatted string containing useful details
      about the test that flag bits denoted by 'x' before the NAS will display Message
      Type field are reserved for future use.

   Message Type:  Message Type has the operator, exactly same value as received from the DSLAM (no manipulation/interpretation by the
      NAS).  This is an optional TLV, but it is strongly RECOMMENDED
      that in case of ATM based local loop, the DSLAM at the very least
      indicates, via this TLV, general
      header (i.e., 32).

   Reserved (16 bits):  reserved for future use.

   # of TLVs:  the total loopback cells generated and number of TLVs that follow, not counting TLVs
      encapsulated within other TLVs.

   Extension Block Length:  the total loopback cells successfully received as part length of
      executing the requested loopback test.

   Length:  up to 128 bytes

   Value:  UTF-8 encoded string of text.

6.  Additional ANCP Messages and TLVs

   This section defines carried in the
      extension block in bytes, including any padding within individual
      TLVs.

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

   Other ANCP capabilities, either specific to DSL or technology-
   independent, MAY reuse the Port Management message for service
   configuration.  If the settings of the fixed fields are compatible
   with the settings just described, the same Port Management message
   that is used for DSL line configuration MAY be used to carry TLVs
   relating to the other capabilities that may apply to the same DSL loop.

   Use of the Port Management message for configuration MAY also be
   useful
   generalized to other access technologies, if the respective
   capabilities specify use of access line identifiers appropriate to
   those technologies in multiple capabilities.  Typically place of the content is under-
   specified, identifiers defined in
   Section 5.1.2.

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 intention that particular capabilities spell out
   necessary information to do so, the remaining details.

6.1.  Additional Messages NAS-side agent MUST create and General Messaging Principles

6.1.1.  General Principles for
   send a Port Management message with the  Design 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 ANCP Messages
   Section 5.1.2.  The GSMPv3 protocol [RFC3292] allows NAS MUST include one or more TLVs to configure
   line service parameters for two messaging constructs that line.  Section 7.5 currently
   identifies only one such TLV, Service-Profile-Name, but other TLVs
   MAY be added by extensions to
   support request/response interaction:

   a. ANCP.

7.4.2.  Procedures On the AN Side

   The same message type is used AN-side ANCP agent MUST be prepared to receive Port Management
   (line configuration) messages for both the request a given DSL loop or logical port at
   any time after negotiation of an adjacency has been completed.

   The AN-side ANCP agent SHOULD validate each message against the
   specifications given in Section 7.3 and the TLV specifications given
   in Section 5.1.2 and Section 7.5.  If it finds an error it MUST
   return a Port Management response message.  The message which copies the Port
   Management request as it was received, but has the Result header
   field set to 0x04 (Failure) and the Code field settings are
       used set to differentiate between request and response messages.

   b.  The request and response messages use two different message
       types.

   The first approach is illustrated by the protocol specifications in
   Section 5. appropriate
   value.  The purpose of this section is AN-side agent MAY add a Status-Info TLV (Section 4.5) to
   provide more details
   about further information on the second approach error, particularly if this is
   recommended in order to allow Section 3.6.1.4 for the given Code value.  If it does
   so, the various length fields and the use # of this messaging
   construct for TLVs field within the development of additional ANCP extensions.

   As Section 4.6 indicated, all ANCP messages other than adjacency
   messages share a common header format.  When
   message MUST be adjusted accordingly.

   If the response received message
   type is different from that of passes validation, the request, AN-side ANCP agent
   "must" extract the specification of information from the TLVs contained in the
   request message will typically indicate
   and present that information to the AN control application.  In
   addition, if the Result header field is was set to Ignore (0x0) and provide procedures indicating explicitly when 0x2 (AckAll) in the
   receiver should generate
   original request, the AN-side agent "must" indicate to the AN control
   application that a response and what message type it should
   use.

   The Transaction ID field is used to distinguish between required.  When the AN control
   application indicates that it has processed the request
   messages and to associate successfully,
   the AN-side agent MUST return a Port Management response message
   which duplicates the request except that the Result header field is
   set to 0x3 (Success).  (The Code field, as in the original request,
   has value 0.)

7.5.  TLVs For DSL Line Configuration

   Currently only the following TLV is specified for DSL line
   configuration.  More TLVs may be defined in a request.
   Specifications future version of this
   specification or in ANCP messages extensions for applications not requiring
   response correlation should indicate that the Transaction ID must be
   set individual service attributes
   of a DSL line (e.g. rates, interleaving delay, multicast channel
   entitlement access-list).

7.5.1.  Service-Profile-Name TLV

   Type:  0x0005

   Description:  Reference to zero in requests.  Applications a pre-configured profile on the DSLAM that require response
   correlation should refer
      contains service specific data for the subscriber.

   Length:  up to 64 bytes

   Value:  ASCII string containing the profile name (which the Transaction ID behaviour described 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 4.6.1. 3.3 of [RFC5851]

8.1.  Control Context (Informative)

   The specification NAS control application initiatea a request for remote
   connectivity testing for a response message should indicate in all cases
   that value of given access loop.  The NAS control
   application can provide loop count and timeout test parameters and
   opaque data for its own use with the Transaction Identifier must be set to that request.  The loop count
   parameter indicates the number of test messages or cells to be used.

   The timeout parameter indicates the
   corresponding request message.  This allows longest that the requester to
   establish whether or not correlation is needed (by setting a non-zero
   or zero value NAS control
   application will wait for the Transaction ID).

6.1.2.  Provisioning Message a result.

   The Provisioning message request is sent by passed in a Port Management (OAM) message.  If the NAS to
   control application has supplied test parameters, they are used,
   otherwise the AN to provision
   information of global scope on the AN.  The Provisioning message has control application uses default test parameters.
   If a loop count parameter provided by the format shown in Figure 16.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           TCP/IP Encapsulating Header (Section 4.2)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                ANCP General Message Header                    |
   +                      (Section 4.4)                            +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                             TLVs                              ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 16: Format of NAS is outside the Provisioning Message

   This document specifies valid
   range, the following fields.  The remaining fields
   in AN does not execute the ANCP general message header MUST be set as specified in
   Section 4.6.1.  The TLVs are specified elsewhere on test, but returns a per-capability
   basis.  The Provisioning message MAY be used to carry data relating
   to more than one capability at once, assuming result
   indicating that the capabilities
   concerned can co-exist and have all been negotiated during adjacency
   establishment.

   Message Type:  MUST be set to 93.

   Result:  MUST be set to 0x0 (Ignore).

   Code:  MUST be set test has failed due to zero.

   Transaction ID:  MUST be populated with a non-zero an invalid parameter.  If
   the test takes longer than the timeout value chosen in (default or provided by
   the manner described in Section 4.6.1.

   If NAS) the AN control application can process return a failure result
   indicating timeout or else can send no response.  The AN control
   application can provide a human-readable string describing the message successfully test
   results,for both failures and accept all the
   provisioning directives contained successes.  If provided, this string is
   included in it, the AN response.  Responses always include the opaque data,
   if any, provided by the NAS control application.

   Figure 19 summarizes the interaction.

 +-------------+    +-----+       +-------+           +----------------+
 |Radius/AAA   |----|NAS  |-------| DSLAM |-----------|    CPE         |
 |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)

                Figure 19: 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 NOT send any
   response.

   If not otherwise specified, if the AN fails be able to create DSL-specific Port
   Management (OAM) messages according to process the message
   successfully it format specified in
   Section 8.3.

   The NAS-side ANCP agent MUST send a Generic Response message (Section 6.1.3)
   indicating failure and providing appropriate diagnostic information.

6.1.3.  Generic Response Message

   This section defines conform to the Generic Response message. normative requirements of
   Section 5.1.2.

   The Generic
   Response message may NAS-side ANCP agent "must" be specified as the appropriate response able to a
   message defined in an extension accept any information
   passed to ANCP, instead of a more specific
   response message.  As a general guideline, specification of it by the
   Generic Response message as a response is appropriate where no data
   needs to NAS control application that may validly be returned to the peer other than a result (success or
   failure), plus,
   included in the case any of a failure, a code indicating the
   reason for failure TLVs specified in Section 8.5.

   The NAS-side ANCP agent MUST package that information as TLVs, and a limited amount of diagnostic data.
   Depending on the particular use case,
   MUST include these TLVs within the Generic Response message
   MAY be sent by either Port Management (OAM) message.

   The NAS-side ANCP agent MUST follow the NAS or 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.

   The AN or NAS MAY send a Generic Response message indicating a
   failure condition independently Side

   The AN-side ANCP agent MUST conform to the normative requirements of a
   Section 5.1.2.

   The AN-side ANCP agent MUST be able to receive and validate DSL-
   specific request before closing Port Management (OAM) messages according to the adjacency as a consequence of that failure condition.  In this
   case, format
   specified in Section 8.3.

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

   The NAS-side ANCP agent MUST set be able to extract the Transaction ID field information
   contained in any of the header TLVs listed in Section 8.2.1 and "must" make
   that information available to the NAS control application.

8.3.  Port Management (OAM) Message Type Format

   The Port Management message for DSL line testing has the same format
   as for DSL line configuration (see Section 7.3), with the following
   differences:

   o  The Result field within in the Status-Info TLV request SHOULD be set to zeroes.  The
   receiver MAY record AckAll (0x1), to
      allow the NAS to receive the information contained in the Status-info TLV
   for management use. a successful
      test response.

   o  The format of Function field MUST be set to 9 (Remote Loopback).  (The
      X-Function field continues to be 0.)

   o  The appended TLVs in the Generic Response extension value field include testing-
      related TLVs rather than subcriber service information.

   The Port Management (OAM) message is shown illustrated in Figure 17 20.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           TCP/IP Encapsulating Header (Section 4.2) 3.2)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                ANCP General Message Header                    |
   +                      (Section 4.4) 3.6.1)                          +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Status-Info TLV                        Port (unused)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Port Session Number (unused)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Event Sequence Number  (unused)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|x|x|x|x|x|x|x| Dur. (unused) |  Function=9   | X-Function=0  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Event Flags  (unused)       | Flow Control Flags  (unused)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |x|x|x|x|x|x|x|x| Message Type  |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     # of TLVs               | Extension Block length (bytes)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    (Section 6.2.3)                 Access line identifying TLV(s)                ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                   Testing-related TLVs                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

    Figure 17: Structure 20: 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 Generic Response Message

   This document specifies 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 following fields.  The remaining fields
   in
   necessary information to do so, the ANCP general message header NAS-side agent MUST be create and
   send a Port Management (OAM) request with the fixed fields set as specified
   described in
   Section 4.6.1.

   Message Type:  MUST be set to 91.

   Result: the previous section.  The message MUST be set to 0x3 (Success) contain one or 0x4 (Failure).

   Code:  MUST be set
   more TLVs to zero for success or identify an appropriate non-zero
      value for failure.

   Transaction ID:  MUST be copied from access line according the message to which this
      message is a response.

   Status-Info TLV: requirements of
   Section 5.1.2.  The NAS MAY be present in a success response, to provide a
      warning as defined for a specific request message type.  MUST be
      present include the Opaque-Data TLV and/or the
   OAM-Loopback-Test-Parameters TLV (defined in a failure response.  See Section 6.2.3 for a detailed
      description of 8.5) to
   configure the Status- Info TLV. loopback test for that line.

8.4.2.  AN-Side Procedures

   The actual contents will
      depend on the request message type this AN-side ANCP agent SHOULD validate each message is responding to.

6.2.  TLVs For General Use

   This section contains against the definitions of some TLVs that are intended
   to be re-usable across different message types
   specifications given in Section 8.3 and capabilities.

6.2.1.  Target TLV

   Name:  Target
   Type:  0x1000 to 0x1020 depending on the specific content.  Only
      0x1000 has been assigned in this specification (see below).

   Description:  The Target TLV (0x1000 - 0x1020) is intended to be a
      general means to represent different types of objects.

   Length:  Variable, depending on specifications given
   in Section 5.1.2 and Section 8.5.  If it finds an error it MUST
   return a Port Management response message which copies the specific object type.

   Value:  Target information Port
   Management request as defined for each object type.  The it was received, but has the Result header
   field can consist of sub-TLVs.

   TLV Type 0x1000 is assigned set to a variant of the Target TLV
   representing a single access line 0x04 (Failure) and encapsulating one or more sub-
   TLVs identifying the target.  Figure 18 illustrates Code field set to the message
   format for a single port identified by an Access-Loop-Circuit-ID TLV
   (0x0001) that could appropriate
   value.  Code value 1289 as described below MAY apply, as well as the
   other Code values documented in Section 3.6.1.4.  Code value 1289
   SHOULD be derived from a Port-UP message:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | used if the OAM-Loopback-Test-Parameters TLV Type = 0x1000          |Length = Circuit-ID Length + 4 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID=0x0001 |       Circuit-ID Length       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Access Loop Circuit ID                     ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 18: Example is present
   with an invalid value of Target TLV For Single Access Line

6.2.2.   Command TLV

   Name:  Command

   Type:  0x0011

   Description: the Count field.  The Command AN-side agent MAY add
   a Status-Info TLV (0x0011) is intended (Section 4.5) to be a general
      means of encapsulating one or more command directives provide further information on the
   error, particularly if this is recommended in a TLV
      oriented message.  The semantics Section 3.6.1.4 for the
   given Code value.  If it does so, the various length fields and the #
   of TLVs field within the command can message MUST be specified
      for each adjusted accordingly.

   If the received message type using it.  I.e., passes validation, the AN-side ANCP agent
   "must" extract the information from the TLVs contained in the specification of each message type
   and present that can carry information to the Command TLV is expected AN control application.  It MUST
   NOT generate an immediate response to define the meaning of request, but MUST instead
   wait for the content of AN control application to indicate that the payload, although re-use of
      specifications is, of course, permissible when appropriate.

   Length:  Variable, depending on response
   should be sent.

   When requested by the specific contents.

   Value:  Command AN control application and presented with the
   necessary information to do so, the AN-side agent MUST create and
   send a Port Management (OAM) response to the original request.  The
   Result field MUST be set to Success (0x3) or Failure (0x4), and the
   Code field SHOULD be set to one of the following values, as defined indicated
   by the AN control application.

   1280 (0x500):  Specified access line does not exist.  See the
      documentation of Code 3/1280 in Section 3.6.1.4 for each message type. more
      information.  The Result header field can include sub-TLVs. MUST be set to Failure
      (0x4).

   1281 (0x501):  Loopback test timed out.  The contents of this TLV Result header field MUST
      be
      specified as one "command" or alternatively a sequence set to Failure (0x4).

   1283 (0x503):  DSL line status showtime

   1284 (0x504):  DSL line status idle

   1285 (0x505):  DSL line status silent

   1286 (0x506):  DSL line status training

   1287 (0x507):  DSL line integrity error

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

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

   All other fields of one or
      more "commands", each beginning with a one-byte Command Code and
      possibly the request including other data following the Command Code.  An IANA
      registry has been established for Command Code values.  This
      document reserves TLVs MUST be copied
   into the Command Code value 0 as an initial entry response unchanged, except that in
      the registry.

6.2.3.  Status-Info TLV

   Name:  Status-Info

   Type:  0x0106

   Description:  The Status-Info-TLV is intended to be a general
      container for warning or error diagnostics relating to commands
      and/or requests.  It is a supplement to successful response the Code field in
   OAM-Loopback-Test-Parameters TLV MUST NOT appear.  If the ANCP
      general header.  The specifications for individual message types
      may indicate AN control
   application has provided the use of this TLV as part of responses,
      particularly for failures.  As mentioned above, necessary information, the Generic
      Response message will usually AN-side agent
   MUST also include an instance of the Status-
      Info TLV.

   Length:  Variable, depending on OAM-Loopback-Test-Response-
   String TLV in the specific contents.

   Value: response.

8.5.  TLVs For the DSL Line Remote Connectivity Testing Capability

   The following fixed fields.  In addition, sub-TLVs may be
      appended to provide further diagnostic information.

      Reserved:  see Section 4.4 TLVs have been defined for handling of reserved fields.

      Msg use with the DSL line
   testing capability.

8.5.1.  OAM-Loopback-Test-Parameters TLV

   Type:  Message Type of  0x0007

   Description:  Parameters intended to override the request default values for which
      this TLV is
         providing diagnostics.

      Error Message loopback test.

   Length:  Number of  2 bytes in the error message,
         excluding padding.  This MAY be zero if no error message is
         provided.

      Error Message:  Human-readable string providing information about
         the warning or error condition.  Padded with zeroes as
         necessary to extend to a four-byte word boundary.

      The following TLVs are RECOMMENDED

   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 appended if the indicated
      Code values are given in generated on the header local loop as part of the message containing the
      Status-info TLV:

      *  Code loopback test.
         The Count value 4 SHOULD be greater than 0 and less than or 5: equal
         to 32.

         Byte 2: Timeout.  Upper bound on the Target or other TLV identifying time in seconds that the
         unknown or unavailable port.

      *  Code value 84:
         NAS will wait for a response from the DSLAM.  The value 0 MAY
         be used, but has a special meaning.

   The OAM-Loopback-Test-Parameters TLV that is unsupported or contains the
         unsupported value. illustrated in Figure 19 illustrates the Status-Info TLV. 21

      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 0x0007          |      Error Message        Length = 2             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Error Message (padded to 4 byte boundary)   Count       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  Timeout      |           optional sub-TLVs...         Padding (=0)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 19: 21: The Status-Info OAM-Loopback-Test-Parameters TLV

7.

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

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

7.1.

9.1.  Summary

   This section requests the following IANA actions:

   o  addition of message types to the GSMPv3 Message Type Name Space
      registry;

   o  addition of a result type to the GSMPv3 Result Type Name Space
      registry; [Editor's Note: may need an ANCP registry instead.
      Coordination between the two protocols is unnecessary because of
      ANCP's reorganization of the Result field.]

   o  extension of limits [Editor's Note: assuming we are allowed to do
      this!] and addition of failure codes to the GSMPv3
      Failure Response Message Name Space registry;

   o  establishment of the following new ANCP registries:

         ANCP Function Codes;

         ANCP Technology Types;

         ANCP Command Codes;

         ANCP TLV Types;

         ANCP Capabilities.

7.2.

9.2.  IANA Actions

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

        +------------------+----------------+--------+-----------+
        | Message Name     | Message Number | Status | Reference |
        +------------------+----------------+--------+-----------+
        | Generic Response | 91             |        | RFCXXXX   |
        | Provisioning     | 93             |        | RFCXXXX   |
        +------------------+----------------+--------+-----------+

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

           +--------------+-----------------------+-----------+
           | Result Value | Result Type Name      | Reference |
           +--------------+-----------------------+-----------+
           | 0            | Ignore (was Reserved) | RFCXXXX   |
           +--------------+-----------------------+-----------+

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

   o  Add the following note to the registry:

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

   o  Extend the table of registration procedures as indicated.

   o  Add entries to the failure response message name table as
      indicated.

   o  Replace the ranges of unassigned codes at the end of the failure
      response message name table as indicated.

           +----------+------------------------+---------------+
           | Range    | Registration Procedure | Notes         |
           +----------+------------------------+---------------+
           | 256-4095 | IETF Consensus         | ANCP use only |
           +----------+------------------------+---------------+

   +-------+-----------------------------------------------+-----------+

   +-------+----------------------------------------------+-----------+
   | Value | Failure Response Message Name                | Reference |
   +-------+-----------------------------------------------+-----------+
   +-------+----------------------------------------------+-----------+
   | 81    | Request message type not implemented (0x51)  | RFCXXXX   |
   | 82    | Transaction identifier out of sequence (0x52) | RFCXXXX   |
   | 83    | Malformed message (0x53)                     | RFCXXXX   |
   | 84    | Mandatory TLV or value not supported by negotiated      | RFCXXXX   |
   |       | capability set missing (0x54)                 | RFCXXXX   |
   | 85    | Invalid value in TLV (0x55)                  | RFCXXXX   |
   | 1280  | Specified access line does not exist (0x500) | RFCXXXX   |
   | 1281  | Loopback test timed out (0x501)              | RFCXXXX   |
   | 1282  | Reserved (0x502)                             | RFCXXXX   |
   | 1283  | DSL line status showtime (0x503)             | RFCXXXX   |
   | 1284  | DSL line status idle (0x504)                 | RFCXXXX   |
   | 1285  | DSL line status silent (0x505)               | RFCXXXX   |
   | 1286  | DSL line status training (0x506)             | RFCXXXX   |
   | 1287  | DSL line integrity error (0x507)             | RFCXXXX   |
   | 1288  | DSLAM resource not available (0x508)         | RFCXXXX   |
   | 1289  | Invalid test parameter (0x509)               | RFCXXXX   |
   +-------+-----------------------------------------------+-----------+
   +-------+----------------------------------------------+-----------+
         +-----------+-------------------------------+-----------+
         | Value     | Failure Response Message Name | Reference |
         +-----------+-------------------------------+-----------+
         | 8-9       | Unassigned                    |           |
         | 47-59     | Unassigned                    |           |
         | 86-127    | Unassigned                    |           |
         | 160-255   | Unassigned                    |           |
         | 256-1279  | Unassigned (ANCP use only)    |           |
         | 1290-4095 | Unassigned (ANCP use only)    |           |
         +-----------+-------------------------------+-----------+

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

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

    +----------------+-----------------------------------+-----------+
    | Function Value | Function Name                     | Reference |
    +----------------+-----------------------------------+-----------+
    | 0              | Reserved                          | RFCXXXX   |
    | 1-7            | Unassigned                        |           |
    | 8              | Configure Connection Service Data | RFCXXXX   |
    | 9              | Remote Loopback                   | RFCXXXX   |
    | 10-255         | Unassigned                        |           |
    +----------------+-----------------------------------+-----------+

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

           +---------+-------------+--------------+-----------+
           | Version | Sub-Version | Name         | Reference |
           +---------+-------------+--------------+-----------+
           | 3       | 1           | Pre-standard |           |
           | 3       | 2           | ANCPv1       | RFCXXXX   |
           +---------+-------------+--------------+-----------+

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

             +-----------------+----------------+-----------+
             | Tech Type Value | Tech Type Name | Reference |
             +-----------------+----------------+-----------+
             | 0               | Any technology | RFCXXXX   |
             | 1               | PON            | RFCXXXX   |
             | 2-4             | Unassigned     |           |
             | 5               | DSL            | RFCXXXX   |
             | 6-254           | Unassigned     |           |
             | 255             | Reserved       | RFCXXXX   |
             +-----------------+----------------+-----------+

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

     +--------------------+-----------------------------+-----------+
     | Command Code Value | Command Code Directive Name | Reference |
     +--------------------+-----------------------------+-----------+
     | 0                  | Reserved                    | RFCXXXX   |
     +--------------------+-----------------------------+-----------+

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

   +--------------+----------------------------------------+-----------+
   | Type Code    | TLV Name                               | Reference |
   +--------------+----------------------------------------+-----------+
   | 0x0000       | Reserved                               | RFCXXXX   |
   | 0x0001       | Access-Loop-Circuit-ID                 | RFCXXXX   |
   | 0x0002       | Access-Loop-Remote-Id                  | RFCXXXX   |
   | 0x0003       | Access-Aggregation-Circuit-ID-ASCII    | RFCXXXX   |
   | 0x0004       | DSL Line Attributes DSL-Line-Attributes                    | RFCXXXX   |
   | 0x0005       | Service-Profile-Name                   | RFCXXXX   |
   | 0x0006       | Access-Aggregation-Circuit-ID-Binary   | RFCXXXX   |
   | 0x0007       | OAM-Loopback-Test-Parameters           | RFCXXXX   |
   | 0x0008       | Opaque-Data                            | RFCXXXX   |
   | 0x0009       | OAM-Loopback-Test-Response-String      | RFCXXXX   |
   | 0x000a-0x001 | Unassigned                             |           |
   | 0            |                                        |           |
   | 0x0011       | Command                                | RFCXXXX   |
   | 0x0012-0x008 | Unassigned                             |           |
   | 0            |                                        |           |
   | 0x0081       | Actual-Net-Data-Upstream               | RFCXXXX   |
   | 0x0082       | Actual-Net-Data-Rate-Downstream        | RFCXXXX   |
   | 0x0083       | Minimum-Net-Data-Rate-Upstream         | RFCXXXX   |
   | 0x0084       | Minimum-Net-Data-Rate-Downstream       | RFCXXXX   |
   | 0x0085       | Attainable-Net-Data-Rate-Upstream      | RFCXXXX   |
   | 0x0086       | Attainable-Net-Data-Rate-Downstream    | RFCXXXX   |
   | 0x0087       | Maximum-Net-Data-Rate-Upstream         | RFCXXXX   |
   | 0x0088       | Maximum-Net-Data-Rate-Downstream       | RFCXXXX   |
   | 0x0089       | Minimum-Net-Low-Power-Data-Rate-Upstre | RFCXXXX   |
   |              | am                                     |           |
   | 0x008A       | Minimum-Net-Low-Power-Data-Rate-Downst | RFCXXXX   |
   |              | ream                                   |           |
   | 0x008B       | Maximum-Interleaving-Delay-Upstream    | RFCXXXX   |
   | 0x008C       | Actual-Interleaving-Delay-Upstream     | RFCXXXX   |
   | 0x008D       | Maximum-Interleaving-Delay-Downstream  | RFCXXXX   |
   | 0x008E       | Actual-Interleaving-Delay-Downstream   | RFCXXXX   |
   | 0x008F       | DSL line state DSL-Line-State                         | RFCXXXX   |
   | 0x0090       | Access Loop Encapsulation Access-Loop-Encapsulation              | RFCXXXX   |
   | 0x0091       | DSL-Type                               | RFCXXXX   |
   | 0x092-0x0105 | Unassigned                             |           |
   | 0x0106       | Status-info Status-Info                            | RFCXXXX   |
   | 0x0107-0x0FF | Unassigned                             |           |
   | F            |                                        |           |
   | 0x1000       | Target (single access line variant)    | RFCXXXX   |
   | 0x1001 -     | Reserved for Target variants           | RFCXXXX   |
   | 0x1020       |                                        |           |
   | 0x1021-0xFFF | Unassigned                             |           |
   | F            |                                        |           |
   +--------------+----------------------------------------+-----------+
   IANA is requested to create a new ANCP Capability registry, new ANCP Capability registry, with
   additions by IETF Consensus.  Values may range from 0 to 255.  The
   specification for a given capability MUST indicate whether it applies
   to a specific access technology or applies to all access
   technologies.  The specification MUST further indicate whether the
   capability is associated with any capability data.  The initial
   entries in the ANCP capability registry are as follows:

   +-------+-------------------+------------+--------------+-----------+
   | Value | Capability Type   | Technology | Capability   | Reference |
   |       | Name              |            | Data         |           |
   +-------+-------------------+------------+--------------+-----------+
   | 0     | Reserved          |            |              | RFCXXXX   |
   | 1     | DSL Topology      | DSL        | None         | RFCXXXX   |
   |       | Discovery         |            |              |           |
   | 2     | DSL Line          | DSL        | None         | RFCXXXX   |
   |       | Configuration     |            |              |           |
   | 3     | Reserved          |            |              | RFCXXXX   |
   | 4     | DSL Line Testing  | DSL        | None         | RFCXXXX   |
   | 5-255 | Unassigned        |            |              |           |
   +-------+-------------------+------------+--------------+-----------+

10.  Security Considerations

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

   o  The protocol solution MUST offer authentication of the AN to the
      NAS.

   o  The protocol solution MUST offer authentication of the NAS to the
      AN.

   o  The protocol solution MUST allow authorization to take place at
      the NAS and the AN.

   o  The protocol solution MUST offer replay protection.

   o  The protocol solution MUST provide data-origin authentication.

   o  The protocol solution MUST be robust against denial-of-service
      (DoS) attacks.  In this context, the protocol solution MUST
      consider a specific mechanism for the DoS that the user might
      create by sending many IGMP messages.

   o  The protocol solution SHOULD offer confidentiality protection.

   o  The protocol solution SHOULD ensure that operations in default
      configuration guarantees a low number of AN/NAS protocol
      interactions.

   Most of these requirements relate to secure transport of ANCP.
   Robustness against denial-of-service attacks partly depends on
   transport and partly on protocol design.  Ensuring a low number of
   AN/NAS protocol interactions in default mode is purely a matter of
   protocol design.

   For secure transport, either the combination of IPsec with
   additions by IETF Consensus.  Values may range from 0 IKEv2
   (references below) or the use of TLS [RFC5246] will meet the
   requirements listed above.  The deciding point is a detail of
   protocol design that was unavailable when [RFC5713] was written.  The
   ANCP adjacency is a major point of vulnerability for denial-of-
   service attacks.  If the adjacency can be shut down, either the AN
   clears its state pending reestablishment of the adjacency, or the
   possibility of mismatches between the AN's and NAS's view of state on
   the AN is opened up.  Two ways to 255. cause an adjacency to be taken down
   are to modify messages so that the ANCP agents conclude that they are
   no longer synchronized, or to attack the underlying TCP session.  TLS
   will protect message contents, but not the TCP connection.  One has
   to use either IPsec or the TCP authentication option [RFC5925] for
   that.  Hence the conclusion that ANCP MUST run over IPsec with IKEv2
   for authentication and key management.

   In greater detail: the ANCP stack MUST include IPsec [RFC4301]
   running in transport mode, since the AN and NAS are the endpoints of
   the path.  The
   specification Encapsulating Security Payload (ESP) [RFC4303] MUST be
   used, in order to satisfy the requirement for a given capability data confidentiality.
   ESP MUST indicate whether it applies
   to a specific access technology or applies to all access
   technologies. be configured for the combination of confidentiality,
   integrity, anti-replay capability.  The specification MUST further indicate whether traffic flow confidentiality
   service of ESP is unnecessary and, in fact, unworkable in the
   capability case of
   ANCP.

   IKEv2 [RFC5996] is associated with any capability data.  The initial
   entries also REQUIRED, to meet the requirements for mutual
   authentication and authorization.  Since the NAS and AN MAY be in
   different trust domains, the ANCP capability registry are as follows:

   +-------+-------------------+------------+--------------+-----------+
   | Value | Capability Type   | Technology | Capability   | Reference |
   |       | Name              |            | Data         |           |
   +-------+-------------------+------------+--------------+-----------+
   | 0     | Reserved          |            |              | RFCXXXX   |
   | 1     | DSL Topology      | DSL        | None         | RFCXXXX   |
   |       | Discovery         |            |              |           |
   | 2     | DSL Line          | DSL        | None         | RFCXXXX   |
   |       | Configuration     |            |              |           |
   | 3     | Reserved          |            |              | RFCXXXX   |
   | 4     | DSL Line Testing  | DSL        | None         | RFCXXXX   |
   | 5-255 | Unassigned        |            |              |           |
   +-------+-------------------+------------+--------------+-----------+

8.  Security Considerations

   Security use of certificates for mutual
   authentication could be the ANCP protocol most practical approach.  However, this
   is discussed in [RFC5713]

9. up to the operator(s) concerned.

   The AN MUST play the role of initiator of the IKEv2 conversation.

11.  Acknowledgements

   The authors would like to thank everyone who provided comments or
   inputs to this document.  Swami Subramanian was an early member of
   the authors' team.  The ANCP Working Group is grateful to Roberta
   Maglione, who served as design team member and primary editor of this
   document for two years before stepping down.  The authors acknowledge
   the inputs provided by Wojciech Dec, Peter Arberg, Josef Froehler,
   Derek Harkness, Kim Hyldgaard, Sandy Ng, Robert Peschi, and Michel
   Platnic.

10.

12.  References

10.1.

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3046]  Patrick, M., "DHCP Relay Agent Information Option",
              RFC 3046, January 2001.

   [RFC3292]  Doria, A., Hellstrand, F., Sundell, K., and T. Worster,
              "General Switch Management Protocol (GSMP) V3", RFC 3292,
              June 2002.

   [RFC3293]  Worster, T., Doria, A., and J. Buerkle, "General Switch
              Management Protocol (GSMP) Packet Encapsulations for
              Asynchronous Transfer Mode (ATM), Ethernet and
              Transmission Control Protocol (TCP)", RFC 3293, June 2002.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [RFC5234]  Crocker, D.

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

   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, Eronen,
              "Internet Key Exchange Protocol Version 2 (IKEv2)",
              RFC 5234, January 2008.

10.2. 5996, September 2010.

12.2.  Informative References

   [G.988.1]  "ITU-T recommendation G.998.1, ATM-based multi-pair
              bonding", 2005.

   [G.988.2]  "ITU-T recommendation G.998.2, Ethernet-based multi-pair
              bonding,", 2005.

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

   [TR_058]

   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
              Authentication Option", RFC 5925, June 2010.

   [TR-058]   Elias, M. and S. Ooghe, "DSL Forum TR-058, Multi-Service
              Architecture & Framework Requirements", September 2003.

   [TR_059]

   [TR-059]   Anschutz, T., "DSL Forum TR-059, DSL Evolution -
              Architecture Requirements for the Support of QoS-Enabled
              IP Services", September 2003.

   [TR_092]

   [TR-092]   DSL Forum (now the Broadband Forum), "DSL Forum TR-092,
              Broadband Remote access server requirements document",
              2005.

   [TR_101]

   [TR-101]   Cohen et al, "Architecture & Transport: "Migration to
              Ethernet Based DSL Aggregation", DSL Forum TR-101", 2005.

   [TR-147]   Voight et al, "Layer 2 Control Mechanism For Broadband
              Multi-Service Architectures", 2008.

   [US_ASCII]
              American National Standards Institute, "Coded Character
              Set - 7-bit American Standard Code for Information
              Interchange", ANSI X.34, 1986.

Authors' Addresses

   Sanjay Wadhwa
   Juniper Networks
   10 Technology Park Drive
   Westford, MA  01886
   USA
   Alcatel-Lucent

   Phone:
   Fax:
   Email: swadhwa@juniper.net sanjay.wadhwa@alcatel-lucent.com

   Jerome Moisand
   Juniper Networks
   10 Technology Park Drive
   Westford, MA  01886
   USA

   Phone:
   Fax:
   Email: jmoisand@juniper.net

   Thomas Haag
   Deutsche Telekom
   Heinrich-Hertz-Strasse 3-7
   Darmstadt,   64295
   Germany

   Phone: +49 6151 628 2088
   Fax:
   Email: haagt@telekom.de

   Norbert Voigt
   Nokia Siemens Networks
   Siemensallee 1
   Greifswald  17489
   Germany

   Email: norbert.voigt@nsn.com
   Tom Taylor (editor)
   Huawei Technologies
   Ottawa
   Canada

   Email: tom111.taylor@bell.net