Network Working Group                                         S.  Wadhwa
Internet-Draft                                                J. Moisand
Intended status: Standards Track                          S. Subramanian
Expires: August 30, 2010                        Juniper Networks
Expires: January 12, 2011                                       T.  Haag
                                                        Deutsche Telekom
                                                                N. Voigt
                                                  Nokia Siemens
                                                             R. Maglione
                                                          Telecom Italia
                                                       February 26, Networks
                                                          T. Taylor, Ed.
                                                     Huawei Technologies
                                                           July 11, 2010

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

Abstract

   This document describes proposed extensions to the GSMPv3 protocol to
   allow its use in a broadband environment, as a control plane Access Node Control Protocol (ANCP).
   ANCP operates between a Network Access Nodes (e.g.  DSLAM) Server (NAS) and Broadband Network Gateways an Access
   Node (e.g.
   NAS).  These proposed extensions are required to realize a protocol
   for "Access Node Control" mechanism as described Digital Subscriber Line Access Multiplexer (DSLAM)) in [ANCP-FRAMEWORK].
   The resulting protocol with the proposed extensions to GSMPv3
   [RFC3292] is referred a
   multi-service reference architecture in order to perform QoS-related,
   service-related and subscriber- related operations.  Use cases for
   ANCP are documented in RFC 5851.  As well as "Access Node Control Protocol" (ANCP).
   This describing the base ANCP
   protocol, this document currently focuses on specific use cases of access node
   control mechanism specifies capabilities for Digital Subscriber
   Line (DSL) topology discovery, line configuration, and OAM
   as described in line testing.
   The design of ANCP framework document [ANCP-FRAMEWORK].  It is
   intended anticipates the specification in other documents
   of extensions to be augmented by the protocol to support additional ANCP protocol specification for
   future
   capabilities covering other use cases considered in scope by the ANCP charter.

   ANCP framework document [ANCP-FRAMEWORK] describes the and other technologies.

   ANCP use-cases
   in detail.  Illustrative text for the use-cases is included here based on GSMPv3 (RFC 3292), but with many modifications and
   extensions, to
   help the protocol implementer understand point that the greater context of ANCP
   protocol interactions. two protocols are not
   interoperable.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts.
   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.
   This Internet-Draft will expire on August 30, 2010. January 12, 2011.

Copyright Notice

   Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . .  4  5
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4  5
     2.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5  6
   3.  Broadband Access Aggregation . . . . . . . . . . . . . . . . .  6  7
     3.1.  ATM-based broadband aggregation  . . . . . . . . . . . . .  6  7
     3.2.  Ethernet-based broadband aggregation . . . . . . . . . . .  7  9
   4.  Access Node Control Protocol -- General Aspects  . . . . . . .  9
     4.1.  Protocol Version . . . . . . . . . .  7
     4.1.  Overview . . . . . . . . . . . . . 10
     4.2.  ANCP Transport . . . . . . . . . . . .  8
     4.2.  ANCP based Access Topology Discovery . . . . . . . . . . 11
     4.3.  Use of the GSMPv3 Adjacency Protocol .  8
       4.2.1.  Goals . . . . . . . . . . 12
       4.3.1.  ANCP Adjacency Message Format  . . . . . . . . . . . . 12
       4.3.2.  ANCP Adjacency Procedures  . . . .  8
       4.2.2.  Message Flow . . . . . . . . . . 15
     4.4.  ANCP General Message Formats . . . . . . . . . . .  9
     4.3.  ANCP based Line Configuration . . . . 16
       4.4.1.  The ANCP Message Header  . . . . . . . . . . 10
       4.3.1.  Goals . . . . . 17
       4.4.2.  The ANCP Message Body  . . . . . . . . . . . . . . . . 20
   5.  ANCP Capabilities For Digital Subscriber Lines (DSL) . . . . . 10
       4.3.2.  Message Flow 22
     5.1.  Overview . . . . . . . . . . . . . . . . . . . . . 11
     4.4.  ANCP based OAM . . . . 22
       5.1.1.  ATM-Specific Considerations  . . . . . . . . . . . . . 22
       5.1.2.  Ethernet-Specific Considerations . . . . . 13
       4.4.1.  Message Flow . . . . . . 23
     5.2.  ANCP Based DSL Topology Discovery  . . . . . . . . . . . . 23
       5.2.1.  Goals  . . . 13
   5.  Access Node Control Protocol (ANCP) . . . . . . . . . . . . . 14
     5.1.  ANCP/TCP connection establishment . . . . . . . . 24
       5.2.2.  Message Flow . . . . 20
     5.2.  ANCP Connection keepalive . . . . . . . . . . . . . . . . 21
     5.3.  Capability negotiation . 24
       5.2.3.  Specification of the ANCP DSL Topology Discovery
               Capability . . . . . . . . . . . . . . . . . 22
     5.4.  GSMP Message Extensions for Access Node Control . . . . . 25
       5.4.1.  General Extensions
     5.3.  ANCP based DSL Line Configuration  . . . . . . . . . . . . 39
       5.3.1.  Goals  . . . . . . . . 25
       5.4.2.  Topology Discovery Extensions . . . . . . . . . . . . 27
       5.4.3.  Line Configuration Extensions . . . . 39
       5.3.2.  Message Flow . . . . . . . . . 37
       5.4.4.  OAM Extensions . . . . . . . . . . . . 40
       5.3.3.  Specification of the ANCP DSL Line Configuration
               Capability . . . . . . . . 40
       5.4.5.  Additional GSMP Extensions for future use cases . . . 43
         5.4.5.1.  General well known TLVs . . . . . . . . . . . 42
     5.4.  ANCP Based DSL Line Testing Capability . . 44
           5.4.5.1.1.  Target TLV . . . . . . . . 46
       5.4.1.  Message Flow . . . . . . . . . . . 44
           5.4.5.1.2.  Command TLV . . . . . . . . . . 46
       5.4.2.  Specification of the ANCP DSL Line  Testing
               Capability . . . . . . . 45
           5.4.5.1.3.  Status-info TLV . . . . . . . . . . . . . . . 47
         5.4.5.2.  Generic Response Message
   6.  Additional ANCP Messages and TLVs  . . . . . . . . . . . . . 48
     5.5.  ATM-specific considerations . 50
     6.1.  Additional Messages and General Messaging Principles . . . 51
       6.1.1.  General Principles for the  Design of ANCP Messages  . 51
       6.1.2.  Provisioning Message . . . . . . . . . . . . . 50
     5.6.  Ethernet-specific considerations . . . . 51
       6.1.3.  Generic Response Message . . . . . . . . . 50
   6.  IANA Considerations . . . . . . 52
     6.2.  TLVs For General Use . . . . . . . . . . . . . . . 51
   7.  Security Considerations . . . . 54
       6.2.1.  Target TLV . . . . . . . . . . . . . . . 56
   8.  Acknowledgements . . . . . . . 54
       6.2.2.  Command TLV  . . . . . . . . . . . . . . . . 56
   9.  References . . . . . 55
       6.2.3.  Status-Info TLV  . . . . . . . . . . . . . . . . . . . 55
   7.  IANA Considerations  . . 56
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 56
     9.2.  Informative References
     7.1.  Summary  . . . . . . . . . . . . . . . . . . 56
   Authors' Addresses . . . . . . . 57
     7.2.  IANA Actions . . . . . . . . . . . . . . . . . . . . . . . 57

1.  Specification Requirements

   The key words "MUST", "MUST
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 62
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 62
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 62
     10.2. Informative References . . . . . . . . . . . . . . . . . . 63
   Appendix A.  Changes from Version -09 to Version -10 . . . . . . . 63
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 65

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

   DSL is a widely deployed access technology for Broadband Access for
   Next Generation Networks.  Several specifications like [TR-059],
   [TR-058], [TR-092] describe possible architectures for these access
   networks.  In the scope of these specifications are the delivery of
   voice, video and data services.

   When deploying value-added services across DSL access networks,
   special attention regarding quality of service and service control is
   required, which implies a tighter coordination between network
   elements in the broadband access network without burdening the OSS
   layer.

   This draft defines extensions and modifications to GSMPv3 (specified
   in [RFC3292]) and certain a new mechanisms 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 layer2 layer 2 Access
   Node (e.g. (e.g., Digital Subscriber Line Access Module, DSLAM) in order to
   perform QoS-related, service- related and subscriber-related
   operations.  The control protocol specification takes GSMPv3 [RFC3292] as a
   result of these extensions
   starting point and mechanisms is referred specifies modifications and extensions to as "Access
   Node Control Protocol" (ANCP). GSMPv3
   to achieve ANCP requirements.  Although ANCP is based on GSMPv3, it
   is the
   two protocols are not interoperable with GSMPv3 defined in [RFC3292]. interoperable.

   This specification assumes ANCP uses the option of transporting GSMPv3 transport over TCP/IP.  TCP
   encapsulation for GSMPv3 ANCP is as defined for GSMPv3 in [RFC3293].  GSMPv3  ANCP
   encapsulation directly over Ethernet and ATM as defined for GSMPv3 in
   [RFC3293] is not considered for ANCP. considered.

   ANCP uses a subset of GSMPv3 messages messages, message content, and
   procedures to implement currently defined
   use-cases.  These relevant GSMPv3 messages are identified in section
   Section 5.  GSMPv3 use cases.  Additional ANCP
   messages, message content, and procedures with suitable extensions, as used by
   ANCP, are described specified in sections Section 5.1, Section 5.2 and
   Section 5.3.  GSMPv3 general extensions this
   document and GSMPv3 message specific
   extensions required by ANCP are described may also be specified in sub-sections other documents extending ANCP.

   The organization of
   Section 5.4.  In addition to specifying extensions and modifications
   to relevant GSMP messages applicable to ANCP, this draft also defines document is as follows:

   o  The next sub-section introduces some terminology that will be
      useful in understanding the usage rest of these messages by ANCP.  Not all the fields in relevant
   GSMP messages are used by ANCP.  This draft indicates document.

   o  Section 3 provides a description of the value that access networks within
      which ANCP should set for will typically be deployed.

   o  Section 4 specifies generally applicable aspects of the fields in these GSMP messages.

   At ANCP
      protocol.

   o  Section 5 describes and specifies the time ANCP implementation of writing three
      capabilities applicable to the control of this specification some implementations 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 ANCP protocol, based base protocol.

   o  Section 7 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 addresses security considerations relating to ANCP, with
      heavy reliance on [RFC5713].

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

   At the time of writing of this specification some implementations of
   the ANCP protocol based on pre-standards drafts are already
   available.  All these  These early-draft implementations use protocol
   version/sub-version 3.1; version/
   sub-version 3.1.  The standard ANCP protocol will use version/
   sub-version 3.2 [Editor's note: sub-version needs to be changed from
   1 to 2 upon publication.] Adopting a new sub-version value provides a way to
   disambiguate the two protocols and allows provides support for supporting 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 details detail in Section 5.2.  It is important to note
   that 4.3.  NOTE: this mechanism does
   not guarantee backwards compatibility of the published ANCP RFC
   specification to with those early-draft implementations.

2.1.  Terminology

   o

   Access Node (AN):  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 DSL Access
      Multiplexer (DSLAM).

   o

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

   o

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

   o

   Net Data Rate:  portion of the total data rate of the DSL line that
      can be used to transmit actual user information (e.g.  ATM cells
      of Ethernet frames).  It excludes overhead that pertains to the
      physical transmission mechanism (e.g. trellis coding in case of
      DSL).  This is defined in section 3.39 of ITU-T G.993.2.

   o

   DSL line (synch) rate:  the total data rate of the DSL line,
      including the overhead attributable to the physical transmission
      mechanism.

   o

   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" "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 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 4.4.2.  The value field of a TLV can contain
      other TLVs.  An IANA registry is maintained for values of the ANCP
      TLV Type field.

   ANCP Protocol Capability:  A detailed specification of ANCP messages,
      message content, and procedures required to implement a specific
      use case or set of use cases.  ANCP capabilities may be specific
      to one access technology or technology independent.  The set of
      capabilities applicable to a given ANCP session are negotiated
      during session startup.

   ANCP session (adjacency):  A session between a NAS and an Access
      Node, beginning with the initiation of the transport connection by
      the AN, passing through adjacency negotiation, discovery and
      provisioning stages, and continuing with service control and
      possible OAM operations until the transport connection is
      terminated.  There may be more than one ANCP session active
      between the NAS and a given AN due to partitioning.

3.   Broadband Access Aggregation

3.1.  ATM-based broadband aggregation

   End

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

   The Regional/Access Network consists of the Regional Network, Network
   Access Server, and the Access Network as show shown in Figure 1.  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 could consist of DSLAM may be in the form of a DSLAM in the central office,
   or a remote DSLAM, or a Remote Access Multiplexer (RAM).  Access  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 the subscriber traffic.  It provides aggregation
   capabilities (e.g.  IP, PPP, ATM) between the Regional/Access Network
   and the NSP or ASP.  These include traditional ATM-based offerings
   and newer, more native IP-based services.  This includes support for
   Point-to-Point Protocol over ATM (PPPoA) and PPP over Ethernet
   (PPPoE), as well as direct IP services encapsulated over an
   appropriate layer 2 transport.

   Beyond aggregation, the NAS is also the injection point for policy
   management and IP QoS in the Regional/Access Networks.  In order to  To allow IP
   QoS support over an existing non-IP-aware layer 2 access network
   without using multiple layer 2 QoS classes, a mechanism based on
   hierarchical scheduling is used.  This mechanism mechanism, defined in
   [TR-059],
   [TR_059], preserves IP QoS over the ATM network between the NAS and
   the RGs routing gateway (RG) at the edge of the subscriber network, by
   carefully controlling downstream traffic in the NAS, so that
   significant queuing and congestion does not occur further down the
   ATM network.  This is achieved by using a diffserv-aware hierarchical
   scheduler in the NAS that will account for downstream trunk
   bandwidths and DSL synch rates.

   [ANCP-FRAMEWORK]

   [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| | +---+ | +-----+ | Node | | ||Modem| +---+ |Devices   ||
   |Broadband| | +---+ |         +------+ | |+-----+       +----------+|
ASP|Network  |-+-|NAS| +--------------|---+ +--------------------------+
---+         | | +---+                |     +--------------------------+
   |         | | +---+                |     |+-----+ +---+ +----------+|
   +---------+ +-|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.  The Ethernet
   aggregation network provides traffic aggregation, class of service
   distinction, and customer separation and traceability.  VLAN tagging
   defined in IEEE 802.1Q and being enhanced by IEEE 802.1ad is used as
   standard virtualization mechanism in the Ethernet aggregation
   network.  The aggregation devices are "provider edge bridges" defined
   in IEEE 802.ad.  Stacked VLAN tags provide one possible way to create
   equivalent of "virtual paths" and "virtual circuits" in the
   aggregation network.  The "outer" vlan could be used to create a form
   of "virtual path" between a given DSLAM and a given NAS.  And "inner"
   VLAN tags to create a form of "virtual circuit" on a per DSL line
   basis.  This is 1:1 VLAN allocation model.  An alternative model is
   to bridge sessions from multiple subscribers behind a DSLAM into a
   single VLAN in the aggregation network.  This is N:1 VLAN allocation
   model.  Architectural and topological models of an Ethernet
   aggregation network in context of DSL aggregation are defined in
   [TR-101]
   [TR_101]

4.  Access Node Control Protocol
4.1.   Overview

   A dedicated control protocol between NAS and access nodes can
   facilitate "NAS managed" tight QOS control in the access network,
   simplified OSS infrastructure for service management, optimized
   multicast replication to enable video services over DSL, subscriber
   statistics retrieval on the NAS for accounting purposes, and fault
   isolation capability on the NAS for the underlying access technology. -- General Aspects

   This dedicated control plane is referred to as "Access section specifies aspects of the Access Node Control
   Protocol" (ANCP).  This document specifies relevant 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 basic GSMPv3 as protocol.  Moreover, ANCP uses only a
   subset of the messages, message contents, and procedures defined for
   GSMPv3.

   The following are the only GSMPv3 [RFC3292] to realize messages that are
   currently used by ANCP.

   Following sections discuss

   Event Messages

      *  Port UP Message

      *  Port DOWN Message

      These messages are used by the use of ANCP for implementing:

   o  Dynamic discovery of access topology discovery capability.

   Port Management Messages  These messages are used by the NAS ANCP "line
      configuration" and ANCP "line testing" capabilities.

   Adjacency Protocol Messages  These messages are used to provide tight
      QOS control bring up a
      protocol adjacency between a NAS and an AN.

   ANCP modifies and extends some basic GSMPv3 procedures.  These
   modifications and extensions are summarized below, and described in
   more detail in the access network. succeeding sections.

   o  Pushing to the access-nodes, subscriber and service data retrieved  ANCP provides support for a capability negotiation mechanism
      between ANCP peers by extending the NAS from an OSS system (e.g. radius server), to simplify
      OSS infrastructure for service management.

   o  Optimized, "NAS controlled GSMPv3 adjacency protocol.
      This mechanism and managed" multicast replication by
      access-nodes at L2 layer. corresponding adjacency message extensions are
      defined in section Section 4.3.

   o  NAS controlled, on-demand access-line test capability (rudimentary
      end-to-end OAM).

   In addition to DSL, alternate broadband access technologies (e.g.
   Metro-Ethernet, Passive Optical Networking, WiMax) will have similar
   challenges to address, and could benefit  The TCP connection establishment procedure in ANCP deviates
      slightly from connection establishment in GSMPv3 as specified in
      [RFC3293].  This is described in section Section 4.2.

   o  ANCP adds content to GSMPv3 messages in the same approach form of a
   control plane between a NAS additional
      fixed fields and an Access Node (e.g.  OLT), providing
   a unified control Type-Length-Value (TLV) structures.  TLVs also
      provide flexibility to both GSMPv3 and management architecture for multiple access
   technologies, hence facilitating migration ANCP-specific messages
      because their order and whether or not specific TLVs are present
      can vary from one message instance to the other
   and/or parallel deployments. next.

4.1.  Protocol Version

   GSMPv3 is messages contain an ideal fit 8-bit protocol version field.  As
   described below, ANCP subdivides this into two 4-bit sub-fields, for implementing ANCP.  It is extensible
   version and
   can be run over TCP/IP, which makes it possible to run over different
   access technologies.

4.2. sub-version.  Implementations of this version of the ANCP based Access Topology Discovery

4.2.1.   Goals

   [TR-059] discusses various queuing/scheduling mechanisms
   specification MUST set the version sub-field to avoid
   congestion in 3 and the access network while dealing with multiple flows
   with distinct QoS requirements.  Such mechanisms require that sub-version
   sub-field to 1.  That is, the NAS
   gains knowledge about hexadecimal representation of the topology value
   of the access network, complete protocol version field MUST be 0x31.

   RFC EDITOR'S NOTE: please change the various
   links being used and their respective net data rates.  Some value of the
   information required is somewhat dynamic sub-version in nature (e.g.  DSL sync
   rate, and therefore also the net data rate), hence cannot come from
   above paragraph to 2 (respectively a
   provisioning and/or inventory management OSS system.  Some of the
   information varies less frequently (e.g. capacity version field value of a DSLAM uplink),
   but nevertheless needs to be kept strictly 0x32) in sync between the actual
   capacity of the uplink and
   the image published specification.  For an explanation see the NAS has of it.

   Following section describes Introduction
   above.

4.2.  ANCP messages that allow the Access Node
   (e.g.  DSLAM) to communicate to Transport

   This document specifies the NAS, access network topology
   information and any corresponding updates.

   Some use of TCP/IP for transport of ANCP
   messages.  Other specifications may introduce additional transports
   in the parameters that can be communicated from the DSLAM to future.

      In the
   NAS include DSL line state, actual upstream and downstream net data
   rates case of ATM access, a synchronized DSL link, maximum attainable upstream and
   downstream net data rates, interleaving delay etc.  Topology
   discovery is specifically important in case the net data rate separate PVC (control channel)
      capable of the
   DSL line changes over time.  The DSL net data rate transporting IP may be different
   every time the DSL modem is turned on.  Additionally, during configured between NAS and the time
      AN for ANCP messages.

      In the DSL modem is active, data rate changes can occur due to
   environmental conditions (the DSL line can get "out case of sync" and can
   retrain to a lower value).

4.2.2.  Message Flow

   When an Ethernet access/aggregation network, a DSL line initially comes up or resynchronizes typical
      practice is to a different
   rate, send the DSLAM generates and transmits Access Node Control Protocol messages over
      a GSMP PORT UP EVENT message
   to the NAS.  The extension field in the message carries dedicated Ethernet virtual LAN (VLAN) using a separate VLAN
      identifier (VLAN ID).

   When transported over TCP, ANCP messages MUST use the TLVs
   containing DSL line specific parameters.  On encapsulation
   specified for GSMPv3 messages carried over TCP in [RFC3293].  This
   encapsulation consists of a loss four-byte header field prepended to the
   ANCP message as shown in Figure 2.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Identifier (0x880C)        |           Length              |
      |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                         ANCP Message                          ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 2: Encapsulation of ANCP Messages Over TCP/IP

   The fields of signal on the
   DSL line, encapsulating header are as follows:

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

   Length:  This 2-byte unsigned integer indicates the total length of
      the ANCP message only.  It does not include the 4-byte
      encapsulating header.

   The Access Node MUST initiate the TCP session to the NAS.  In order  This is
   necessary to provide expected service level, avoid static provisioning on the NAS needs for all the ANs
   that are being served by the NAS.  It is easier to learn configure a given
   AN with the initial attributes single IP address of the DSL line before NAS that serves the subscriber can log
   in and access AN.  This is
   a deviation from [RFC3293], which indicates that the provisioned services for controller
   initiates the subscriber.  Figure 2
   summarizes TCP connection to the interaction.

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

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

            <----- Port UP (EVENT Message)  <----- DSL
                  (updated line parameters)      Resynch
   2. switch.

   The NAS ------------------ MUST listen for incoming connections from the Access ----------- Home ------ Subscriber
                               Node             Gateway

           <--- Nodes.
   Port DOWN (EVENT Message) <---- DSL
                                              Loss of Signal

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

       Figure 2: Message flow (ANCP mapping) for topology discovery

   The Event message with PORT UP message type (80) 6068 is used for
   conveying DSL line attributes TCP connection.

   In the event of an ANCP transport protocol failure, all pending ANCP
   messages destined to the NAS.  This message with relevant
   extensions disconnected recipient SHOULD be discarded
   until the transport is defined in section Section 5.4.2. re-established.

4.3.  ANCP based Line Configuration

4.3.1.   Goals

   Following dynamic discovery of access topology (identification  Use of DSL
   line and its attributes) as assisted by the mechanism described in GSMPv3 Adjacency Protocol

   Section 11 of [RFC3292] defines the previous section (topology discovery), GSMPv3 adjacency protocol.  ANCP
   reuses the NAS could then query a
   subscriber management OSS system (e.g.  RADIUS server) GSMPv3 adjacency protocol to retrieve
   subscriber authorization data (service profiles, aka user
   entitlement).  Most of such service mechanisms are typically enforced
   by synchronize the NAS itself, but there are a few cases where it might be useful
   to push such service parameter to and
   Access Nodes and maintain the DSLAM for local enforcement of
   a mechanism (e.g.  DSL-related) on ANCP session.  After the corresponding subscriber line.
   One such example of a service parameter that can TCP connection
   is established, adjacency protocol messages MUST be pushed exchanged as
   specified in Section 11 of [RFC3292], subject to the
   DSLAM for local enforcement is DSL "interleaving delay".  Longer
   interleaving delay (and hence stringent error correction) is required
   for a video service to ensure better video "quality additional
   specifications of experience",
   whereas for a VoIP service or for "shoot first" gaming service, a
   very short interleaving delay is more appropriate.  Another relevant
   application this section.  ANCP messages other than adjacency
   protocol messages MUST NOT be sent until the adjacency protocol has
   achieved synchronization.

4.3.1.  ANCP Adjacency Message Format

   The GSMPv3 adjacency message format defined in Section 11 of
   [RFC3292] is downloading per subscriber multicast channel
   entitlement information modified and extended for ANCP as shown in Figure 3
   below.  The 8-bit "version" field in IPTV applications where the DSLAM GSMPv3 adjacency protocol
   messages is
   performing IGMP snooping or IGMP proxy function.  Using ANCP, the NAS
   could achieve the goal of pushing line configuration to the DSLAM by
   an interoperable and standardized protocol.

   If a subscriber wants modified to choose a different service, it can require
   an OPEX intensive reconfiguration of carry the line via a network operator,
   possibly implying a business-to-business transaction between an ISP
   and an access provider.  Using ANCP version (four bits) and sub-
   version (four bits).  See Section 4.1 for line configuration from the
   NAS dramatically simplifies the OSS infrastructure values to set for service
   management, allowing fully centralized subscriber-related service
   data (e.g.  RADIUS server back-end)
   version and avoiding complex cross-
   organization B2B interactions.

   The best way to change line parameters would be by using profiles.
   These profiles (DSL profiles sub-version for different services) are pre-
   configured on the DSLAMs.  The NAS can then indicate a reference present version of this
   specification.  In addition to the right DSL profile via ANCP.  Alternatively, discrete DSL
   parameters can also be conveyed by modification of the NAS in ANCP.

4.3.2.  Message Flow

   Triggered by topology information reporting a version field,
   ANCP adds several new DSL line or
   triggered by a subsequent user session establishment (PPP or DHCP),
   the NAS may send line configuration information (e.g. reference to a
   DSL profile) to fields.  These are described below the DSLAM using GSMP Port Management messages.  The
   NAS may get such line configuration data from a policy server (e.g.
   RADIUS).  Figure figure.

       0                   1                   2                   3 summarizes the interaction.

                                  1.DSL Signal
                                   <-----------
           2. Port UP (EVENT Message)
          (Access Topology Discovery)
                  <----------------
                              3. PPP/DHCP Session
                    <--------------------------------
     4. Authorization
    & Authentication
     <-------------------
                    Port Management Message
                    (Line Configuration)
                  5. -------->
   +----------+   +-----+     +-----+    +-------+    +-----------+
   |Radius/AAA|---| NAS |-----| AN  |----|  Home |----|Subscriber
       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   Ver |   +-----+     +-----+    |Gateway|    +-----------+
   |Server  Sub  |                          +-------+
   +----------+

   Figure 3: 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 4 summarizes
   the interaction.

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

     +-----------+                      2. Service On Demand
     |           |<----------------------------------------------- Type  | Web portal|     Timer     |M|     Code    |  OSS etc
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 3.Change of   4.Port Management                          Sender Name                          |
      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Authorization   Message
     |Radius AAA                               | -------->     (Updated Line                               |  Policy
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      |                Config - New Profile)                         Receiver Name                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          ------------->                          Sender Port                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    +------+     +-------+   +---------+  +----------+                         Receiver Port                         |           |----| NAS  |-----|  AN   |---|  Home   |--|Subscriber|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | PType |    +------+     +-------+ PFlag | Gateway               Sender Instance                 |  +----------+
     +-----------+                             +---------+

   Figure 4: Message flow - ANCP mapping for Updated Line Configuration

   The format
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Partition ID  |              Receiver Instance                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Tech Type     | # of relevant extensions to port management message is
   defined in section Caps     | Total Length                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                   Capability Fields                           ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 3

   [Editor's Note: it seems likely this text and Section 5.4.3.  The line configuration models
   could be viewed as a form of delegation of authorization from the NAS 4.3 will have
   to the DSLAM.

4.4.  ANCP based OAM

   In a mixed Ethernet and ATM access network (including the local
   loop), it is desirable be modified 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 on ANCP can provide NAS with an access-line
   test multiple capability and to some extent fault isolation.  Controlled sets (for different
   Tech Type values).]

   The fields added by a
   local management interface the NAS can use an ANCP operation to
   trigger are as follows:

   Tech Type:  indicates the access-node technology to perform a loopback test on the local-loop
   (between which the access-node and capability
      extension applies.  An IANA registry is maintained for possible
      values of the CPE).  The access-node can respond
   via another ANCP operation Tech Type field.  This specification assigns the result
      Tech Type value 0x05 to DSL.

   # of Caps:  indicates the triggered loopback test.
   In case number of ATM based local-loop capability fields that follow.

   Total Length:  indicates the ANCP operation can trigger total number of bytes occupied by the
   access-node to generate ATM (F4/F5) loopback cells on
      capability fields that follow.

   Capability Fields:  Each capability field indicates one ANCP
      capability supported by the local loop.
   In case sender of Ethernet, the access-node can trigger an Ethernet loopback
   message(per EFM OAM) on the local-loop.

4.4.1.  Message Flow

   "Port Management" message can be used by the NAS to request access
   node to trigger adjacency message.
      Negotiation of a "remote loopback" test on the local loop.  The
   result common set of the loopback test can be asynchronously conveyed by the
   access node capabilities to be supported within
      the NAS ANCP session is described in a "Port Management" response message. Section 4.3.2.  The detailed
      format of relevant extensions to port management message a capability field is defined
   in section described below.

   The format of relevant extensions to port management
   message is defined in section Section 5.4.4.  Figure 5 summarizes the
   interaction.

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

                  Figure 5: Message Flow: ANCP based OAM

5.  Access Node Control Protocol (ANCP)

   ANCP uses a subset of GSMPv3 messages described in [RFC3292] to
   implement currently defined use-cases.  GSMPv3 general message
   format, used by all GSMP messages other than adjacency protocol
   messages, capability field is defined shown in section 3.1.1 of GSMPv3 [RFC3292].  ANCP
   modifies this base GSMPv3 message format.  The modified GSMPv3
   message format is defined as follows: 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Vers  |  Sub  | Message     Capability Type           | Result|        Code   Capability Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Partition ID  |            Transaction Identifier             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |I|      SubMessage Number      |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                          Message Payload                      ~
      |                                                               |
      ~                                                               ~
      ~                   Capability Data                             ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 6: Modified GSMPv3 message format 4: Capability Field

   The 8-bit version field in the base GSMPv3 message header is split
   into two 4 bit fields for carrying the version and a sub-version of
   the GSMP protocol.  ANCP uses version 3 and sub-version 1 sub-fields of this structure are as follows:

   Capability Type:  indicates the GSMP
   protocol. specific capability supported.  An ANCP implementation SHOULD always set the version field
   to 3, and the sub-version field to 1.  The Result field in the
   message header has been modified to be 4 bits long, and the Code
   field to be 12 bits long.

   Version:

        The version number
      IANA registry exists for values of the GSMP protocol being used in this
        session.  ANCP uses version 3.

   Sub-Version: sub-field.  The sub-version values
      specified by this document are listed below.

   Capability Length:  the number of the GSMP protocol being used bytes of data contained in this
        session.  ANCP uses sub-version 1 the
      Capability Data sub-field, excluding padding.  If the definition
      of a particular capability includes no capability data, the GSMP protocol.  [RFC
        Editor's note: sub-version needs to be changed from 1 to 2 upon
        publication]

   Result:

      The Result field derived from GSMP [RFC3292] has value
      of the following
      codes:

         Ignore:

            Res = 0x00 - Ignore this field on receipt and follow Capability Length sub-field is zero.

   Capability Data:  contains data associated with the
            procedures capability as
      specified for the received message type.

         Nack:

            Res = 0x01 - Result code indicating that no response is
            expected to capability.  If the message other than in cases definition of failure
            caused during a particular
      capability includes no capability data, the processing of Capability Data sub-
      field is absent (has zero length).  Otherwise, the message contents Capability Data
      sub-field MUST be padded with zeroes as required to terminate on a
      4-byte word boundary.  The possibility of specifying capability
      data provides the flexibility to advertise more than the mere
      presence or that absence of a capability if needed.

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

   1.  Capability Type : DSL Topology Discovery = 0x01
          Length (in bytes) : 0

          Capability Data : NULL

       For the contained directive(s).

         AckAll:

            Res detailed protocol specification of this capability see
       Section 5.2.

   2.  Capability Type : DSL Line Configuration = 0x02 - Result code indicating that a response to

          Length (in bytes) : 0

          Capability Data : NULL

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

   3.  Capability Type : DSL Line Testing = 0x04

          Length (in bytes) : 0

          Capability Data : NULL

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

4.3.2.  ANCP Adjacency Procedures

   The NAS MUST set the M-flag in the SYN message (signifying it is requested in all cases.  It the
   master).  Once the adjacency is specifically
            intended established, periodic adjacency
   messages (type ACK) MUST be exchanged.  The default for the ACK
   interval to be used advertised in some cases for Request the adjacency messages only,
            and is not to 10 sec for
   ANCP.  The actual value SHOULD be used in Event messages.

         Success:

            Res = 0x03 - Set by receiver configurable and is an
   implementation choice.  It is RECOMMENDED that both ends specify the
   same timer value; to indicate successful
            execution of all directives in achieve this, each end SHOULD compare the corresponding Request
            message.

         Failure:

            Res = 0x4 - Set by receiver timer
   value in the Response first adjacency message if one
            or more directives in the corresponding Request message
            fails.

   Message-Type:

      The GSMP it receives with its own
   preferred value and ANCP message type.

   Code:

      This field gives further information concerning the result in a
      response message.  It is mostly used agree to pass an error code in use the higher of the two values.  That
   is, the node that receives a
      failure response but can also be used to give further information higher timer value than its own SHOULD
   reply in a success response message or an event message.  In a request
      message, its subsequent adjacency messages (such as SYNACK, ACK) with
   the code field is not used and is set to zero. higher timer value.

   In an the adjacency protocol message, the Code field is used to determine the function of version and the message.

      ANCP implementations MAY use any of sub-version fields are
   used for version negotiation.  The version negotiation is performed
   before synchronisation is achieved.  In a SYN message the Code values specified in version/
   sub-version fields always contain the IANA registry "Global Switch Management Protocol highest version 3
      (GSMPv3) Failure Response Message Name Space" if they appear
      applicable.  In particular, understood by
   the values:

      2  Invalid request sender.  A receiver receiving a SYN message (i.e., with a properly formed version/
   sub-version higher than it understands MUST silently discard that
   message.  A receiver receiving a SYN message which
         violates with a version/
   sub-version within the protocol through its timing or direction of
         transmission)

      4  One or more range of versions that it understands MUST
   reply with a SYNACK with the specified ports do not exist

      6  One or more of version/sub- version from the specified ports are down

      7  Invalid Partition ID

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

      30 The limit on the maximum number of point-to- multipoint
         connections that the switch can support has been reached

      31 The limit on received
   SYN in its ANCP version/sub-version fields.  This defines the maximum number
   version/sub-version of branches that the specified
         point-to-multipoint connection can support has been reached

   may unfortunately apply ANCP protocol to be used while the
   adjacency remains synchronised.  All other ANCP usage, including messages within the case where
   "Port" is interpreted to mean Target
   session MUST use the agreed version in the version/sub-version
   fields.

   The semantics and suggested values for Code, "Sender Name", "Receiver
   Name", "Sender Instance", and "Receiver Instance" fields are as
   defined in section Section 5.4.5.1.1

   Instead 11 of the value:

   3 [RFC3292].  The specified request is not implemented on this switch

   specified "Sender Port", and "Receiver
   Port" SHOULD be set to 0 by [RFC3292], this specification defines a new value:

   81 Request message type both ends.  The pType field SHOULD be set
   to 0 (No Partition).  The pFlag SHOULD be set to 1 (New Adjacency).

   If the adjacency times out on either end, due to not implemented

   This receiving an
   adjacency message for a duration of (3 * Timer value), where the
   timer value MAY be sent is specified in a failure response from either the AN or adjacency message, all the NAS.  This specification also defines state
   received from the additional values:

   82 Transaction identifier out of sequence

   83 Malformed message

   84 TLV or value not supported by negotiated capability set ANCP extensions defining new code values neighbor SHOULD use be cleaned up, and the range 0x0100
   through 0x01ff for this purpose. TCP
   connection SHOULD be closed.  The range of values from 256 NAS MUST continue to 4095 is reserved listen for IETF use.

   Partition ID:

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

      AN and NAS MAY agree on the partition ID using one of the
      following possible options:

      1 - new
   connection requests.  The partition ID could be configured on the AN MUST try to re-establish the TCP
   connection and learnt by
      NAS in both sides MUST attempt to re-establish the adjacency message;

      2 - adjacency.

   The partition ID could handling defined above will need some modifications when ANCP
   graceful restart procedures are defined.  These procedures will be statically configured on
   defined in a separate draft.

   Both the NAS as
      part of configuring and the neighbor information.

   Transaction ID:

      24-bit field set by Access Node MUST advertise supported
   capabilities in the sender of a Request message to associate adjacency messages they send.  If a
      Response received
   adjacency message with the original Request message.  The receiver
      of indicates no support for a Request message reflects capability that is
   supported by the transaction ID from receiving device, it MUST turn off the Request capability
   locally and MUST send an updated adjacency message in with the
   corresponding Response message.  For event
      messages, the transaction identifier SHOULD be set capability field omitted to zero.  The
      Transaction Identifier is not used, and match the field is not present, received
   capability set.  This process will eventually result in both sides
   agreeing on the adjacency protocol.

   I flag:

      An ANCP implementation SHOULD minimal set "I" and subMessage fields to 1
      to signify no fragmentation.

   Length:

      Length of supported capabilities.  The adjacency
   MUST NOT come up unless the GSMP message including its header fields capabilities advertised by the controller
   and defined
      GSMP message body.

   Additional General Message Information:

   o  Any field in the controlled device match.

   After initial synchronization, if at any time a GSMP message that capability mismatch
   is unused or defined as
      "reserved" detected, the adjacency MUST be set to zero brought down (RSTACK MUST be
   generated by the sender and ignored by device detecting the
      receiver;

   o  Flags that are undefined will mismatch), and synchronization
   MUST be designated as: x: reserved.

   Following are re-attempted.

4.4.  ANCP General Message Formats

   This section describes the relevant GSMPv3 general format of ANCP messages defined in [RFC3292], that
   are currently used by ANCP.  Other other than
   the message types explicitly
   listed below, no other adjacency messages.

   The GSMPv3 messages are used by ANCP currently.

   o  Event Messages

      *  Port UP Message

      *  Port DOWN Message

      These messages are used by ANCP topology discovery use-case.

   o  Port Management Messages

      *  These messages are general message format, used by ANCP "line configuration" use-case
         and ANCP OAM use-case.

   o  Adjacency Protocol Messages

      *  These all GSMP messages are used to bring up a protocol adjacency
         between a NAS and an AN.

   ANCP modifies and extends few basic GSMPv3 procedures.  These
   modifications and extensions are summarized below, and described in
   more detail in the succeeding sections.

   o  ANCP provides support for a capability negotiation mechanism
      between ANCP peers by extending the GSMPv3 adjacency protocol.
      This mechanism and corresponding other
   than adjacency message extensions are protocol messages, is defined in section Section 5.3

   o  TCP connection establishment procedure in 3.1.1 of
   GSMPv3 [RFC3292].  ANCP deviates slightly
      from the connection establishment in modifies this base GSMPv3 message format as specified in
      [RFC3293].  This is described
   shown in section Section 5.1

   o  ANCP makes GSMPv3 messages extensible and flexible by adding a
      general "extension block" to the end of the relevant GSMPv3
      messages.  The "extension block" contains a TLV structure to carry
      information relevant to each ANCP use-case.  The format of the
      "extension block" is defined in section Section 5.4.1.1.

   o

5.1.  ANCP/TCP connection establishment

   ANCP will use TCP for exchanging protocol messages [RFC3293]. defines
   the GSMP message encapsulation for TCP.  The TCP session is initiated
   from the DSLAM (access node) to the NAS (controller).  This is
   necessary to avoid static provisioning on the NAS for all the DSLAMs
   that are being served by the NAS.  It is easier to configure a given
   DSLAM with the single IP address of the NAS that serves the DSLAM.
   This is a deviation from [RFC3293] which indicates that the
   controller initiates the TCP connection to the switch.

   When GSMP messages are sent over a TCP connection a four-byte TLV
   header field is prepended to the GSMP message to provide delineation
   of GSMP messages within the TCP stream. 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 (0x88-0C)  | Result|        Code           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Partition ID  |            Transaction Identifier             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |I|      SubMessage Number      |           Length              |
      |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                         GSMP                          Message Payload                      ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 7: 5: ANCP General Message Format

4.4.1.  The ANCP Message Header

   The immediately visible differences from GSMPv3 with TCP/IP Encapsulation message format

   Type

        This 2-byte are the subdivision
   of the Version field indicates into version and sub-version, and the type code
   reallocation of space between Result and Code to enlarge the following
        message.  The type code range
   for GSMP messages is 0x88-0C (i.e., Code.  The 8-bit version field in the
        same as GSMP's Ethertype).

   Length
        This 2-byte unsigned integer indicates base GSMPv3 message header
   is split into two 4 bit fields for carrying the total length version and a sub-
   version of the
        GSMP ANCP protocol.  The Result field in the message only.  It does not include the 4-byte TLV header.

   NAS listens for incoming connections from header
   has been modified to be 4 bits long, and the access nodes.  Port
   6068 is used for TCP connection.  Adjacency protocol messages, which
   are used Code field to synchronize be 12 bits
   long.

   A complete explanation of the NAS and access-nodes header fields is as follows:

   Version and maintain
   handshakes, are sent after Sub-version:  The version of the TCP connection is established. ANCP
   messages other than adjacency protocol messages may be sent only
   after that was
      agreed for the session during adjacency protocol has achieved synchronization.

   In negotiation.  For the case of ATM access, a separate PVC (control channel) capable
   of transporting IP would
      values that must be configured between NAS and the DSLAM for placed into these fields, see Section 4.1.

   Message Type:  The ANCP messages.

   In case of an Ethernet access/aggregation network, message type.  Message type values are
      registered in a typical practice common GSMPv3/ANCP IANA registry.

   Result:  The Result field derived from GSMPv3 [RFC3292].  Ignore
      (0x0) is to send the Access Node Control Protocol messages over a dedicated
   Ethernet Virtual LAN (VLAN) using a separate VLAN identifier (VLAN
   ID).

5.2.  ANCP Connection keepalive

   GSMPv3 defines an adjacency protocol. new value added by ANCP.  The adjacency protocol is used
   to synchronize states across the link, to negotiate which version of
   the GSMP protocol to use, to discover the identity remaining Result values
      below are a subset of those defined for GSMPv3.  GSMPv3 expected
      the entity at
   the other end sender of a link, and to detect when it changes.  GSMP is a
   hard state protocol.  It is therefore important request to detect loss of
   contact choose between switch and controller, NAck (0x1) and AckAll
      (0x2) according to detect any change of
   identity of switch or controller.  No protocol messages other than
   those of the adjacency protocol its needs.  ANCP specifies what Result value
      each request should have.  Responses indicate either Success (0x3)
      or Failure (0x4) as the case may be sent across be.

      Ignore:  Res = 0x0 - Ignore this field on receipt and follow the link until
         procedures specified for the
   adjacency protocol has achieved synchronization.  There are received message type.

      Nack:  Res = 0x1 - Result code indicating that no
   changes response is
         expected to the base GSMP adjacency protocol for implementing ANCP.

   The NAS will set the M-flag message other than in cases of failure caused
         during the processing of the SYN message (signifying it is contents or of the
   master).  Once
         contained directive(s).

      AckAll:  Res = 0x2 - Result code indicating that a response to the adjacency
         message is established, periodic adjacency
   messages (type ACK) are exchanged.  The default ACK interval as
   advertised requested in the adjacency messages is 10 sec for ANCP.  It SHOULD
   be configurable and is an implementation choice.  It is recommended
   that both ends specify the same timer value, all cases.

      Success:  Res = 0x3 - Set in order to achieve this
   behavior both ends look at a response message by the timer values receiver of
         a request to indicate successful execution of all directives in
         the received (initial)
   adjacency corresponding request message.

      Failure:  Res = 0x4 - Set in a response message and agree to use by the higher receiver of the two values.
   That is, the node that receives
         a higher timer value than its own,
   will reply request to indicate either that there was an error in its subsequent adjacency messages (such as SYNACK, ACK)
   with the higher timer value.

   The GSMP adjacency
         content of the request message defined or that one or more directives
         in [RFC3292] is extended for ANCP
   and is shown in section 5.3 immediately following this section.  The
   8-bit "version" the corresponding request could not be executed
         successfully.

   Code:  This field in gives further information concerning the adjacency protocol messages result in
      a response message.  It is modified
   to carry the version and sub-version of the GSMP protocol for version
   negotiation.  ANCP uses version 3 and sub-version 1 of GSMP protocol.
   [RFC Editor's note: sub-version needs mostly used to pass an error code in a
      failure response but can also be changed from 1 used to 2 upon
   publication.] give further information
      in a success response message or an event message.  In a request
      message, the adjacency protocol the version and the sub-
   version fields are used for version negotiation.  The version
   negotiation is performed before synchronisation Code field is achieved.  In a
   SYN message not used and MUST be set to zero.

      ANCP implementations MAY use any of the version/sub-version fields always contain Code values specified in
      the highest IANA registry "Global Switch Management Protocol version understood by 3
      (GSMPv3) Failure Response Message Name Space" if they appear
      applicable.  In particular, the sender.  A receiver receiving a SYN values:

      2  Invalid request message
   with a version/sub-version higher than understood will ignore that
   message.  A receiver receiving (i.e., a SYN properly formed message with a version/
   sub-vresion lower than its own highest version/sub-version, but a
   version/sub-version that it understands, will reply with a SYNACK
   with the version/sub-version from which
         violates the received SYN in protocol through its ANCP
   version/sub-version fields.  This defines timing or direction of
         transmission)

      4  One or more of the version/sub-version specified ports do not exist

      6  One or more of the ANCP protocol to be used while the adjacency protocol remains
   synchronised.  All other messages will use the agreed version in the
   version/sub-version fields.

   The semantics and suggested values for Code, "Sender Name", "Receiver
   Name", "Sender Instance", and "Receiver Instance" fields specified ports are as
   defined in [RFC3292].  The "Sender Port", and "Receiver Port" should
   be set to 0 by both ends.  The pType field should be set to 0. down

      7  Invalid Partition ID

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

      30 The
   pFlag should be set to 1.

   If limit on the adjacency times out maximum number of point-to-multipoint
         connections that the switch can support has been reached

      31 The limit on either end, due the maximum number of branches that the specified
         point-to-multipoint connection can support has been reached

      may unfortunately apply to not receiving ANCP usage, where "Port" is interpreted
      to mean an
   adjacency message for access line or a duration Target as defined in Section 6.2.1.

      Instead of (3 * Timer value), where the
   timer value value:

      3  The specified request is not implemented on this switch

      specified by [RFC3292], this specification defines a new value:

      81 Request message type not implemented

      This value MAY be sent in a failure response from either the adjacency message, all AN or
      the state
   received from NAS.  This specification also defines the additional values:

      82 Transaction identifier out of sequence

      83 Malformed message

      84 TLV or value not supported by negotiated capability set

      ANCP neighbor should be cleaned up, and extensions defining new code values SHOULD use the TCP
   connection should be closed.  The NAS would continue to listen range 256
      (0x100) through 511 (0x1FF) for
   new connection requests.  The DSLAM will try this purpose.

      The range of values from 256 to re-establish 4095 is reserved for IETF use.

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

      The AN and both sides will attempt to re-establish NAS MAY agree on the adjacency. partition ID using one of the
      following possible options:

      1 -  The handling defined above will need some modifications when ANCP
   graceful restart procedures are defined.  These procedures will partition ID could be
   defined in a separate draft.

5.3.  Capability negotiation

   The adjacency message as defined in [RFC3292] is extended to carry
   "Capability TLVs".  Both configured on the NAS AN and learned by
         the access node will advertise
   supported capabilities NAS in the originated adjacency messages.  If a
   received adjacency message indicates absence message;

      2 -  The partition ID could be statically configured on the NAS as
         part of support for a
   capability that is supported by configuring the receiving device, it will turn
   off neighbor information.

   Transaction ID:  24-bit field set by the capability locally and will send an updated adjacency sender of a request message
      to associate a response message with the capability turned off to match original request message.
      Unless otherwise specified for a given message type, the received capability set.
   This process will eventually result
      Transaction ID in both sides agreeing on the
   minimal request messages MUST be set of supported capabilities.  The adjacency will not come
   up unless to a value in the capabilities advertised by
      range (1, 2^24 - 1).  When used in this manner, the controller Transaction ID
      sequencing MUST be maintained independently for each ANCP
      adjacency and the
   controlled device match.

   After initial synchronization, if at anytime per message type.  Furthermore, it SHOULD be
      incremented linearly for each new message of the given type,
      cycling back to 1 after running the full range.  Each Transaction
      ID sequence SHOULD be reinitialized to a capability mismatch random non-zero value
      when an adjacency is
   detected, negotiated.  For event messages, the adjacency will
      Transaction ID SHOULD be brought down (RSTACK will set to zero.

      Unless otherwise specified, the default behaviour for all ANCP
      responses is that the value of the Transaction ID MUST be
   generated by copied
      from the device detecting corresponding request message.

   I flag and SubMessage Number:  An ANCP implementation SHOULD set the mismatch),
      I Flag and synchronization
   will be re-attempted.

       0 subMessage Number fields to 1                   2                   3 to signify no
      fragmentation.

   Length:  Length of the ANCP message including its header fields and
      defined ANCP message body.

4.4.2.  The ANCP Message Body

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

   The general format of a TLV is shown in Figure 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Ver |  Sub  | Message Type  |     Timer     |M|     Code    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Sender Name                          |
      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      |                         Receiver Name                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Sender Port                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Receiver Port                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | PType | PFlag |               Sender Instance                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Partition ID  |              Receiver Instance                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Tech     Type (IANA registered)    | # of TLVs     | Total          Length               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                   Capability TLVs                            Value                              ~
       ~                                                               ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 8 6: General TLV Format

   The format fields of capability TLV is:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Capability Type         |   Capability Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                                                               ~
      ~                   Capability Data                             ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 9: Capability a TLV are defined as follows:

   Type:  The Tech TLV Type field type indicates the technology to which the
   capability extension applies.  For access node control in case of DSL
   networks, new type "DSL" is proposed.  The value for this field is
   0x05.  This is the first available a 16-bit unsigned value in the range that is not
   currently allocated.  It will need to be reserved with IANA.

   Capability length is identifying the TLV
      type and nature of its contents.  An IANA registry has been
      established for ANCP TLV Type codes.

   Length  The number of actual bytes contained of data in the
   value portion Value field of the TLV.  The TLV,
      excluding any padding required to bring this TLV is padded to a 4-octet alignment.
   Therefore, 4-byte word
      boundary (see "Value" below).  If a TLV with no data will contain a zero contains other TLVs, any
      padding in the length field
   (if capability data is three octets, the length field will contain a
   three, but contained TLVs MUST be included in the size value of
      Length.

         If the actual TLV is eight octets).  Capability
   data field can contains another TLV followed by other data, the
         outer TLV will not be empty properly parsable unless Length is set as
         indicated; if the capability interior padding is just omitted from Length, as
         many bytes of data at the end of the outer TLV will be missed.
         If the outer TLV contains another TLV as its final field it
         requires no padding of its own (since the contained TLV
         including padding ends on a boolean. 4-byte boundary).  In this case the capability is a boolean, it
         issue is inferred one of consistency rather than parsability, since the
         padding of that final TLV could be omitted from Length without
         loss of data.

      Depending on the presence specification of the
   TLV (with no data).

   Capability data provides TLV, the flexibility to advertise more than mere
   presence or absence value of a capability.  Capability types can Length may
      be
   registered with IANA.  Following capabilities are defined zero, a constant for ANCP as
   applied to DSL access:

   1.  Capability Type : Dynamic-Topology-Discovery = 0x01

          Length (in bytes) : 0

          Capability Data : NULL

   2.  Capability Type : Line-Configuration = 0x02

          Length (in bytes) : 0

          Capability Data : NULL

   3.  Capability Type : Transactional-Multicast = 0x03 (controller i.e.
       NAS terminates IGMP messages from subscribers, and via l2 control
       protocol, signals state to the access-nodes (e.g.  DSLAMs) to
       enable layer2 replication all instances of multicast streams.  In ATM access
       network this implies that NAS instructs the access-node TLV, or a varying
      quantity.

   Value  The actual data carried by the TLV, if any.  The value field
      in each TLV MUST be padded with zeroes as required to setup align with a P2MP cross-connect.
      4-byte word boundary.  The details Value field of this will a TLV may include fixed
      fields and/or other TLVs.

   Unless otherwise specified, TLVs MAY be covered added to a message in any
   order.  If the recipient of a
       separate ID.

          Length (in bytes) : 0

          Capability Data : NULL

   4.  Capability Type : OAM = 0x04

          Length (in bytes) : 0

          Capability Data : NULL

5.4.  GSMP Message Extensions for Access Node Control

5.4.1.  General Extensions

   Extensions to GSMP messages for various use-cases message does not understand a
   particular TLV, it MUST silently ignore it.

   A number of "Access Node
   Control" mechanism TLVs are defined specified in sections Section 5.4.2 to
   Section 5.4.4.  However, sub-sectionSection 5.4.1.1 below defines
   extensions to GSMP the remainder of this document.

4.4.2.1.  Additional Conventions and General Requirements

   Any field in a message that have general applicability is inherited from GSMPv3 and section
   Section 5.4.5 introduces anothor messaging principle is unused in
   ANCP and additional
   general purpose TLVs any field that could is explicitly shown as Reserved MUST be used set
   to develop new use cases in
   future.

5.4.1.1.  Extension TLV

   In order to provide flexibility and extensibility certain GSMP
   messages such as "PORT MANAGEMENT" and "EVENT" messages defined in
   [RFC3292] have been modified to include an extension block that
   follows a TLV structure.  Individual messages in the following
   sections describe all zeroes by the usage sender and format of the extension block.

   All Extension TLVs will MUST be designated as follow:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |x|x|x|x|x|x|x|x| Message Type  |   Tech Type   | Block Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                         Extension Value                       ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 10: Extension TLV

      x: Reserved Flags

         These are generally used ignored by specific messages and will the receiver.

      Such fields could be
         defined assigned a specific purpose in those messages.

      Message Type

         An 8-bit a future
      version of this specification.

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

5.  ANCP Capabilities For Digital Subscriber Lines (DSL)

5.1.   Overview

   DSL is used.

      Tech Type

         An 8-bit field indicating the applicable a widely deployed access technology type value. 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 Message Type plus scope of these specifications includes the Tech Value uniquely define a single
         Extension Type and can be treated as a single 16 bit extension
         type.  "Tech Type" value delivery of 0x05 SHOULD be used by ANCP for DSL
         technology
   voice, video, and 0x01 for PON technology.

            0x00 Extension block not in use

            0x01 PON

            0x05 data services.

   When deploying value-added services across DSL

            0x06 - 0xFE Reserved

            0xFF Base Specification Use

      Block Length

         A 8-bit field indicating the length access networks,
   special attention is required to assure quality of the Extension Value
         field service and
   service control, which implies a tighter coordination between network
   elements in bytes.  When the Tech broadband access network without burdening the OSS
   layer.

   This document specifies basic ANCP capabilities for use specifically
   in controlling Access Nodes serving DSL access (Tech Type = 0x00, the length value
         MUST be set to 0.

      Extension Value

         A variable length field that is an integer number of 32 bit
         words long. 0x05).
   The Extension Value field is interpreted according
         to same ANs could be serving other access technologies (e.g.  Metro-
   Ethernet, Passive Optical Networking, WiMax), in which case the specific definitions provided by AN
   will also have to support the messages corresponding other-technology-specific
   capabilities.  These additional capabilities are not specified here,
   but may be specified in the
         following sections..

5.4.2.  Topology Discovery Extensions other documents.

   The GSMP Event message with PORT UP message type (80) is used for
   conveying DSL capabilities specified in this section are:

   DSL Topology Discovery:  Dynamic discovery of access topology and DSL
      line attributes by the NAS, to support tight QOS control in the NAS.  The message SHOULD be
   generated when a line first comes UP, or any of
      access network.

   DSL Line Configuration:  Pushing subscriber and service data
      retrieved by the attributes of NAS from an OSS system (e.g.  RADIUS server) to
      the Access Nodes, to simplify OSS infrastructure for service
      management.

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

5.1.1.  ATM-Specific Considerations

   Topology discovery and line re-trains to a different rate or one or
   more of configuration involve the configured DSL line attributes are administratively modified.
   Also, when
   attributes.  For ATM based access networks, the ANCP session first comes up, DSL line on the DSLAM SHOULD transmit
   a PORT UP message
   is identified by the port and PVP/PVC corresponding to the
   subscriber.  The DSLAMs are connected to the NAS for each line that is up.  When a DSL
   line goes down (idle or silent), via an ATM access
   aggregation network.  Since, the DSLAM SHOULD transmit an Event
   message with PORT DOWN message type (81) (Access Node) is not directly
   connected to the NAS.  It is
   recommended that NAS, the DSLAMs use NAS needs a dampening mechanism per DSL line to
   control learn the rate of state changes per DSL line, communicated line
   identifier (more generally referred to the
   NAS.

   Not all the fields in GSMP Event message are applicable as "access loop circuit ID")
   corresponding to ANCP. a subscriber.  The
   fields that are not applicable MUST be set to zero by access loop circuit ID has no
   local significance on the NAS.  The ANCP sender messages for topology
   discovery and ignored by line configuration carry opaque Access-Loop-Circuit-ID
   values which have only local significance on the ANCP receiver. DSLAMs.

   The fields access loop circuit identifier can be carried as an ASCII string
   in the PORT UP and PORT
   DOWN messages ANCP messages.  This allows ANCP to be set by decoupled from the ANCP sender, and corresponding
   handling by
   specifics of the ANCP receiver is described below.

   The version field MUST be set to 3, and underlying access technology being controlled.  On
   the sub field MUST other hand, this requires a NAS mechanism by which each such
   identifier can be set correlated to
   1.  As defined in [RFC3292], the one byte Message Type field MUST be
   set context of an aggregation-
   network-facing IP interface (corresponding to 80 for PORT UP Event message, and to 81 for PORT DOWN Event
   Message.  The 12 bit Code field MUST be set to 0.  The 4 bit Result
   field MUST be set to 0 (signifying Ignore.)  If a PORT UP message
   with a Result field set to 0 is received by the NAS and subscriber) on the NAS is
   able to process
   NAS.  This will typically require local configuration of such IP
   interfaces, or of the message correctly, underlying ATM interfaces.

5.1.2.  Ethernet-Specific Considerations

   One possible way of approaching the NAS MUST NOT generate any
   ANCP message use of Ethernet technology in response to the PORT UP.  If the PORT UP message
   received cannot be processed correctly by the NAS (e.g. the message
   access aggregation network is malformed) the NAS MAY respond with an ANCP Error Message (TBD)
   containing to recreate the reason equivalent of the failure.  The 24-bit Transaction
   Identifier field MUST be set to 0.  The "I" bit Virtual
   Paths (VPs) and the SubMessage
   field MUST be set Virtual Circuits (VCs) by using stacked Virtual LAN
   tags.  As an example, one can use an "outer" VLAN to 1 create a form of
   "virtual path" between a given DSLAM and a given NAS, and then use
   "inner" VLAN tags to signify no fragmentation.  The Length field
   is two bytes create a form of "virtual circuit" on a per DSL
   line basis.  In this case, VLAN tags conveyed in topology discovery
   and MUST contain the length line configuration messages will allow unique identification of
   the message (including
   header and DSL line in a straightforward manner, assuming the payload) VLAN tags are
   not translated in bytes.

   The "Port" field, "Port Session Number" field some way by the aggregation network, and "Event Sequence
   Number" field are 4 bytes each, and MUST be set unique
   across physical ports.

   However, some carriers do not wish to 0 by the ANCP
   sender.  LABEL field in event messages use this "connection oriented"
   approach.  Therefore, an alternative model is defined as to bridge sessions from
   multiple subscribers behind a TLV DSLAM to a single VLAN in
   [RFC3292].  ANCP does NOT use the Label TLV.
   aggregation network.  This is the N:1 model.  In both PORT UP and
   PORT DOWN event messages an ANCP sender MUST treat this model, or in
   the Label field,
   immediately following case where user traffic is sent untagged, the "Event Sequence Number" field, as a fixed 8
   byte field, and MUST set these 8 bytes Access Node needs
   to 0.  The receiver MUST NOT
   interpret the LABEL field as a TLV and MUST ignore the 8 bytes
   immediately following insert the "Event Sequence Number" field.  In future
   versions exact identity of ANCP, if necessary, the un-used fields DSL line in GSMP Event
   message, which do not the topology
   discovery and line configuration messages, and then have ANCP specific semantics, can be used
   partially or completely, a mechanism
   by re-naming appropriately, and associating
   valid semantics with these fields.

   The Tech Type field is extended with new type "DSL".  The value for which this field is 0x05.

   In case of bonded copper loops can be correlated to the customer premise (as per DSL
   multi-pair bonding described by [G.988.1] and [G.988.2]), context of an aggregation-
   network-facing IP interface (for the DSLAM
   MUST report subscriber) on the aggregate net data rate and other attributes for NAS.  This
   can either be based on local configuration on the
   "DSL bonded circuit" (represented as a single logical port) to NAS, or on the
   NAS fact
   that such DSLAM (Access Node) typically inserts the access loop
   circuit ID in a PORT UP message.  Any change subscriber signaling messages relayed to the NAS (i.e.
   DHCP or PPPoE discovery messages).

   Section 5.2.3.3 defines TLVs to represent the "access loop circuit
   ID".

5.2.  ANCP Based DSL Topology Discovery
5.2.1.   Goals

   [TR_059] discusses various queuing/scheduling mechanisms to avoid
   congestion in the aggregate access network while dealing with multiple flows
   with distinct QoS requirements.  Such mechanisms require that the NAS
   gains knowledge about the topology of the access network, the various
   links being used and their respective net data rate rates.  Some of the "DSL bonded circuit" (due to a change
   information required is somewhat dynamic in nature (e.g.  DSL sync
   rate, and therefore also the net data rate rate), hence cannot come from a
   provisioning and/or inventory management OSS system.  Some of
   individual constituent DSL lines or due the
   information varies less frequently (e.g. capacity of a DSLAM uplink),
   but nevertheless needs to change be kept strictly in state sync between the actual
   capacity of the
   individual constituent DSL lines) MUST be reported by uplink and the DSLAM to image the NAS in a PORT UP message. has of it.

   The DSLAM MUST also report following section describes ANCP messages that allow the
   "aggregate" state Access
   Node (e.g., DSLAM) to communicate access network topology information
   and any corresponding updates to the NAS.

   Some of the "DSL bonded circuit" parameters that can be communicated from the DSLAM to the
   NAS via PORT UP include DSL line state, actual upstream and PORT DOWN messages.

    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              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Port                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Port Session Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Event Sequence Number                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                             Label                             +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |x|x|x|x|x|x|x|x| Message Type  |   Tech Type   | Block Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                         Extension Value                       ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 11

   The format downstream net data
   rates of the "Extension Value" field for Tech Type "DSL" a synchronized DSL link, maximum attainable upstream and
   downstream net data rates, interleaving delay etc.  Topology
   discovery is as
   follows :

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     # specifically important in case the net data rate of TLVs               | Extension Block length (bytes)  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                            TLVs                               ~
       ~                                                               ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 12: Extension Value the
   DSL line changes over time.  The "Extension Value" contains one or more TLVs DSL net data rate may be different
   every time the DSL modem is turned on.  Additionally, during the time
   the DSL modem is active, data rate changes can occur due to identify a
   environmental conditions (the DSL line and define its characteristics.  A TLV can consist of multiple
   sub-TLVs.  First 2 byte get "out of sync" and can
   retrain to a lower value).

5.2.2.  Message Flow

   To provide expected service levels, the "Extension Value" contains NAS needs to learn the number
   initial attributes of TLVs that follow.  The next 2 bytes contain the total length of DSL line before the TLVs carried subscriber can log in
   and access the extension block in bytes (existing "Block
   Length" field in services provisioned for the GSMP message is limited to 255 bytes and is not
   sufficient).

   General format of subscription.  When a TLV is :

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

                          Figure 13:  General TLV

   The value field in each TLV is padded DSL
   line initially comes up or resynchronizes to a 4-octet alignment.  The
   Length field in each TLV contains the actual number of bytes in the
   TLV (not including the padding if present).  If a TLV is not
   understood by different rate, the NAS, it is silently ignored.  Currently defined
   types start from 0x01.

   Following TLVs are currently defined:

   1.  Type (Access-Loop-Circuit-ID = 0x01): This is a mandatory TLV
   DSLAM generates and
       contains transmits an identifier of the subscriber's connection ANCP Port UP Event message to the
       access node (i.e. "local loop").  The "local loop" can be ATM
       based or Ethernet based.  The "Access Loop Circuit ID" has local
       significance at the access node.
   NAS.  The exact usage on extension field in the NAS is
       beyond message carries the scope TLVs containing
   DSL line specific parameters.  Upon loss of this document.  The format used for "local
       loop" identification in signal on the DSL line,
   an ANCP messages MUST be identical to what Port DOWN message is used generated by the access nodes in subscriber signaling messages when DSLAM and sent to the access nodes act as "signaling relay agents" as outlined in
       [RFC3046] and [TR-101].

          Length : (up to 63 bytes)

          Value : ASCII string

          For an ATM based local loop
   NAS.  Figure 7 summarizes the string consists 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 slot/port
          and VPI/VCI information corresponding to the subscriber's Signal

          Figure 7: ANCP Message Flow For DSL
          connection.  Default syntax for the string inserted by the
          access node as per [TR-101] is:

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

   The Access-Node-Identifier uniquely identifies Event message with Port UP message type (80) is used for
   conveying DSL line attributes to the access node NAS.  This message with relevant
   extensions is defined in the access network.  The slot/port and VPI/VCI uniquely
          identifies next section.

5.2.3.  Specification of the ANCP DSL line on the access node.  Also, there is
          one to one correspondence between Topology Discovery Capability

5.2.3.1.  Protocol Requirements

   The DSL line and topology discovery capability is assigned capability type
   0x01.  No capability data is associated with this capability.
   Implementations of the VC between DSL topology discovery capability MUST support
   the access node following ANCP protocol elements:

   o  ANCP Port UP and the NAS.

          For local loop Port DOWN Event messages, which is Ethernet are based (and tagged), on the
          string consists
      GSMPv3 [RFC3292] messages of slot/port and VLAN tag corresponding to the
          subscriber.  Default syntax for the string inserted by the
          access node as per [TR-101] is:

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

   2.  Type (Access-Loop-Remote-Id = 0x02): This is an optional TLV same name but include capability-
      specific modifications and
       contains an identifier to uniquely identify a user on a local
       loop on the access node. extensions (Section 5.2.3.2).

   o  The exact usage on 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-Binary TLV;
   o  Access-Aggregation-Circuit-ID-ASCII 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 in Section 5.2.3.3.

5.2.3.2.  ANCP Port UP and Port DOWN Event Message Descriptions

   The ANCP Port UP and Port DOWN Event messages are derived from the NAS is out of
       scope
   GSMPv3 Event message shown in Section 9 of this document.  It is desirable that the [RFC3292].  The modified
   format used for
       the field is similar to what DSL topology discovery is used by the access nodes in
       subscriber signaling messages when the access nodes act as
       "signaling relay agents" as outlined shown in [RFC3046] and [TR-101].

          Length : (up to 63 bytes)

          Value : ASCII string

   3. Figure 8.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           TCP/IP Encapsulating Header (Section 4.2)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                ANCP General Message Header                    |
   +                      (Section 4.4)                            +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Port                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Port Session Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Event Sequence Number                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                             Label                             +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |x|x|x|x|x|x|x|x| Message Type (Access-Aggregation-Circuit-ID-Binary = 0x06)

          Length : (8 bytes)

          Value : two 32 bit integers  |   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 ethernet access aggregation, where DSL Topology Discovery

   See Section 4.4 for a per-subscriber
          (stacked) VLAN can be applied (1:1 model defined in [TR-101]), description of the VLAN stack provides a convenient way ANCP general message header.
   The Message Type field MUST be set to uniquely identify
          the DSL line. 80 for Port UP, 81 for Port
   DOWN.  The outer VLAN is equivalent 12 bit Code field MUST be set to virtual path
          between a DSLAM and 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 NAS general
   header MUST be set as described in Section 4.4.

   The Port, Port Session Number, and inner VLAN is equivalent to a
          virtual circuit on a per DSL line basis.  In this scenario,
          any subscriber data received Event Sequence Number fields are
   not used by the access node DSL Topology Discovery capability and
          transmitted out the uplink to the aggregation network will MUST be
          tagged with
   considered reserved.  The Label field (including the VLAN stack assigned by Stacked Label
   Indicator and the access node

          This TLV can carry unused flags at the VLAN tags assigned by start of the access node Label field), is
   also unused, and MUST be treated as a reserved fixed 8-byte field.
   The handling of unused/reserved fields is described in the ANCP messages.
   Section 4.4.2.1.

   The VLAN tags can uniquely identify the
          DSL line being referred to remaining message fields are described as follows:

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

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

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

   Block Length:  unused, reserved.

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

   Extension Block Length:  the total length of the TLVs carried in any way translated the
      extension block in bytes, including any padding within individual
      TLVs.  (The existing "Block Length" field inherited from the aggregation
          network GSMP
      message is limited to 255 bytes and are unique across physical ports.  Each 32 bit
          integer (least significant bits) contains is not sufficient).

   TLVs:  two or more TLVs to identify a 12 bit VLAN
          identifier (which DSL line and define its
      characteristics.

5.2.3.2.1.  Procedures

   The GSMP Event message with Port UP message type (80) is part used for
   conveying DSL line attributes to the NAS.  The message SHOULD be
   generated when a line first comes UP, or any of the VLAN tag defined by IEEE
          802.1Q).

          Also, in case attributes of an ATM aggregation network, where the DSLAM
          is directly connected
   line change e.g. the line re-trains to a different rate or one or
   more of the NAS (without an intermediate ATM
          switch), configured line attributes are administratively modified.
   Also, when the two values can contain VPI and VCI on ANCP session first comes up, the DSLAM
          uplink (and can uniquely identify SHOULD transmit
   a Port UP message to the NAS for each line that is up.  When a DSL
   line on goes down (idle or silent), the DSLAM).

          This is optional.

   4.  Type (Access-Aggregation-Circuit-ID-ASCII = 0x03)

          Length : (up to 63 bytes)

          Value : ASCII string

          This field contains information pertaining to DSLAM SHOULD transmit an uplink on the
          access node.  For Ethernet access aggregation, assuming Event
   message with Port DOWN message type (81) to the
          access node assigns VLAN tags (1:1 model), typical format for NAS.  It is
   recommended that the string is:

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

          The slot/port corresponds DSLAMs use a dampening mechanism per DSL line to
   control the ethernet uplink on the access
          node towards rate of state changes per DSL line, communicated to the
   NAS.

          For an ATM aggregation network, typical format for

   If a Port UP message with a Result field set to 0 is received by the string
          is:

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

          This TLV allows
   NAS and the NAS is able to associate process the information contained
          in message correctly, the NAS
   MUST NOT generate any ANCP messages message in response to the DSL line on the access node. Port UP.  If
   the access node inserts this string in Port UP message received cannot be processed correctly by the ANCP messages,
          when referring to local loop characteristics NAS
   (e.g.  DSL line
          in the message is malformed) the NAS MAY respond with an ANCP
   Generic Response message (Section 6.1.3) containing the reason for
   the failure.

   In the case of a DSLAM), then it should be able bonded copper loops to map the
          information contained in the string uniquely to customer premise (as per
   the local loop
          (e.g. DSL line).

          On multi-pair bonding described by [G.988.1] and [G.988.2]), the NAS,
   DSLAM MUST report the information contained in this string can be
          used to derive an "aggregation network" facing construct (e.g.
          an IP interface) corresponding to aggregate net data rate and other attributes
   for the local loop (e.g. DSL
          line).  The association could be based on "local
          configuration" on the NAS.

          The access node can also convey bonded circuit (represented as a single logical port) to
   the NAS, the
          characteristics (e.g. bandwidth) of the uplink on the access
          node.  This TLV then serves the purpose of uniquely
          identifying NAS in a Port UP message.  Any change in the uplink whose characteristics are being
          defined.  A separate set aggregate net data
   rate of sub-TLVs will be defined for the
          uplink characteristics (TBD).

          This TLV is optional.

   5.  Type (DSL Line Attributes = 0x04):

          Length : variable (up DSL bonded circuit (due to 1024 bytes)

          Value : This is a mandatory TLV and consists change in net data rate of one
   individual constituent DSL lines or more
          Sub-TLVs corresponding due to DSL line attributes.  No sub-TLVs
          other than change in state of the "DSL type" and "DSL line state" SHOULD
   individual constituent DSL lines) MUST be
          included reported by the DSLAM to
   the NAS in a PORT DOWN Port UP message.  The general format DSLAM MUST also report the
   aggregate state of the sub-TLVs is identical DSL bonded circuit to the general
          TLV format.  The value field in each sub-TLV is padded to a
          4-octet alignment. NAS via Port UP and
   Port DOWN messages.

   The Length field in each sub-TLV contains
          the actual number definition of bytes TLVs in the TLV (not including the
          padding if present).  Current defined sub-TLV types are start
          from 0x81.

          Following sub-TLVs next section contains some additional
   procedural information.

5.2.3.3.  TLVs For DSL Topology Discovery

   The following TLVs are currently defined :

          +  Type (DSL-Type = 0x91) : Defines the type for DSL Topology Discovery,
   but may be reused for other capabilities.

5.2.3.3.1.  Access-Loop-Circuit-ID TLV

   Name:  Access-Loop-Circuit-ID

   Type:  0x0001

   Description:  an identifier of transmission
             system in use.  This is a mandatory TLV.

                Length : (4 bytes)

                Value : (Transmission system : ADSL1 = 0x01, ADSL2 =
                0x02, ADSL2+ = 0x03, VDSL1 = 0x04, VDSL2 = 0x05, SDSL =
                0x06, UNKNOWN = 0x07).

          +  Type (Actual-Net-Data-Upstream = 0x81): Actual upstream net
             data rate on a DSL line.  This is a mandatory TLV.

                Length : (4 bytes)

                Value : (Rate in Kb/sec)

          +  Type (Actual-Net-Data-Rate-Downstream = 0x82) : Actual
             downstream net data rate on a DSL line.  This is a
             mandatory TLV.

                Length : (4 bytes)

                Value : (Rate in Kb/sec)

          +  Type (Minimum-Net-Data-Rate-Upstream = 0x83) : Minimum net
             data rate desired by the operator.  This is optional.

                Length : (4 bytes)

                Value : (Rate in Kb/sec)

          +  Type (Minimum-Net-Data-Rate-Downstream = 0x84) : Minimum
             net data rate desired by subscriber's connection to the operator.  This is optional.

                Length : (4 bytes)

                Value : (Rate in Kb/sec)

          +  Type (Attainable-Net-Data-Rate-Upstream = 0x85) : Maximum
             net upstream rate that
      Access Node (i.e. "local loop").  The local loop can be attained ATM based
      or Ethernet based.  The access loop circuit ID has local
      significance at the Access Node.  The exact usage on the DSL line.
             This NAS is an optional TLV.

                Length : (4 bytes)

                Value : (Rate
      beyond the scope of this document.  The format used for local loop
      identification in Kb/sec)

          +  Type (Attainable-Net-Data-Rate-Downstream = 0x86) : Maximum
             net downstream rate that can ANCP messages MUST be attained on the DSL line.
             This identical to what is an optional TLV.

                Length : (4 bytes)

                Value : (Rate in Kb/sec)

          +  Type (Maximum-Net-Data-Rate-Upstream = 0x87) : Maximum net
             data rate desired used
      by the operator.  This is optional.

                Length : (4 bytes)

                Value : (Rate Access Nodes in Kb/sec)

          +  Type (Maximum-Net-Data-Rate-Downstream = 0x88) : Maximum
             net data rate desired by subscriber signaling messages when the operator.  This is optional.

                Length : (4 bytes)
                Value : (Rate in Kb/sec)

          +  Type (Minimum-Net-Low-Power-Data-Rate-Upstream = 0x89) :
             Minimum net data rate desired by the operator in low power
             state.  This is optional.

                Length : (4 bytes)

                Value : (Rate
      Access Nodes act as signaling relay agents as outlined in Kb/sec)

          +  Type (Minimum-Net-Low-Power-Data-Rate-Downstream = 0x8A) :
             Minimum net data rate desired by
      [RFC3046] and [TR_101].

      For an ATM based local loop the operator in low power
             state.  This is optional.

                Length : (4 bytes)

                Value : (Rate in Kb/sec)

          +  Type (Maximum-Interleaving-Delay-Upstream = 0x8B) : maximum
             one way interleaving delay.  This is optional.

                Length : (4 bytes)

                Value : (Time in msec)

          +  Type (Actual-Interleaving-Delay-Upstream = 0x8C) : Value string consists of slot/port and
      VPI/VCI information corresponding to the interleaver setting.  This is
             optional.

                Length : (4 bytes)

                Value : (Time in msec)

          +  Type (Maximum-Interleaving-Delay-Downstream = 0x8D) :
             maximum one way interleaving delay.  This is optional.

                Length : (4 bytes)

                Value : (Time in msec)

          +  Type (Actual-Interleaving-Delay-Downstream = 0x8E) : Value
             corresponding to subscriber's DSL
      connection.  Default ABNF [RFC5234] syntax for the interleaver setting.  This is
             optional.

                Length : (4 bytes)
                Value : (Time string inserted
      by the Access Node as per [TR_101] is:

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

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

      The Access-Node-Identifier uniquely identifies the Access Node in msec)

          +  Type (DSL line state = 0x8F) :
      the access network.  The state of slot/port and VPI/VCI uniquely identify
      the DSL line.
             For PORT UP message, at this time, line on the TLV Access Node.  Also, there is optional
             (since one to one
      correspondence between DSL line and the message type implicitly conveys VC between the state of Access Node
      and the
             line). NAS.

      For PORT DOWN, the TLV a local loop which is mandatory, since it
             further communicates Ethernet based (and tagged), the state string
      consists of slot/port and VLAN tag corresponding to the line as IDLE or
             SILENT.

                Length : (4 bytes)

                Value : { SHOWTIME = 0x01, IDLE = 0x02, SILENT = 0x03 }

          +  Type (Access Loop Encapsulation = 0x90) : The data link
             protocol and, optionally
      subscriber.  Default ABNF syntax for the encapsulation overhead on string inserted by the
             access loop.
      Access Node as per [TR_101] is:

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

      This is an optional a mandatory TLV.  However, when this

   Length:  up to 63 bytes

   Value:  ASCII string

5.2.3.3.2.  Access-Loop-Remote-Id TLV

   Name:  Access-Loop-Remote-Id

   Type:  0x0002

   Description:  This is present, an optional TLV and contains an identifier to
      uniquely identify a user on a local loop on the data link protocol MUST minimally be
             indicated.  The encapsulation overhead can be optionally
             indicated.

                Length : (3 bytes)

                Value : Access Node.  The three bytes (most to least significant) and
                valid set
      exact usage on the NAS is out of scope of values for each byte are defined below.

                   Data Link (1 byte): {ATM AAL5 = 0, ETHERNET = 1}

                   Encaps 1 (1 byte): {

                      NA = 0,

                      Untagged Ethernet = 1,

                      Single-tagged Ethernet = 2}

                   Encaps 2 (1 byte):{

                      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}

             If this TLV document.  It is present,
      desirable that the Data Link protocol MUST be
             indicated as defined above.  However, format used for the Access Node can
             choose field be similar to not convey what is
      used by the encapsulation on Access Nodes in subscriber signaling messages when the
      Access Nodes act as signaling relay agents as outlined in
      [RFC3046] and [TR_101].

   Length:  up to 63 bytes

   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 loop
             by specifying aggregation, where a value of 0 (NA) for the two encapsulation
             fields

5.4.3.  Line Configuration Extensions

   The Port Management message format per-subscriber
      (stacked) VLAN can be applied (1:1 model defined in [RFC3292] has been
   modified to contain an extension block (described above in section
   Section 5.4.1.1) at the end of the message.  Also, [TR_101]), the original two
   byte Function field has been modified
      VLAN stack provides a convenient way to contain one byte for uniquely identify the
   Function field indicating DSL
      line.  The outer VLAN is equivalent to virtual path between a specific action
      DSLAM and the NAS and inner VLAN is equivalent to be taken a virtual
      circuit on a per DSL line basis.  In this scenario, any subscriber
      data received by the
   recipient of the message, Access Node and one byte for X-Function field, which
   could further qualify transmitted out the action specified in uplink to
      the Function field.
   Any Function specific data MUST aggregation network will be carried in the extension block.

   Not all tagged with the fields in GSMP Port Management message are applicable to
   ANCP.  The fields that are not applicable MUST be set to zero VLAN stack
      assigned by the
   ANCP sender and ignored by Access Node.

      This TLV carries the ANCP receiver.

   The NAS uses VLAN tags assigned by the extension block access node in the Port Management messages to
   convey service attributes of the DSL lines to
      ANCP messages.  The VLAN tags can uniquely identify the DSLAM.  TLVs are
   defined for DSL line identification and service data for the DSL
   lines.  Port number is set
      being referred to 0 in the message.  A new action type
   "Configure Connection Service Data" (value 0x8) is defined.  The
   "Function" field is set to the action type.  This action type
   indicates to ANCP messages, assuming the device being controlled (Access Node i.e.  DSLAM) to
   apply service configuration data contained VLAN tags are
      not in any way translated in the extension value
   (TLVs), to aggregation network and are
      unique across physical ports.  Each 32 bit unsigned integer (least
      significant bits) contains a 12 bit VLAN identifier (which is part
      of the DSL line (identified VLAN tag defined by IEEE 802.1Q).

      [Editor's Note: should we specify that the upper 20 bits are set
      to zero?  Which one is inner, which one is outer?]

      Also, in case of an ATM aggregation network, where the TLVs in DSLAM is
      directly connected to the
   extension value).  For NAS (without an intermediate ATM
      switch), the action type "Configure Connection Service
   Data", X-Function two values can contain VPI and VCI on the DSLAM
      uplink (and can uniquely identify the DSL line on the DSLAM).

      This TLV is optional.

   Length:  8 bytes

   Value:  two 32 bit unsigned integers

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

   Name:  Access-Aggregation-Circuit-ID-ASCII

   Type:  0x0003

   Description:  This field MUST be set contains information pertaining to 0.  The Tech Type field is
   extended with new type "DSL". an uplink
      on the Access Node.  For Ethernet access aggregation, assuming the
      Access Node assigns VLAN tags (1:1 model), typical ABNF format for
      the string is:

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

      The value slot/port corresponds to the ethernet uplink on the Access
      Node towards the NAS.

      For an ATM aggregation network, the typical format for the string
      is:

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

      This TLV allows the NAS to associate the information contained in
      the ANCP messages to the DSL line on the Access Node.

      If the Access Node inserts this field is 0x05.

    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              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             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| Message Type  |   Tech Type   | Block Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                         Extension Value                       ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 14

   The format of string in the "Extension Value" field is as follows:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     # of TLVs               | Extension Block length (bytes)  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                            TLVs                               ~
       ~                                                               ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 15: Extension Value

   The "Extension Value" field contains one or more TLVs containing ANCP messages, when
      referring to local loop characteristics (e.g.  DSL line identifier and desired service attributes in case of
      a DSLAM), then it should be able to map the information contained
      in the DSL line.
   First 2 byte of the "Extension Value" contains string uniquely to the number of TLVs
   that follow.  The next 2 bytes contain local loop (e.g.  DSL line).

      On the total length of NAS, the
   extension block in bytes (existing "Block Length" field information contained in the GSMP
   message is limited to 255 bytes and is not sufficient).

   General format of a TLV is:

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

                          Figure 16:  General TLV

   The value field is padded this string can be used
      to a 4-octet alignment. derive an aggregation-network-facing construct (e.g. an IP
      interface) corresponding to the local loop (e.g.  DSL line).  The Length field
   in each TLV contains
      association could be based on local configuration on the actual number NAS.

      The Access Node can also convey to the NAS the characteristics
      (e.g., bandwidth) of bytes in the TLV (not
   including uplink on the padding if present).  If a Access Node.  This TLV is not understood by then
      serves the
   access-node, it is silently ignored.  Depending upon purpose of uniquely identifying the deployment
   scenario, uplink whose
      characteristics are being defined.  This version of the NAS may present
      document does not specify "Access Loop Circuit-ID" or the "Access
   Aggregation Circuit-ID") as defined in section Section 5.4.1.
   Following TLVs can appear in this message:

   o  Type (Access-Loop-Circuit-ID = 0x01) : defined in section
      Section 5.4.1

   o  Type (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in
      section Section 5.4.1

   o  Type (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in
      section Section 5.4.1

   o  Type (Service-Profile-Name = 0x05): Reference needed to a pre-configured
      profile on convey the DSLAM uplink
      characteristics, in the same way that contains service specific data for the
      subscriber.

         Length : (up to 64 bytes)

         Value : ASCII string containing DSL-Line-Attributes TLV
      and the profile name (NAS learns
         from a policy server after a subscriber is authorized).

      In future, more TLVs MAY be defined for individual service
      attributes of a DSL line (e.g. rates, interleaving delay,
      multicast channel entitlement access-list etc)

5.4.3.1.  Provisioning Message

   The Provisioning message is sent by the NAS to encapsulated within it convey the AN to provision
   information in characteristics of
      the AN. subscriber access line.

      This message can be used TLV is optional.

   Length:  up to provision global
   scope information on the Access Node.

   The Message Type for the Provisioning message 63 bytes

   Value:  ASCII string

5.2.3.3.5.  DSL-Line-Attributes TLV (Mandatory)

   Name:  DSL-Line-Attributes

   Type:  0x0004

   Description:  This is 93.

   The NAS sending the Provisioning message MUST set the Result field 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
   0x00. DSL line
      attributes.  The NAS DSL-Line-Attributes TLV MUST populate contain the ANCP Transaction Identifier field with a
   distinct non-zero, linearly incrementing value for each request per
   adjacency, as
      mandatory TLVs described below when it is present in Section 5.4.5 .

   The ANCP Provisioning message payload a Port UP
      message.  It MAY contain different TLVs,
   like for example Service-Profile-Name TLV.  The Service-Profile-Name
   TLV MAY appear zero, one or multiple times.

   On receipt of the Provisioning message, the AN MUST:

   o  ignore the Result field

   o  if the AN can process the message successfully and accept all the
      provisioning directives contained optional TLVs described below when it
      is present in it, the AN MUST NOT send any
      response.

5.4.4.  OAM Extensions

   GSMP "Port Management" message (type 32) SHOULD be used by the NAS to
   trigger access node to run a loopback test on Port UP message.

      When the local loop.  The
   message format DSL-Line-Attributes TLV is defined present in section Section 5.4.2.  The version
   field a Port DOWN message
      it SHOULD be set to 3 and sub-version field SHOULD be set to 1.
   The remaining fields in the GSMP header have standard semantics.  The
   function type used in the request message SHOULD be set to "remote
   loopback" (type = 0x09).  The port, "port session number", "event
   sequence number", duration, "event flags", "flow control flags" NOT include any TLVs other than DSL-Type and
   code fields SHOULD all be set to 0.  The result field SHOULD be set
   to "AckAll" to indicate requirement for the access node to send a
   success or failure response.  The transaction ID SHOULD contain a
   sequence number inserted by the NAS in each request that it
   generates.

   Not all the fields in GSMP Port Management message are applicable to
   ANCP. DSL-Line-
      State.

5.2.3.3.6.  TLVs Delivering Line Attributes

   The fields that are not applicable TLVs which follow convey DSL line attributes.  They MUST be set to zero by the
   ANCP sender and ignored by the ANCP receiver.

   The extension field format is also defined above in section
   Section 5.4.2.  The extension value field can contain one or more
   TLVs including the access-line identifier on the DSLAM and OAM test
   characteristics desired by
   encapsulated within the NAS.

   The DSL-Line-Attributes TLV format is defined above when they are carried
   in section Section 5.4.2.  The value
   field is padded to a 4-octet alignment.  The Length field in each Port UP or Port DOWN message.

5.2.3.3.6.1.  DSL-Type TLV
   contains (Mandatory)

   Name:  DSL-Type

   Type:  0x0091

   Description:  Indicates the actual number type of bytes transmission system in the TLV (not including the
   padding if present).  If 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 not understood by the NAS, it is
   silently ignored.  Depending upon the deployment scenario, the NAS
   may specify "Access Loop Circuit-ID" or the "Access Aggregation
   Circuit-ID") as defined in section Section 5.4.1.  Following TLVs can
   appear in this message:

   o  Type (Access-Loop-Circuit-ID = 0x01) : defined in section
      Section 5.4.1

   o  Type (Access-Aggregation-Circuit-ID-Binary = 0x06): defined a
      mandatory TLV.

   Length:  4 bytes

   Value:  Rate in
      section Section 5.4.1

   o  Type (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined 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
      section Section 5.4.1

   o  Type (OAM-Loopback-Test-Parameters = 0x07): Parameters related to
      loopback test. Kbits/s as a 32 bit unsigned integer

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

   Name:  Minimum-Net-Data-Rate-Upstream

   Type:  0x0083

   Description:  Minimum upstream net data rate desired by the operator.
      This is an optional TLV.  If this TLV is not
      present

   Length:  4 bytes

   Value:  Rate 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 by the request message, the DSLAM SHOULD use locally
      determined default values for the test parameters.

         Length : (4 bytes)

         Value : two 1 byte numbers described below (listed
      operator.  This is an optional TLV.

   Length:  4 bytes

   Value:  Rate in order of
         most to least significant).  Thus, Kbits/s as a 32 bit unsigned integer

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

   Name:  Attainable-Net-Data-Rate-Upstream

   Type:  0x0085
   Description:  Maximum net upstream rate that can be attained on the
      DSL line.  This is an optional TLV.

   Length:  4 bytes consist of 1
         byte of Count, followed by 1 byte of Timeout, followed by two
         pad bytes of zero.

         +  Count (1 byte) : Number of loopback cells/messages

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

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

   Name:  Attainable-Net-Data-Rate-Downstream

   Type:  0x0086

   Description:  Maximum net downstream rate that
            should can be generated attained on the local loop as part of the
            loopback test.  The NAS SHOULD restrict the "count" to be
            greater than 0 and less than or equal to 32.  The DSLAM
            SHOULD discard the request for a loopback test, if the
            received test parameters contain
      DSL line.  This is an out of range value for
            the "count" field.  The DSLAM MAY optionally send a failure
            response to the NAS with the code "invalid test parameter".

         +  Timeout (1 byte) : Upper bound on the time optional TLV.

   Length:  4 bytes

   Value:  Rate in seconds that
            the NAS would wait for Kbits/s as a response from the DSLAM.  If the
            total time taken 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 by the DSLAM to complete a test with
            requested parameters, exceeds the specified "timeout" value,
            it can choose to omit the generation of a response to the
            NAS.  DSLAM SHOULD use a locally determined value for the
            "timeout", if the received value of the "timeout" parameter
            is 0.

   o  Type (Opaque-Data = 0x08) : operator.
      This is an optional TLV.  If present
      in the request message, the DSLAM SHOULD reflect it back

   Length:  4 bytes

   Value:  Rate in the
      response unmodified

         Length : (8 bytes)

         Value : Two Kbits/s as a 32 bit integers inserted unsigned integer

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

   Name:  Maximum-Net-Data-Rate-Downstream

   Type:  0x0088

   Description:  Maximum net downstream data rate desired by the NAS (not to be
         interpreted
      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.10.  Minimum-Net-Low-Power-Data-Rate-Upstream TLV

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

   Type:  0x0089

   Description:  Minimum net upstream data rate desired by the DSLAM, but just reflected back operator
      in the
         response).

   The access node generates low power state.  This is an optional TLV.

   Length:  4 bytes

   Value:  Rate in Kbits/s as a success or failure response when it deems 32 bit unsigned integer

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

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

   Type:  0x008A

   Description:  Minimum net downstream data rate desired by the loopback test to be complete.  "Port Management" message (type
   32)
      operator in low power state.  This is used.  The result field SHOULD be set to success or failure.
   The function type SHOULD be set an optional TLV.

   Length:  4 bytes

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

5.2.3.3.6.12.  Maximum-Interleaving-Delay-Upstream TLV

   Name:  Maximum-Interleaving-Delay-Upstream

   Type:  0x008B

   Description:  maximum one way interleaving delay.  This 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 TLV

   Name:  Actual-Interleaving-Delay-Upstream

   Type:  0x008C
   Description:  Value corresponding to 0x09.  The transaction ID SHOULD
   be copied from the sequence number contained interleaver setting.  This
      is an optional TLV.

   Length:  4 bytes

   Value:  Time in the corresponding
   request.  The other parameters not explicitly defined here SHOULD be
   set ms as specified 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 is an
      optional TLV.

   Length:  4 bytes

   Value:  Time in the request message above.  The code field SHOULD
   be set 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 to the interleaver setting.  This
      is an optional TLV.

   Length:  4 bytes

   Value:  Time in ms as a value 32 bit unsigned integer

5.2.3.3.6.16.  DSL-Line-State TLV (Mandatory for Port DOWN)

   Name:  DSL-Line-State

   Type:  0x008F

   Description:  The state of the DSL line.  For the Port UP message, in
      this specification, the range 0x500 to 0x5ff (to be reserved with
   IANA) to indicate TLV is optional (since the status message type
      implicitly conveys the state of the line).  For Port DOWN, the TLV
      is mandatory, since it further communicates the state of the executed test.  The valid values
   defined are (can be extended in future):

      0x500 : Specified access line does not exist

      0x501 : Loopback test timed out

      0x502 : Reserved

      0x503 : DSL line status showtime

      0x504 : DSL line status idle

      0x505 : DSL line status silent

      0x506 : DSL line status training

      0x507 : DSL line integrity error

      0x508 : DSLAM resource not available

      0x509 : Invalid test parameter

   The Extension value can contain one
      as IDLE or more TLVs including the SILENT.

   Length:  4 bytes

   Value:  32 bit unsigned integer

         SHOWTIME = 1

         IDLE = 2

         SILENT = 3

5.2.3.3.6.17.  Access-Loop-Encapsulation TLV to
   identify

   Name:  Access-Loop-Encapsulation

   Type:  0x0090

   Description:  The data link protocol and, optionally, the access line
      encapsulation overhead on which the test was performed, and details
   from executing access loop.  This is an optional
      TLV.  However, when this TLV is present, the test. data link protocol
      MUST minimally be indicated.  The access line identifier SHOULD encapsulation overhead MAY be
   identical
      indicated.  The Access Node can choose to what was contained in not convey the request.
      encapsulation on the access loop by specifying a value of 0 (NA)
      for the two encapsulation fields

   Length:  3 bytes

   Value:  The relevant TLVs
   are:

   o  Type (Access-Loop-Circuit-ID = 0x01) : three bytes (most to least significant) and valid set of
      values for each byte are defined in section
      Section 5.4.1

   o  Type (Access-Aggregation-Circuit-ID-Binary below.

         Byte 1: Data Link

            ATM AAL5 = 0x06): defined in
      section Section 5.4.1

   o  Type (Access-Aggregation-Circuit-ID-ASCII 0

            ETHERNET = 0x03): defined in
      section Section 5.4.1

   o  Type (Opaque-Data 1

         Byte 2: Encapsulation 1

            NA = 0x08) : Data inserted by the NAS in the
      request reflected back by the DSLAM.

         Length : (up to 8 bytes)

         Value : Two 32 bit integers as received in the request (opaque
         to the DSLAM).

   o  Type (OAM-Loopback-Test-Response-String 0

            Untagged Ethernet = 0x09)

         Length : (up to 128 bytes)

         Value : Suitably formatted ASCII string containing useful
         details about the test that 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 is illustrated in Figure 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    TLV Type = 0x0090          |        Length = 3             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Data link     |    Encaps 1   |    Encaps 2   | Padding (=0)  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 9: The Access-Loop-Encapsulation TLV

5.3.  ANCP based DSL Line Configuration

5.3.1.   Goals

   Following dynamic discovery of access topology (identification of DSL
   line and its attributes) as assisted by the NAS will display for mechanism described in
   the
         operator, exactly as received from previous section (topology discovery), the DSLAM (no manipulation/
         interpretation NAS may query a
   subscriber management OSS system (e.g., RADIUS server) to retrieve
   subscriber authorization data (service profiles).  Most of such
   service mechanisms are typically enforced by the NAS).  This is an optional TLV, NAS itself, but
   there are a few cases where it is
         strongly recommended, that in case of ATM based local loop, may be useful to push such service
   parameters to the DSLAM at the very least indicates via this TLV, the total
         loopback cells generated and for local enforcement of a mechanism (e.g.
   DSL-related) on the total loopback cells
         successfully received as part corresponding subscriber line.

   One such example of executing a service parameter that can be pushed to the requested
         loopback test.

5.4.5.  Additional GSMP Extensions for future use cases

   GSMP protocol defined in [RFC3292] allows
   DSLAM for two messaging
   principles in case of Request/Response interaction:

   o  The same message type used local enforcement is DSL "interleaving delay".  Longer
   interleaving delay (and hence stringent error correction) is required
   for both request message and response
      message where result field and code field settings are used a video service to
      differentiate between request and response messages;

   o  Two different message types ensure better video "quality of experience",
   whereas for request message and response
      messages.

   First message principle has been adopted a VoIP service or for use cases defined "shoot first" gaming service, a
   very short interleaving delay is more appropriate.  Another relevant
   application is downloading per subscriber multicast channel
   entitlement information in
   sections Section 5.4.2 to Section 5.4.4, IPTV applications where the purpose of this section DSLAM is to specify
   performing IGMP snooping or IGMP proxy function.  Using ANCP, the second type of approach in order to allow NAS
   can achieve the use goal of this message principle for pushing line configuration to the development DSLAM by an
   interoperable and standardized protocol.

   If a subscriber wants to choose a different service, it can require
   an operational-expense-intensive reconfiguration of future use cases.

   In the new message paradigm different message types are used as ANCP
   Request Message line via a
   network operator, possibly implying a business-to-business
   transaction between an ISP and an access provider.  Using ANCP Response Message: for
   line configuration from the format of a generic
   ANCP message starts with NAS dramatically simplifies the common GSMP header as in the case of the
   existing ANCP implementation, but the Result field is set to Ignore
   in order to instruct the receipt to ignore this field OSS
   infrastructure for service management, allowing fully centralized
   subscriber-related service data (e.g., RADIUS server back-end) and follow the
   procedures specified
   avoiding complex cross-organization business-to-business
   interactions.

   The best way to change line parameters is by using profiles.  These
   profiles (DSL profiles for different services) are pre-configured on
   the received message type. DSLAMs.  The Transaction
   Identifier field is used to distinguish between request messages and
   to associate NAS can then send a response message reference to a request.  Applications that
   require such response correlation MUST set the Transaction Identifier
   to a value in right DSL
   profile via ANCP.  Alternatively, discrete DSL parameters can also be
   conveyed by the range (1, 2^24 - 1).  When used NAS in this manner, the
   Transaction Identifier sequencing MUST be maintained independently
   for each ANCP adjacency and per message type.  Furthermore, it SHOULD
   be incremented linearly for each ANCP.

5.3.2.  Message Flow

   Triggered by topology information reporting a new message of DSL line or
   triggered by a subsequent user session establishment (PPP or DHCP),
   the given type,
   cycling back NAS may send line configuration information (e.g. reference to 1 after running the full range.  Message types not
   requiring response message correlation SHOULD set the Transaction Id
   field a
   DSL profile) to 0x0.  In the event of an ANCP transport protocol failure,
   all pending DSLAM using ANCP messages destined to the disconnected recipient can
   be discarded until the transport is re- established following which
   the Transaction Identifier is re- initialized. Port Management messages.  The value of the Transaction Identifier in a Response message MUST be
   set to that of
   NAS may get such line configuration data from a policy server (e.g.,
   RADIUS).  Figure 10 summarizes the respective Request message.  This allows interaction.

   +----------+   +-----+     +-----+    +-------+    +-----------+
   |Radius/AAA|---| NAS |-----| AN  |----|  Home |----|Subscriber |
   |Policy    |   +-----+     +-----+    |Gateway|    +-----------+
   |Server    |                          +-------+
   +----------+

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

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

   The NAS may update the
   Requester line configuration due to correlate a subscriber service
   change (e.g. triggered by the Response to policy server).  Figure 11 summarizes
   the original Request. interaction.

                      +------+     +-------+   +---------+  +----------+
                      | NAS  |-----|  AN   |---|  Home   |--|Subscriber|
                      +------+     +-------+   | Gateway |  +----------+
                                               +---------+

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

     +-----------+                      2. Service On Demand
     |           |<-----------------------------------------------
     | Web portal|
     |  OSS etc  | 3.Change of
     |           | Authorization
     |Radius AAA | --------> 4.Port Management
     |  Policy   |              Message
     |           |          ------------->
     +-----------+       (Updated Line Config - New Profile)

   Figure 11: Message flow - ANCP Mapping For Updated Line Configuration
   The
   Transaction Identifier format of relevant extensions to port management message is not used
   defined in ANCP adjacency messages.  Also,
   other ANCP applications not requiring it SHOULD set section Section 5.3.3.  The line configuration models
   could be viewed as a form of delegation of authorization from the Transaction
   Identifier NAS
   to 0x0 in their messages.

   All TLVs within the ANCP message have to be 32 bit aligned, and when
   necessary padded with 0s to DSLAM.

5.3.3.  Specification of the 32 bit boundary.  The padding is not
   reflected in ANCP DSL Line Configuration Capability

5.3.3.1.  Protocol Requirements

   The DSL line configuration capability is assigned capability type
   0x02.  No capability data is associated with this capability.
   Implementations of the message length field.

5.4.5.1.  General well known TLVs

   This section contains DSL line configuration capability MUST support
   the definitions of three general well known
   TLVs.  These TLVs are intended to be re-usable across different
   messages.

5.4.5.1.1.  Target TLV

   The Target TLV (0x1000 - 0x01020) following ANCP protocol elements:

   o  ANCP Port Management message, which is intended to be a general well
   known TLV allowing based on the representation of different types GSMPv3
      [RFC3292] message of objects.
   Its use is not restricted to any the same name but includes capability-
      specific modifications and extensions (Section 5.3.3.2).

   o  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 in Section 5.3.3.4).

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

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

    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           TCP/IP Encapsulating Header (Section 4.2)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                ANCP General 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| Message Type  |   Tech Type = Target   |        Target-TLV Block Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     # of TLVs               | Extension Block length (bytes)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                         Target Info                             TLVs                              ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Target TLV:

             TLV (0x1000 - 0x1020) indicating the type of target being
             addressed.  Target TVL 0x1000 indicates

                                 Figure 12

   See Section 4.4 for a single Access-
             Port.

   Target TLV Length:

             Length in bytes description of Target Info.  Excludes TLV header

   Target Info:

             Target information as defined for each the given target. ANCP general message header.
   The Message Type field can consist of sub-TLVs.

   In its simplest form, when targeting a single access line the Target-
   TLV will MUST be set to a value of (0x1000), and carry in its payload one
   or more sub-TLVs identifying the target. 32.  The following example
   illustrates the message format for a single port identified by an
   Access-Loop-Circuit-ID TLV (0x0001) that could 12 bit Code field MUST
   be derived from a
   Port-UP message:

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 set to 0.  The 4 5 6 7 8 9 0 bit Result field MUST be set to either 1 (NAck)
   or 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    TLV Type = Target          |        Target-TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Access-Loop-Circuit-ID=0x0001 |       Circuit-ID Length       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                    Access Loop Circuit ID                     ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.4.5.1.2.   Command TLV (AckAll), as determined by policy on the NAS.  The Command TLV (0x11) is intended to 24-bit
   Transaction Identifier field MUST be set to a general well known TLV
   allowing the encapsulation of one or more command directives positive value.  Other
   fields in a TLV
   oriented message.  The semantics of the command are allowed to general header MUST be
   specified for each message type, ie different set as described in Section 4.4.

   The Port Management message types that
   choose to carry the Command TLV are expected format defined in [RFC3292] has been
   modified to define contain additional data at the meaning end of the content of message.  Also,
   the payload, which could be re-used from those already
   defined elsewhere if appropriate.

        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 = Command        |       Command-TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                         Command Info                          ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Additional sub-TLV Type   |   Additional sub-TLV Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                   Additional sub-TLV data                     ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Command TLV:

             TLV (0x11) indicating original two byte Function field has been modified to contain one
   byte for the contents Function field indicating a specific action to be taken
   by the recipient of the message, and one or more
             command directives.

   Command TLV Length:

             Combined length byte for X-Function field,
   which further qualifies the action specified in bytes of the Function field.
   Any Function specific data MUST be carried in Command Info TLVs in the extension
   block.

   The Port, Port Session Number, and
             sub-TLV.  Excludes Event Sequence Number fields are
   not used by the Command TLV header

   Commad-Info:

             Command information as defined for each message type. DSL Line Configuration capability and MUST be
   considered reserved.  The
             field can consist handling of sub-TLVs.

   Additional sub-TLV:

             Additional sub-TLVs can be present unused/reserved fields is
   described in a command TLV.  Any
             such sub-TLVs must directly follow each command. Section 4.4.2.1.

   The remaining message fields are described as follows:

   R Flag:  not used by ANCP.

   Additional sub-TLV Length:

             Number of actual bytes contained in Port Management flags:  the value portion of
             each additional sub-TLV

5.4.5.1.3.  Status-info TLV

   The Status-info-TLV is intended flag bits marked 'x' following
      the R flag are not used by ANCP.

   Duration:  not used for DSL line configuration.

   Function:  action to be a general well known TLV used performed.  For DSL line configuration,
      Function MUST be set to convey the status code regarding commands and/or requests.  The
   format of the Status-info-TLV (0x0106) is shown below.

        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 = Status-info     |        Status TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Reserved   |  Msg Type     |      Error Message Length     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Error Message (aligned (Configure Connection Service Data).
      This action type requests the Access Node (i.e., DSLAM) to 4 bytes length)              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           sub-TLVs...                                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   Status-info TLV:

             TLV (0x106) conveying apply
      service configuration data contained in the status or error response extension value (TLVs)
      to the DSL line (identified by one of a
             command

   Status TLV Length:

             Specifies the length TLVs in bytes of the Status Info TLV
             payload.  Excludes extension
      value).

   X-Function:  qualifies the TLV header

   Reserved:

             This action set by Function.  For DSL line
      configuration, this field MUST be set to all zeroes 0.

   Event Flags:  not used by ANCP.

   Flow Control Flags:  not used by ANCP.

   Extension Flags:  the sender and
             ignored flag bits denoted by 'x' before the receiver.

   Msg Message
      Type field are reserved for future use.

   Message Type:

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

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

   Block Length:  unused, reserved.

   # of TLVs:  the Status-info TLV
             is reporting on

   Error Message number of TLVs that follow, not counting TLVs
      encapsulated within other TLVs.

   Extension Block Length:

             It contains  the total length of an optional error message or 0 if
             none.

   Error message:

             It contains a human-readable description of the error being
             reported by TLVs carried in the Status-info field.

   TLVs:

             This
      extension block in bytes, including any padding within individual
      TLVs.  (The existing "Block Length" field inherited from the GSMP
      message is of indeterminate length, and contains zero limited to 255 bytes and is not sufficient).

   TLVs:  two or more of the TLVs associated with the Status-info TLV.  The
             following TLVs are RECOMMENDED to be provided if the
             indicated Code values are given in identify a DSL line and configure its
      service data.

5.3.3.3.  Procedures

   Section 5.3.2 Describes the header of circumstances under which the NAS sends a
   Port Management message containing to the Status-info TLV:

             Code value 4 or 5: AN to configure DSL service parameters
   for a specific subscriber line.  To identify the Target or other TLV identifying line, the
             unknown NAS MUST
   include one of Access-Loop-Circuit-ID TLV, Access-Aggregation-
   Circuit-ID-Binary TLV, or unavailable port.

             Code value 84: the Access-Aggregation-Circuit-ID-ASCII TLV that is unsupported or contains in
   the
             unsupported value.

5.4.5.2.  Generic Response Message

   This section defines Port Management message, depending upon the Generic Response message. deployment scenario.
   The Generic
   Response message NAS MUST include one or more TLVs to configure line service
   parameters for that line.  Section 5.3.3.4 currently identifies only
   one such TLV, Service-Profile-Name, but other TLVs may be specified as added by
   extensions to ANCP.

   If the appropriate response NAS sets Result to AckAll (0x1) and the AN processes the Port
   Management message successfully, the AN MUST return a Port Management
   message defined in an extension to ANCP, instead of a more specific
   response message.  As reply, containing a general guideline, specification Result field set to Success (0x3).
   All other fields of the
   Generic Response returned message as a response is appropriate where no data
   needs to MUST be returned identical to the peer other than a result (success or
   failure), plus, those
   received in the case of a failure, a code indicating request.

   If an error occurs during the
   reason for failure and a limited amount processing of diagnostic data.
   Depending on the particular use case, Port Management
   message, then the Generic Response message
   MAY be sent by either the NAS or the AN.

   The AN or NAS MAY send MUST always return a Generic Response Port Management message indicating a
   failure condition independently of a specific request before closing
   the adjacency as a consequence of that failure condition.  In this
   case, the sender MUST set the Transaction Identifier field in the
   header and
   with the Message Type Result field within the Status-info TLV set to
   zeroes. Failure (0x4).  The receiver MAY record the information contained in Code field MUST be
   set to indicate the
   Status-info TLV reason for management use. failure.  The format remainder of the Generic Response message is shown in Figure 17
    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 (0x88-0C)         |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vers  |  Sub  |MessageType=91 |Result |        Code           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Partition ID  |            Transaction Identifier             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|      SubMessage Number      |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Status-info-TLV=0x106  |      Status-TLV-Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Reserved     |  Msg type     |    Error Message Length       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Error Message (padded to 4) if Length &gt; 0        |
   +---------------------------------------------------------------+
   |           sub-TLVs...                                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 17: Structure of
   MUST be copied from the Generic Response Message

   Message Type: request.  The message type value for AN MAY add a Status-Info TLV
   (Section 6.2.3) to provide further information on the Generic Response message is 0x91.

   Result:

      The value of error, in which
   case the Result various length fields and the # of TLVs field for within the Generic Response
   message MUST be either Success (0x03) or Failure (0x04).

   Code:

      The Code field MUST have value zero if Result adjusted accordingly.

5.3.3.4.  TLVs For DSL Line Configuration

   Currently only the following TLV is set to Success
      (0x03).  It MUST have an appropriate non-zero value if Result is
      set to Failure (0x04).  As discussed in section 5, extensions to
      ANCP MAY define new Code values for use in failure responses for
      specific request message types.

   Partition ID:

      As specified in section Section 5.

   Transaction Identifier:

      The Transaction Identifier MUST be copied from the request to
      which the Generic Response message is responding.

   I, Sub-message Number, Length:

      As specified in Section 5.

   Status-info TLV:

      MAY be present in a success response, to provide a warning as
      defined for a specific request message type.  MUST DSL line
   configuration.  More TLVs may be present defined in a
      failure response.  The Message Type field value is copied from the
      header of the request message.  The Error Message field contains
      human-readable diagnostic text.  The description future version of the response
      for a particular request message type MAY specify further sub-TLVs
      to be included in Status-info, either generally this
   specification or in ANCP extensions for specific
      failure Code values.

5.5.  ATM-specific considerations

   The topology discovery and line configuration involve the DSL line
   attributes.  For ATM based access networks, the individual service attributes
   of a DSL line (e.g. rates, interleaving delay, multicast channel
   entitlement access-list).

   Name:  Service-Profile-Name

   Type:  0x0005

   Description:  Reference to a pre-configured profile on the DSLAM
   is identified by the port and PVP/PVC corresponding to that
      contains service specific data for the subscriber.  The DSLAMs are connected

   Length:  up to 64 bytes
   Value:  ASCII string containing the profile name (which the NAS via an
      learns from a policy server after a subscriber is authorized).

5.4.  ANCP Based DSL Line Testing Capability

   In a mixed Ethernet and ATM access
   aggregation network.  Since, network (including the DSLAM (access-node) local
   loop), it is not directly
   connected desirable to the NAS, the NAS needs a 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 to learn
   until end-to-end Ethernet OAM mechanisms are more widely implemented
   in various network elements.

   A simple solution based on ANCP can provide the DSL NAS with an access
   line
   identifier (more generally referred to as "Access Loop Circuit-ID")
   corresponding test capability and to some extent fault isolation.  Controlled
   by a subscriber.  The "Access loop circuit-ID" has no local significance on management interface the NAS.  The NAS can use an ANCP messages for topology
   discovery and line configuration carry opaque "Access loop
   Circuit-ID" which has only local significance operation to
   trigger the Access Node to perform a loopback test on the DSLAMs.

   The access local loop circuit identifier can be carried as an ASCII string
   in
   (between the Access Node and the CPE).  The Access Node can respond
   via another ANCP messages.  This allows ANCP to be decoupled from operation with the
   specifics result of the underlying access technology being controlled.  On triggered loopback
   test.  In the other hand, this requires a NAS mechanism by which such
   identifier case of ATM based local loop the ANCP operation can be correlated to
   trigger the context of an "aggregation
   network" facing IP interface (corresponding Access Node to the subscriber) generate ATM (F4/F5) loopback cells on the
   NAS.  This would typically require
   local configuration of such IP
   interfaces, or of loop.  In the underlying ATM interfaces.

5.6.  Ethernet-specific considerations

   One possible way case of approaching Ethernet, the use of Access Node can trigger an
   Ethernet technology in the
   access aggregation network is to recreate loopback message(per EFM OAM) on the equivalent of Virtual
   Paths (VPs) and Virtual Circuits (VCs) local loop.

5.4.1.  Message Flow

   The Port Management message can be used by using stacked Virtual LAN
   tags.  As an example, one could use an "outer" VLAN the NAS to create a form
   of "virtual path" between a given DSLAM and a given NAS.  And then
   use "inner" VLAN tags request Access
   Node to create trigger a form of "virtual circuit" remote loopback test on a per
   DSL line basis.  In this case, VLAN tags conveyed in topology
   discovery and line configuration messages will allow to uniquely
   identify the DSL line in a straightforward manner, assuming local loop.  The result
   of the VLAN
   tags are not translated in some way loopback test can be asynchronously conveyed by the aggregation network, and
   are unique across physical ports.

   However, some carriers do not wish to 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 is the N:1 model.  In this model, or in
   the case where user traffic is sent untagged, the access node needs Access
   Node to insert the exact identity of the DSL line NAS in the topology
   discovery and line configuration messages, and then hve a mechanism
   by which this can be correlated to the context Port Management response message.  The formats
   of an "aggregation
   network" facing IP interface (for the subscriber) on the NAS.  This
   can either be based on local configuration on relevant extensions to the NAS, or on Port Management message are defined
   in Section 5.4.2.2.  Figure 13 summarizes the fact
   that such interaction.

 +-------------+    +-----+       +-------+           +----------------+
 |Radius/AAA   |----|NAS  |-------| DSLAM (access node) typically inserts the "Access Loop
   Circuit ID" in subscriber signaling messages relayed to the NAS (i.e.
   DHCP or PPPoE discovery messages).

   Section Section 5.4.1 defines "Access Loop Circuit ID".

6.  IANA Considerations

   This document defines the following additions to the GSMPv3 Message
   Type Name Space registry:

                 +--------------+--------+---------------+
                 | Message      | Number | Source        |
                 +--------------+--------+---------------+
                 | Provisioning |-----------|    CPE         | 93
 |Policy Server|    +-----+       +-------+           | This document (DSL Modem +   |
                 +--------------+--------+---------------+

   This document defines the following modification to the General
   Switch
 +-------------+                                      |Routing Gateway)|
                                                      +----------------+
                  Port Management Protocol version 3 (GSMPv3) Result Type Name Space
   registry:

         +--------------+------------------------+---------------+
         | Result Value | Result Type Name       | Reference     |
         +--------------+------------------------+---------------+
         | 0            | Ignore (from Reserved) | This document |
         +--------------+------------------------+---------------+

   This document defines the following addition to the GSMPv3 Message
   Function Name Space registry [editor's note GMSPv3 did not define a
   Name Space for Function even if RFC3292 defines values for function
   field]:

           +----------------+-----------------+---------------+
           | Function Value | Function Name   | Reference     |
           +----------------+-----------------+---------------+
           | 0x09           | Remote
                  (Remote Loopback          ATM loopback | This document |
           +----------------+-----------------+---------------+

   The GSMPv3 Failure Response
                   Trigger Request)         OR EFM Loopback
                1.  ---------------->     2. --------->
                                             <--------+
                     3. <---------------
                     Port Management Message Name Space is extended from the
   GSMPv3 limit of 255 to a new upper limit
                (Remote Loopback Test Response)

                Figure 13: Message Flow For ANCP based OAM

5.4.2.  Specification of 4095 and the ANCP DSL Line  Testing Capability

5.4.2.1.  Protocol Requirements

   The DSL line testing capability is assigned capability type 0x04.  No
   capability data is associated with this document
   adds capability.  Implementations
   of the DSL line testing capability MUST support the following values to ANCP
   protocol elements:

   o  ANCP Port Management message, which is based on the GSMPv3 Failure Response Message Name
   Space registry:

   +-------------------+-----------------------------------+-----------+
   | Failure Response  | Failure Response Message Name     | Reference |
   | Message Value     |                                   |           |
   +-------------------+-----------------------------------+-----------+
   | 81d               | Request
      [RFC3292] message type not          | This      |
   |                   | implemented (0x51)                | document  |
   | 82d               | Transaction identifier out of     | This      |
   |                   | sequence (0x52)                   | document  |
   | 83d               | Malformed the same name but includes capability-
      specific modifications and extensions (Section 5.4.2.2).

   o  The procedures associated with this message (0x53)          | This      |
   |                   |                                   | document  |
   | 84d               | and its contents
      (Section 5.4.2.3).

   o  Access-Loop-Circuit-ID TLV or value not supported by     | This      |
   |                   | negotiated capability set (0x54)  | document  |
   | 85d               | Invalid value (as defined in Section 5.2.3.3);

   o  Access-Aggregation-Circuit-ID-Binary TLV (0x55)       | This      |
   |                   |                                   | document  |
   | From 256d to 499d | Reserved for IETF use (0x0100 -   | This      |
   |                   | 0x1F3)                            | document  |
   | 1280d             | Specified access line does (as defined in
      Section 5.2.3.3);

   o  Access-Aggregation-Circuit-ID-ASCII TLV (as defined 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    | This      |
   |                   | exist (0x500)                     | document  |
   | 1281d             | Loopback test timed out (0x501)   | This      |
   |                   |                                   | document  |
   | 1282d             | Reserved (0x502)                  | This      |
   |                   |                                   | document  |
   | 1283              | DSL line status showtime (0x503)  | This      |
   |                   |                                   | document  |
   | 1284              | otherwise indicated, the TLVs listed above are defined in
   Section 5.4.2.4.

5.4.2.2.  Message Format

   The Port Management message for DSL line status idle (0x504)      | This      |
   |                   |                                   | document  |
   | 1285              | testing has the same format
   as for DSL line status silent (0x505)    | This      |
   |                   |                                   | document  |
   | 1286              | configuration (see Section 5.3.3.2), with the
   following differences:

   o  The Result field in the request SHOULD be set to AckAll (0x1), to
      allow the NAS to receive the information contained in a successful
      test response.

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

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

5.4.2.3.  Procedures

   The ANCP Port Management message as described in Section 5.4.2.2 MAY
   be used by the NAS to trigger the Access Node to run a loopback test
   on the local loop.  To identify the line to 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 Port Management message, depending upon the deployment scenario.
   The NAS MAY include the OAM-Loopback-Test-Parameters and/or Opaque-
   Data TLVs (defined in Section 5.4.2.4) to configure the loopback test
   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 the OAM-Loopback-Test-
   Parameters TLV in Section 5.4.2.4.)  The Result field MUST be set to
   Success (0x3) or Failure (0x4) as applicable.  The Code field SHOULD
   be set to one of the following values if applicable.

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

   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 (0x506)  | This      |
   |                   |                                   | document  |
   |

   1287              | (0x507):  DSL line integrity error (0x507)  | This      |
   |                   |                                   | document  |
   |

   1288              | (0x508):  DSLAM resource not available      | This      |
   |                   | (0x508)                           | document  |
   |

   1289              | (0x509):  Invalid test parameter (0x509)    | This      |
   |                   |                                   | document  |
   | From 509d to      | Reserved for IETF use (0x1FD -    | This      |
   | 4095d             | 0XFFF)                            | document  |
   +-------------------+-----------------------------------+-----------+

   This document reserves

   All other fields including the values 256 to 499 appended TLVs MUST be copied from the
   request, except that the OAM-Loopback-Test-Parameters TLV MUST NOT
   appear in the response and 509 the OAM-Loopback-Test-Response-String TLV
   SHOULD appear in the response.

   Section 5.4.2.4 contains additional procedures relating to 4095 within specific
   TLVs.

5.4.2.4.  TLVs For the GSMPv3 Failure Response Message Name Space registry DSL Line Test Capability

   The following TLVs have been defined for use by
   extensions to with the Access Node Control Protocol (ANCP).

   This document defines DSL line
   testing capability.

5.4.2.4.1.  OAM-Loopback-Test-Parameters TLV

   Name:  OAM-Loopback-Test-Parameters

   Type:  0x0007

   Description:  Parameters related to a new ANCP Version Space registry.  The initial
   entry is as follows:

        +--------------------+-------------------+---------------+
        | ANCP Version Value | ANCP Version Name | Reference     |
        +--------------------+-------------------+---------------+
        | 3                  | ANCP Version      | This document |
        +--------------------+-------------------+---------------+ loopback test.  This document defines a new ANCP Sub-Version Space registry.  The
   initial entry is as follows:

    +------------------------+-----------------------+---------------+
    | ANCP Sub-Version Value | ANCP Sub-Version Name | Reference     |
    +------------------------+-----------------------+---------------+
    | an
      optional TLV.  If this TLV is not present in the request message,
      the DSLAM SHOULD use locally determined default values for the
      test parameters.

   Length:  2 bytes

   Value:  two 1 [*]                  | ANCP Sub-Version      | This document |
    +------------------------+-----------------------+---------------+

   [*] Editor's note: sub-version needs byte fields described below (listed in order of most to
      least significant).

         Byte 1: Count.  Number of loopback cells/messages that should
         be changed from 1 generated on the local loop as part of the loopback test.
         The NAS SHOULD restrict the "count" to 2 upon
   publication

   This document defines be greater than 0 and
         less than or equal to 32.  The DSLAM SHOULD discard a new ANCP Tech Type Name Space registry. request
         for a loopback test, if the received test parameters contain an
         out of range value for the "count" field.  The
   initial entries are as follows:

     +-----------------+----------------------------+---------------+
     | Tech Type Value | Tech Type Name             | Reference     |
     +-----------------+----------------------------+---------------+
     | 0x00            | Extension block not AN MAY include a
         Code value of 0x509 "Invalid test parameter" in the resulting
         failure response to the NAS.

         Byte 2: Timeout.  Upper bound on the time in seconds that the
         NAS will wait for a response from the DSLAM.  If the total time
         taken by the DSLAM to complete a test with requested
         parameters, exceeds the specified "timeout" value, it MAY
         choose to omit the generation of a response to the NAS.  The
         DSLAM SHOULD use | This document |
     | 0x01            | PON                        | This document |
     | 0x05            | DSL                        | This document |
     | 0x06 - 0xFE     | Reserved                   | This document |
     | 0xFF            | Base Specification Use     | This document |
     +-----------------+----------------------------+---------------+

   This document defines a new ANCP Command Code registry. locally determined value for Timeout, if the
         received value of the Timeout parameter is 0.

   The initial
   entries are as follows:

   +-----------------------------+--------------------+---------------+ OAM-Loopback-Test-Parameters TLV is illustrated 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Command Code Directive Name    TLV Type = 0x0007          | Command Code Value        Length = 2             | Reference
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |
   +-----------------------------+--------------------+---------------+   Count       | Reserved  Timeout      | 0x00         Padding (=0)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Figure 14: The OAM-Loopback-Test-Parameters TLV

5.4.2.4.2.  Opaque-Data TLV

   Name:  Opaque-Data

   Type:  0x0008

   Description:  This document |
   +-----------------------------+--------------------+---------------+ is an optional TLV.  If it is present in the
      request message, the DSLAM SHOULD reflect it back in the response
      unmodified.

   Length:  8 bytes

   Value:  Two 32 bit unsigned integers inserted by the NAS (not to be
      interpreted by the DSLAM, but just reflected back in the
      response).

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

   Name:  OAM-Loopback-Test-Response-String

   Type:  0x0009

   Description:  Suitably formatted ASCII string containing useful
      details about the test that the NAS will display for the operator,
      exactly as received from the DSLAM (no manipulation/interpretation
      by the NAS).  This document 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, the total loopback cells
      generated and the total loopback cells successfully received as
      part of executing the requested loopback test.

   Length:  up to 128 bytes

   Value:  ASCII string.

6.  Additional ANCP Messages and TLVs

   This section defines two messages and a new number of TLVs that may be
   useful in multiple capabilities.  Typically the content is under-
   specified, with the intention that particular capabilities spell out
   the remaining details.

6.1.  Additional Messages and General Messaging Principles

6.1.1.  General Principles for the  Design of ANCP TLV Type registry. Messages

   The initial
   entries are as follows:

   +--------------------------------------+--------------+-------------+
   | TLV Name                             | Type 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    | Reference   |
   +--------------------------------------+--------------+-------------+
   | Access-Loop-Circuit-ID               | 0x01         | This        |
   |                                      |              | document    |
   | Access-Loop-Remote-Id                | 0x02         | This        |
   |                                      |              | document    |
   | Access-Aggregation-Circuit-ID-ASCII  | 0x03         | This        |
   |                                      |              | document    |
   | DSL field settings are
       used to differentiate between request and response messages.

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

   The first approach is illustrated by the protocol specifications in
   Section 5.  The purpose of this section is to provide more details
   about the second approach in order to allow the use of this messaging
   construct for the development of additional ANCP extensions.

   As Section 4.4 indicated, all ANCP messages other than adjacency
   messages share a common header format.  When the response message
   type is different from that of the request, the specification of the
   request message will typically indicate that the Result field is set
   to Ignore (0x0) and provide procedures indicating explicitly when the
   receiver should generate a response and what message type it should
   use.

   The Transaction ID field is used to distinguish between request
   messages and to associate a response message to a request.
   Specifications of ANCP messages for applications not requiring
   response correlation should indicate that the Transaction ID must be
   set to zero in requests.  Applications that require response
   correlation should refer to the Transaction ID behaviour described in
   Section 4.4.1.

   The specification for a response message should indicate in all cases
   that value of the Transaction Identifier must be set to that of the
   corresponding request message.  This allows the requester to
   establish whether or not correlation is needed (by setting a non-zero
   or zero value for the Transaction ID).

6.1.2.  Provisioning Message

   The Provisioning message is sent by the NAS to the AN to provision
   information of global scope on the AN.  The Provisioning message has
   the format shown in Figure 15.

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

               Figure 15: Format of the Provisioning Message

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

   Message Type:  MUST be set to 93.

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

   Code:  MUST be set to zero.

   Transaction ID:  MUST be populated with a non-zero value chosen in
      the manner described in Section 4.4.1.

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

   If not otherwise specified, if the AN fails to process the message
   successfully it MUST send a Generic Response message (Section 6.1.3)
   indicating failure and providing appropriate diagnostic information.

6.1.3.  Generic Response Message

   This section defines the Generic Response message.  The Generic
   Response message may be specified as the appropriate response to a
   message defined in an extension to ANCP, instead of a more specific
   response message.  As a general guideline, specification of the
   Generic Response message as a response is appropriate where no data
   needs to be returned to the peer other than a result (success or
   failure), plus, in the case of a failure, a code indicating the
   reason for failure and a limited amount of diagnostic data.
   Depending on the particular use case, the Generic Response message
   MAY be sent by either the NAS or the AN.

   The AN or NAS MAY send a Generic Response message indicating a
   failure condition independently of a specific request before closing
   the adjacency as a consequence of that failure condition.  In this
   case, the sender MUST set the Transaction ID field in the header and
   the Message Type field within the Status-Info TLV to zeroes.  The
   receiver MAY record the information contained in the Status-info TLV
   for management use.

   The format of the Generic Response message is shown in Figure 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)                            +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Status-Info TLV                            |
   ~                    (Section 6.2.3)                            ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 16: Structure of the Generic Response Message

   This document specifies the following fields.  The remaining fields
   in the ANCP general message header MUST be set as specified in
   Section 4.4.1.

   Message Type:  MUST be set to 91.

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

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

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

   Status-Info TLV:  MAY be present in a success response, to provide a
      warning as defined for a specific request message type.  MUST be
      present in a failure response.  See Section 6.2.3 for a detailed
      description of the Status- Info TLV.  The actual contents will
      depend on the request message type this message is responding to.

6.2.  TLVs For General Use

   This section contains the definitions of some TLVs that are intended
   to be re-usable across different message types and capabilities.

6.2.1.  Target TLV

   Name:  Target

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

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

   Length:  Variable, depending on the specific object type.

   Value:  Target information as defined for each object type.  The
      field can consist of sub-TLVs.

   TLV Type 0x1000 is assigned to a variant of the Target TLV
   representing a single access line and encapsulating one or more sub-
   TLVs identifying the target.  Figure 17 illustrates the message
   format for a single port identified by an Access-Loop-Circuit-ID TLV
   (0x0001) that could be derived from a Port-UP message:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    TLV Type = 0x1000          |Length = Circuit-ID Length + 4 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID=0x0001 |       Circuit-ID Length       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Access Loop Circuit ID                     ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 17: Example of Target TLV For Single Access Line

6.2.2.   Command TLV

   Name:  Command

   Type:  0x0011

   Description:  The Command TLV (0x0011) is intended to be a general
      means of encapsulating one or more command directives in a TLV
      oriented message.  The semantics of the command can be specified
      for each message type using it.  I.e., the specification of each
      message type that can carry the Command TLV is expected to define
      the meaning of the content of the payload, although re-use of
      specifications is, of course, permissible when appropriate.

   Length:  Variable, depending on the specific contents.

   Value:  Command information as defined for each message type.  The
      field can include sub-TLVs.  The contents of this TLV MUST be
      specified as one "command" or alternatively a sequence of one or
      more "commands", each beginning with a one-byte Command Code and
      possibly including other data following the Command Code.  An IANA
      registry has been established for Command Code values.  This
      document reserves the Command Code value 0 as an initial entry in
      the registry.

6.2.3.  Status-Info TLV

   Name:  Status-Info

   Type:  0x0106

   Description:  The Status-Info-TLV is intended to be a general
      container for warning or error diagnostics relating to commands
      and/or requests.  It is a supplement to the Code field in the ANCP
      general header.  The specifications for individual message types
      may indicate the use of this TLV as part of responses,
      particularly for failures.  As mentioned above, the Generic
      Response message will usually include an instance of the Status-
      Info TLV.

   Length:  Variable, depending on the specific contents.

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

      Reserved:  see Section 4.4.2.1 for handling of reserved fields.

      Msg Type:  Message Type of the request for which this TLV is
         providing diagnostics.

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

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

      The following TLVs are RECOMMENDED to be appended if the indicated
      Code values are given in the header of the message containing the
      Status-info TLV:

      *  Code value 4 or 5: the Target or other TLV identifying the
         unknown or unavailable port.

      *  Code value 84: the TLV that is unsupported or contains the
         unsupported value.

   Figure 18 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 18: The Status-Info TLV

7.  IANA Considerations

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

7.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; [Editor's Note: GSMPv3 has no function
         code registry, so this one might as well belong to ANCP.
         Coordination between the two protocols is unnecessary because
         of ANCP's reorganization of the Function field.]

         ANCP Technology Types;

         ANCP Command Codes;

         ANCP TLV Types;

         ANCP Capabilities.

7.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    | TLV or value not supported by negotiated      | RFCXXXX   |
   |       | capability set (0x54)                         |           |
   | 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.
   [Editor's Note: what about X-Function?  Probably has to be a sub-
   registry 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:
   [Editor's Note: assumes that proposal to combine version and sub-
   version into a single registry is accepted.]

   +---------+-------------+--------------+----------------------------+
   | Version | Sub-Version | Name         | Reference                  |
   +---------+-------------+--------------+----------------------------+
   | 3       | 1           | Pre-standard | [Could identify a draft    |
   |         |             |              | version]                   |
   | 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:

   [Editor's Note: probably need text in the main body of the document
   explaining 0x00 and 0xFF.  Latter probably has to be Reserved and
   remaining values simply Unassigned.]

       +-----------------+----------------------------+-----------+
       | Tech Type Value | Tech Type Name             | Reference |
       +-----------------+----------------------------+-----------+
       | 0               | Extension block not in use | 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                    | 0x04 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       | This Command                                | RFCXXXX   |
   | 0x0012-0x008 | document Unassigned                             |           | Service-Profile-Name
   | 0x05 0            | This                                        |           |
   | 0x0081       | document Actual-Net-Data-Upstream               | RFCXXXX   | Access-Aggregation-Circuit-ID-Binary
   | 0x06 0x0082       | This Actual-Net-Data-Rate-Downstream        | RFCXXXX   |
   | 0x0083       | document Minimum-Net-Data-Rate-Upstream         | RFCXXXX   | OAM-Loopback-Test-Parameters
   | 0x07 0x0084       | This Minimum-Net-Data-Rate-Downstream       | RFCXXXX   |
   | 0x0085       | document 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                         | RFCXXXX   |
   | 0x0090       | Access Loop Encapsulation              | RFCXXXX   |
   | 0x0091       | DSL-Type                               | RFCXXXX   |
   | 0x092-0x0105 | Unassigned                             |           |
   | 0x0106       | Status-info                            | RFCXXXX   |
   | 0x0107-0x0FF | Unassigned                             |           |
   | F            |                                        |           |
   | 0x1000       | Target (single access line variant)    | RFCXXXX   |
   | 0x1001 -     | Reserved for Target variants           | RFCXXXX   |
   | 0x1020       | Opaque-Data                                        | 0x08           | This
   | 0x1021-0xFFF | Unassigned                             |           |
   | F            |                                        |           |
   +--------------+----------------------------------------+-----------+
   IANA is requested to create a new ANCP Capability registry, with
   additions by IETF Consensus.  Values may range from 0 to 255.  The
   initial entries are as follows:

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

8.  Security Considerations

   Security of the ANCP protocol is discussed in [RFC5713]

9.  Acknowledgements

   The authors would like to thank everyone that has 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.  References

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

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

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

   [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]   Elias, M. and S. Ooghe, "DSL Forum TR-058, Multi-Service
              Architecture & Framework Requirements", September 2003.

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

   [TR_092]   "DSL Forum TR-092, Broadband Remote access server
              requirements document", 2005.

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

Appendix A.  Changes from Version -09 to Version -10

   The changes to this document are editorial, although clarifications
   may have inadvertently introduced some small technical differences.
   The biggest change was a rearrangement of text to provide a clear
   separation between generally applicable protocol aspects and the
   three DSL capabilities documented here.  The following table provides
   a mapping between section numbers in the -09 version and section
   numbers in the -10 version, with comments where text was modified
   significantly.

   +--------------+--------------+-------------------------------------+
   | -09 Section  | OAM-Loopback-Test-Response-String    | 0x09         | This        |
   |                                      |              | document -10 Section  | Comments                            | Reserved
   +--------------+--------------+-------------------------------------+
   | 0x0a-0x0f Abstract     | This Abstract     | Rewritten to better reflect         |
   |              | document              | contents.                           | Target
   | 0x1000 -            | This        |
   |                                      | 0X1020       | document -            | -                                   | Command
   | 0x11 1            | This 1            |                                     |
   | -            | document -            | -                                   | Status-info
   | 0x0106 2            | This 5.2          | First two paragraphs moved.         |
   |              | document              |
   +--------------------------------------+--------------+-------------+

   This document defines Remainder smoothed a new ANCP Capability registry.  The initial
   entries are as follows:

   +----------------------------+----------------------+---------------+
   | Capability Type Name       | Capability Type Code | Reference     |
   +----------------------------+----------------------+---------------+
   | Dynamic-Topology-Discovery | 0x01                 | This document bit.  Added    |
   | Line-Configuration              | 0x02              | This document outline.                   |
   | Transactional-Multicast    | 0x03 -            | This document -            | -                                   | OAM
   | 0x04 2.1          | This document 2.1          |
   +----------------------------+----------------------+---------------+

   This document defines a new Added definitions for TLV, ANCP sub-TLV Type registry.  The initial
   entries are as follows:

   +--------------------------------------------+--------+-------------+
   | sub-TLV Name                               | Type   | Reference   |
   |                                            | Code   |             |
   +--------------------------------------------+--------+-------------+
   | Actual-Net-Data-Upstream                   | 0x81   | This        |
   |                                            |        | document    |
   | Actual-Net-Data-Rate-Downstream            | 0x82   | This     |
   |              |              | document capability, ANCP session            |
   | Minimum-Net-Data-Rate-Upstream              | 0x83              | This (adjacency).                        |
   | -            | -            | document -                                   |
   | Minimum-Net-Data-Rate-Downstream 3, 3.1, 3.2  | 0x84 Same         | This                                     |
   | -            | -            | document -                                   |
   | Attainable-Net-Data-Rate-Upstream 4.1          | 0x85 5.1          | This First paragraph dropped.            |
   | -            | -            | document -                                   |
   | Attainable-Net-Data-Rate-Downstream 4.2.1, 4.2.2 | 0x86 5.2.1, 5.2.2 | This                                     |
   | -            | -            | document -                                   |
   | Maximum-Net-Data-Rate-Upstream 4.3.1, 4.3.2 | 0x87 5.3.1, 5.3.2 | This                                     |
   | -            | -            | document -                                   |
   | Maximum-Net-Data-Rate-Downstream 4.4, 4.4.1   | 0x88 5.4, 5.4.1   | This                                     |
   | -            | -            | document -                                   |
   | Minimum-Net-Low-Power-Data-Rate-Upstream 5            | 0x89 4.4, 4.4.1,  | This In 4.4.1, added normative text for  |
   |              | 4.4.2.1, 4   | document Transaction ID taken from old       |
   | Minimum-Net-Low-Power-Data-Rate-Downstream              | 0x8A              | This 5.4.5.  Did not include "Extension  |
   |              |              | document Block" as generally usable          |
   | Maximum-Interleaving-Delay-Upstream              | 0x8B              | This structure, but this decision is     |
   |              |              | document subject to WG review.               |
   | Actual-Interleaving-Delay-Upstream -            | 0x8C -            | This -                                   |
   | 5.1          | 4.2          | document Added normative text from old       |
   | Maximum-Interleaving-Delay-Downstream              | 0x8D              | 5.4.5.  This text need review.      |
   | -            | -            | document    |
   | Actual-Interleaving-Delay-Downstream       | 0x8E   | This        | -                                   |
   | 5.2, 5.3     | document 4.3 and      | Capabilities were renamed to        | DSL line state
   | 0x8F              | This sub-sections | explicitly include "DSL" as part of |
   |              | document              | the name.  OAM was renamed to line  | Access Loop Encapsulation
   | 0x90              | This              | testing, since that is all that is  |
   |              | document              | included.                           | DSL-Type
   | 0x91 -            | This -            | -                                   |
   | 5.4.1.1      | document 5.2.3.2,     |
   +--------------------------------------------+--------+-------------+

7.  Security Considerations

   Security of the ANCP protocol is discussed in [RFC5713]

8.  Acknowledgements

   The authors would like to thank everyone that has provided comments
   or inputs to this document.  In particular, the authors acknowledge
   the inputs provided by Wojciech Dec, Peter Arberg, Josef Froehler,
   Derek Harkness, Kim Hyldgaard, Sandy Ng, Robert Peschi, Michel
   Platnic and Tom Taylor.

9.  References

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

9.2.  Informative References

   [ANCP-FRAMEWORK]
              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",
              draft-ietf-ancp-framework-13.txt, work in progress,
              February 2010.

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

   [RFC5713]  Moustafa , H., Tschofenig, H., and S. De Cnodder,
              "Security Threats and Security Requirements for the Access
              Node Control Protocol (ANCP)", January 2010.

   [TR-058]   Elias, M. Merged into message format          |
   |              | 5.3.3.2      | descriptions.                       |
   | -            | -            | -                                   |
   | 5.4.2        | 5.2.3.2,     | Contents scattered due to           |
   |              | 5.2.3.3, and S. Ooghe, "DSL Forum TR-058, Multi-Service
              Architecture & Framework Requirements", September 2003.

   [TR-059]   Anschutz, T., "DSL Forum TR-059, DSL Evolution | separation of message format,       |
   |              | sub-sections | procedures, TLV definitions.        |
   | -
              Architecture Requirements for the Support            | -            | -                                   |
   | 5.4.3        | 5.3.3.2      |                                     |
   | -            | -            | -                                   |
   | 5.4.3.1      | 6.1.2        | Provisioning message was not really |
   |              |              | related to line provisioning.       |
   | -            | -            | -                                   |
   | 5.4.4        | Sub-sections | Contents scattered due to           |
   |              | of QoS-Enabled
              IP Services", September 2003.

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

   [TR-101]   Cohen et al, "Architecture & Transport: "Migration 5.4.2     | separation of message format,       |
   |              |              | procedures, TLV definitions.        |
   | -            | -            | -                                   |
   | 5.4.5        | 6.1.1        | Normative text on Transaction ID,   |
   |              |              | discarding of messages removed to
              Ethernet Based DSL Aggregation", DSL Forum TR-101", 2005.   |
   |              |              | 4.4 and 4.2 respectively.           |
   | -            | -            | -                                   |
   | 5.4.5.1 and  | 6.2 and      |                                     |
   | sub-sections | sub-sections |                                     |
   | -            | -            | -                                   |
   | 5.4.5.2      | 6.1.3        |                                     |
   | -            | -            | -                                   |
   | 5.5, 5.6     | 5.1.1, 5.1.2 |                                     |
   | -            | -            | -                                   |
   | 6, 7, 8, 9   | 7, 8, 9, 10  |                                     |
   +--------------+--------------+-------------------------------------+

Authors' Addresses

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

   Phone:
   Fax:
   Email: swadhwa@juniper.net

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

   Phone:
   Fax:
   Email: jmoisand@juniper.net
   Swami Subramanian
   Juniper Networks
   10 Technology Park Drive
   Westford, MA  01886
   USA

   Phone:
   Fax:
   Email: ssubramanian@juniper.net
   Thomas Haag
   Deutsche Telekom
   Heinrich-Hertz-Strasse 3-7
   Darmstadt,   64295
   Germany

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

   Norber

   Norbert Voigt
   Nokia Siemens

   Phone:
   Fax: Networks
   Siemensallee 1
   Greifswald  17489
   Germany

   Email: norbert.voigt@siemens.com

   Roberta Maglione
   Telecom Italia
   via Reiss Romoli 274
   Torino
   Italy

   Phone: norbert.voigt@nsn.com

   Tom Taylor (editor)
   Huawei Technologies
   Ottawa
   Canada

   Email: roberta.maglione@telecomitalia.it tom111.taylor@bell.net