[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 RFC 6320

Network Working Group                                         S.  Wadhwa
Internet-Draft                                            Alcatel-Lucent
Intended status: Standards Track                              J. Moisand
Expires: October 28, 2011                               Juniper Networks
                                                                T.  Haag
                                                        Deutsche Telekom
                                                                N. Voigt
                                                  Nokia Siemens Networks
                                                          T. Taylor, Ed.
                                                     Huawei Technologies
                                                          April 26, 2011


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

Abstract

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

   ANCP is based on GSMPv3 (RFC 3292), but with many modifications and
   extensions, to the point that the two protocols are not
   interoperable.  For this reason, ANCP was assigned a separate version
   number to distinguish it.

Status of this Memo

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

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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference



 Wadhwa, et al.         Expires October 28, 2011                [Page 1]

Internet-Draft                ANCP Protocol                   April 2011


   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 28, 2011.

Copyright Notice

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

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

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





















 Wadhwa, et al.         Expires October 28, 2011                [Page 2]

Internet-Draft                ANCP Protocol                   April 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  6
     1.1.  Historical Note  . . . . . . . . . . . . . . . . . . . . .  7
     1.2.  Requirements Language  . . . . . . . . . . . . . . . . . .  7
     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  7
   2.  Broadband Access Aggregation . . . . . . . . . . . . . . . . .  9
     2.1.  ATM-based Broadband Aggregation  . . . . . . . . . . . . .  9
     2.2.  Ethernet-Based Broadband Aggregation . . . . . . . . . . . 10
   3.  Access Node Control Protocol -- General Aspects  . . . . . . . 11
     3.1.  Protocol Version . . . . . . . . . . . . . . . . . . . . . 11
     3.2.  ANCP Transport . . . . . . . . . . . . . . . . . . . . . . 11
     3.3.  Encoding of Text Fields  . . . . . . . . . . . . . . . . . 12
     3.4.  Treatment of Reserved and Unused Fields  . . . . . . . . . 12
     3.5.  The ANCP Adjacency Protocol  . . . . . . . . . . . . . . . 13
       3.5.1.  ANCP Adjacency Message Format  . . . . . . . . . . . . 13
       3.5.2.  ANCP Adjacency Procedures  . . . . . . . . . . . . . . 19
     3.6.  ANCP General Message Formats . . . . . . . . . . . . . . . 29
       3.6.1.  The ANCP Message Header  . . . . . . . . . . . . . . . 30
       3.6.2.  The ANCP Message Body  . . . . . . . . . . . . . . . . 36
     3.7.  General Principles for the Design of ANCP Messages . . . . 37
   4.  Generally Useful ANCP Messages and TLVs  . . . . . . . . . . . 38
     4.1.  Provisioning Message . . . . . . . . . . . . . . . . . . . 38
     4.2.  Generic Response Message . . . . . . . . . . . . . . . . . 39
     4.3.  Target TLV . . . . . . . . . . . . . . . . . . . . . . . . 41
     4.4.  Command TLV  . . . . . . . . . . . . . . . . . . . . . . . 42
     4.5.  Status-Info TLV  . . . . . . . . . . . . . . . . . . . . . 42
   5.  Introduction To ANCP Capabilities For Digital Subscriber
       Lines (DSL)  . . . . . . . . . . . . . . . . . . . . . . . . . 44
     5.1.  DSL Access Line Identification . . . . . . . . . . . . . . 44
       5.1.1.  Control Context (Informative)  . . . . . . . . . . . . 44
       5.1.2.  TLVs For DSL Access Line Identification  . . . . . . . 46
   6.  ANCP Based DSL Topology Discovery  . . . . . . . . . . . . . . 49
     6.1.  Control Context (Informative)  . . . . . . . . . . . . . . 49
     6.2.  Protocol Requirements  . . . . . . . . . . . . . . . . . . 50
       6.2.1.  Protocol Requirements On the AN Side . . . . . . . . . 51
       6.2.2.  Protocol Requirements On the NAS Side  . . . . . . . . 51
     6.3.  ANCP Port UP and Port DOWN Event Message Descriptions  . . 51
     6.4.  Procedures . . . . . . . . . . . . . . . . . . . . . . . . 53
       6.4.1.  Procedures On the AN Side  . . . . . . . . . . . . . . 53
       6.4.2.  Procedures On the NAS Side . . . . . . . . . . . . . . 53
     6.5.  TLVs For DSL Line Attributes . . . . . . . . . . . . . . . 54
       6.5.1.  DSL-Line-Attributes TLV  . . . . . . . . . . . . . . . 54
       6.5.2.  DSL-Type TLV . . . . . . . . . . . . . . . . . . . . . 54
       6.5.3.  Actual-Net-Data-Rate-Upstream TLV  . . . . . . . . . . 55
       6.5.4.  Actual-Net-Data-Rate-Downstream TLV  . . . . . . . . . 55
       6.5.5.  Minimum-Net-Data-Rate-Upstream TLV . . . . . . . . . . 55
       6.5.6.  Minimum-Net-Data-Rate-Downstream TLV . . . . . . . . . 56



 Wadhwa, et al.         Expires October 28, 2011                [Page 3]

Internet-Draft                ANCP Protocol                   April 2011


       6.5.7.  Attainable-Net-Data-Rate-Upstream TLV  . . . . . . . . 56
       6.5.8.  Attainable-Net-Data-Rate-Downstream TLV  . . . . . . . 56
       6.5.9.  Maximum-Net-Data-Rate-Upstream TLV . . . . . . . . . . 56
       6.5.10. Maximum-Net-Data-Rate-Downstream TLV . . . . . . . . . 56
       6.5.11. Minimum-Net-Low-Power-Data-Rate-Upstream TLV . . . . . 57
       6.5.12. Minimum-Net-Low-Power-Data-Rate-Downstream TLV . . . . 57
       6.5.13. Maximum-Interleaving-Delay-Upstream TLV  . . . . . . . 57
       6.5.14. Actual-Interleaving-Delay-Upstream TLV . . . . . . . . 57
       6.5.15. Maximum-Interleaving-Delay-Downstream TLV  . . . . . . 58
       6.5.16. Actual-Interleaving-Delay-Downstream . . . . . . . . . 58
       6.5.17. DSL-Line-State TLV . . . . . . . . . . . . . . . . . . 58
       6.5.18. Access-Loop-Encapsulation TLV  . . . . . . . . . . . . 58
   7.  ANCP based DSL Line Configuration  . . . . . . . . . . . . . . 60
     7.1.  Control Context (Informative)  . . . . . . . . . . . . . . 60
     7.2.  Protocol Requirements  . . . . . . . . . . . . . . . . . . 61
       7.2.1.  Protocol Requirements On the NAS Side  . . . . . . . . 61
       7.2.2.  Protocol Requirements On the AN Side . . . . . . . . . 61
     7.3.  ANCP Port Management (Line Configuration) Message
           Format . . . . . . . . . . . . . . . . . . . . . . . . . . 62
     7.4.  Procedures . . . . . . . . . . . . . . . . . . . . . . . . 64
       7.4.1.  Procedures On the NAS Side . . . . . . . . . . . . . . 64
       7.4.2.  Procedures On the AN Side  . . . . . . . . . . . . . . 64
     7.5.  TLVs For DSL Line Configuration  . . . . . . . . . . . . . 65
       7.5.1.  Service-Profile-Name TLV . . . . . . . . . . . . . . . 65
   8.  ANCP-Based DSL Remote Line Connectivity Testing  . . . . . . . 65
     8.1.  Control Context (Informative)  . . . . . . . . . . . . . . 65
     8.2.  Protocol Requirements  . . . . . . . . . . . . . . . . . . 66
       8.2.1.  Protocol Requirements On the NAS Side  . . . . . . . . 66
       8.2.2.  Protocol Requirements On the AN Side . . . . . . . . . 66
     8.3.  Port Management (OAM) Message Format . . . . . . . . . . . 67
     8.4.  Procedures . . . . . . . . . . . . . . . . . . . . . . . . 68
       8.4.1.  NAS-Side Procedures  . . . . . . . . . . . . . . . . . 68
       8.4.2.  AN-Side Procedures . . . . . . . . . . . . . . . . . . 69
     8.5.  TLVs For the DSL Line Remote Connectivity Testing
           Capability . . . . . . . . . . . . . . . . . . . . . . . . 70
       8.5.1.  OAM-Loopback-Test-Parameters TLV . . . . . . . . . . . 70
       8.5.2.  Opaque-Data TLV  . . . . . . . . . . . . . . . . . . . 71
       8.5.3.  OAM-Loopback-Test-Response-String TLV  . . . . . . . . 71
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 71
     9.1.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . 72
     9.2.  IANA Actions . . . . . . . . . . . . . . . . . . . . . . . 72
       9.2.1.  ANCP Message Type Registry . . . . . . . . . . . . . . 72
       9.2.2.  ANCP Result Code Registry  . . . . . . . . . . . . . . 73
       9.2.3.  ANCP Port Management Function Registry . . . . . . . . 74
       9.2.4.  ANCP Technology Type Registry  . . . . . . . . . . . . 75
       9.2.5.  ANCP Command Code Registry . . . . . . . . . . . . . . 75
       9.2.6.  ANCP TLV Type Registry . . . . . . . . . . . . . . . . 75
       9.2.7.  ANCP Capability Type Registry  . . . . . . . . . . . . 77



 Wadhwa, et al.         Expires October 28, 2011                [Page 4]

Internet-Draft                ANCP Protocol                   April 2011


       9.2.8.  Joint GSMP / ANCP Version Registry . . . . . . . . . . 77
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 78
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 79
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 79
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 79
     12.2. Informative References . . . . . . . . . . . . . . . . . . 80
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 81












































 Wadhwa, et al.         Expires October 28, 2011                [Page 5]

Internet-Draft                ANCP Protocol                   April 2011


1.  Introduction

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

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

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

   Figure 1:  Architectural Context For the Access Node Control Protocol

   At various points in this document, information flows between the
   control applications and ANCP are described.  The purpose of such
   descriptions is to clarify the boundary between this specification
   and, for example, [TR-147].  There is no intention to place limits on
   the degree to which the control application and the protocol
   implementation are integrated.

   This specification specifies ANCP transport over TCP/IP.  TCP
   encapsulation for ANCP is as defined in Section 3.2.

   The organization of this document is as follows:

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

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




 Wadhwa, et al.         Expires October 28, 2011                [Page 6]

Internet-Draft                ANCP Protocol                   April 2011


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

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

   o  Section 5 and the three following sections describe and specify
      the ANCP implementation of three capabilities applicable to the
      control of DSL access technology: topology discovery, line
      configuration, and remote line connectivity testing.

   o  Section 9 is the IANA Considerations section.  This section
      defines a number of new ANCP-specific registries, as well as the
      joint GSMP/ANCP version registry mentioned below.

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

1.1.  Historical Note

   Initial implementations of the protocol that became ANCP were based
   on GSMPv3 [RFC3292].  The ANCP charter required the Working Group to
   develop its protocol based on these implementations.  In the end,
   ANCP introduced so many extensions and modifications to GSMPv3 that
   the two protocols are not interoperable.  Nevertheless, although this
   specification has no normative dependencies on [RFC3292], the mark of
   ANCP's origins can be seen in the various unused fields within the
   ANCP message header.

   Early in ANCP's development the decision was made to use the same TCP
   port and encapsulation as GSMPv3, and by the time ANCP was finished
   it was too late to reverse that decision because of existing
   implementations.  As a result, it is necessary to have a way for an
   ANCP peer to quickly distinguish ANCP from GSMP during initial
   adjacency negotiations.  This has been provided by a joint registry
   of GSMP and ANCP version numbers.  GSMP has version numbers 1 through
   3.  ANCP has the initial version number 50.

1.2.  Requirements Language

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

1.3.  Terminology

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



 Wadhwa, et al.         Expires October 28, 2011                [Page 7]

Internet-Draft                ANCP Protocol                   April 2011


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

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

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

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

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

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

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

   Net data rate:  [RFC5851] defined by ITU-T G.993.2 [G.993.2], Section
      3.39, i.e., the portion of the total data rate that can be used to
      transmit user information (e.g., ATM cells or Ethernet frames).
      It excludes overhead that pertains to the physical transmission
      mechanism (e.g., trellis coding in the case of DSL).  It includes



 Wadhwa, et al.         Expires October 28, 2011                [Page 8]

Internet-Draft                ANCP Protocol                   April 2011


      TPS-TC (Transport Protocol Specific - Transmission Convergence)
      encapsulation; this is zero for ATM encapsulation, and non-zero
      for 64/65 encapsulation.

   Line rate:  [RFC5851] defined by ITU-T G.993.2.  It contains the
      complete overhead including Reed-Solomon and trellis coding.

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


2.   Broadband Access Aggregation

2.1.  ATM-based Broadband Aggregation

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

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

   The Access Node terminates the DSL signal.  It may be in the form of
   a DSLAM in the central office, or a remote DSLAM, or a Remote Access
   Multiplexer (RAM).  The Access Node is the first point in the network
   where traffic on multiple DSL lines will be aggregated onto a single
   network.

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

   Beyond aggregation, the NAS is also the enforcement point for policy
   management and IP QoS in the regional/access networks.  To allow IP
   QoS support over an existing non-IP-aware layer 2 access network



 Wadhwa, et al.         Expires October 28, 2011                [Page 9]

Internet-Draft                ANCP Protocol                   April 2011


   without using multiple layer 2 QoS classes, a mechanism based on
   hierarchical scheduling is used.  This mechanism, defined in
   [TR-059], preserves IP QoS over the ATM network between the NAS and
   the routing gateway (RG) at the edge of the subscriber network, by
   carefully controlling downstream traffic in the NAS, so that
   significant queuing and congestion does not occur further down the
   ATM network.  This is achieved by using a diffserv-aware hierarchical
   scheduler in the NAS that will account for downstream trunk
   bandwidths and DSL synchronization rates.

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

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

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

               Figure 2: ATM Broadband Aggregation Topology

2.2.  Ethernet-Based Broadband Aggregation

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

   Stacked VLAN tags provide one possible way to create equivalent of
   "virtual paths" and "virtual circuits" in the aggregation network.
   The "outer" vlan can be used to create a form of "virtual path"



 Wadhwa, et al.         Expires October 28, 2011               [Page 10]

Internet-Draft                ANCP Protocol                   April 2011


   between a given DSLAM and a given NAS.  "Inner" VLAN tags create a
   form of "virtual circuit" on a per DSL line basis.  This is the 1:1
   VLAN allocation model.  An alternative model is to bridge sessions
   from multiple subscribers behind a DSLAM into a single VLAN in the
   aggregation network.  This is the N:1 VLAN allocation model.  Section
   1.6 of [TR-101] provides brief definitions of these two models, while
   section 2.5.1 describes them in more detail.


3.  Access Node Control Protocol -- General Aspects

   This section specifies aspects of the Access Node Control Protocol
   (ANCP) that are generally applicable.

3.1.  Protocol Version

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

3.2.  ANCP Transport

   This document specifies the use of TCP / IPSec+IKEv2 / IP for
   transport of ANCP messages.  For further discussion of the use of
   IPSec + IKEv2 see Section 10.  The present section deals with the TCP
   aspects.  Other specifications may introduce additional transports in
   the future.

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

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

   When transported over TCP, ANCP messages MUST use an encapsulation
   consisting of a four-byte header field prepended to the ANCP message
   as shown in Figure 3.











 Wadhwa, et al.         Expires October 28, 2011               [Page 11]

Internet-Draft                ANCP Protocol                   April 2011


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

           Figure 3: Encapsulation of ANCP Messages Over TCP/IP

   The fields of the encapsulating header are as follows:

   Identifier (16 bits):  This identifies a GSMP or ANCP message.  It
      MUST be set to 0x880C.

   Length (16 bits):  Total length of the ANCP message in bytes, not
      including the 4-byte encapsulating header.

   The Access Node MUST initiate the TCP session to the NAS, using
   destination port 6068.

      This is necessary to avoid static address provisioning on the NAS
      for all the ANs that are being served by the NAS.  It is easier to
      configure a given AN with the single IP address of the NAS that
      serves the AN.

   The NAS MUST listen on port 6068 for incoming connections from the
   Access Nodes.

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

3.3.  Encoding of Text Fields

   In ANCP, all text fields use UTF-8 encoding [RFC3629].  Note that US
   ASCII characters have the same representation when coded as UTF-8 as
   they do when coded according to [US_ASCII].

   When extracting text fields from a message, the ANCP agent MUST NOT
   assume that the fields are zero-terminated.

3.4.  Treatment of Reserved and Unused Fields

   ANCP messages contain a number of fields that are unused or reserved.
   Some fields are always unused (typically because they were inherited



 Wadhwa, et al.         Expires October 28, 2011               [Page 12]

Internet-Draft                ANCP Protocol                   April 2011


   from GSMPv3 but are not useful in the ANCP context).  Others are
   reserved in the current specification, but are provided for
   flexibility in future extensions to ANCP.  Both reserved and unused
   fields MUST be set to zeroes by the sender and MUST be ignored by the
   receiver.

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

3.5.  The ANCP Adjacency Protocol

   ANCP uses the adjacency protocol to synchronize the NAS and Access
   Nodes and maintain the ANCP session.  After the TCP connection is
   established, adjacency protocol messages MUST be exchanged as
   specified in this section.  ANCP messages other than adjacency
   protocol messages MUST NOT be sent until the adjacency protocol has
   achieved synchronization.

3.5.1.  ANCP Adjacency Message Format

   The ANCP adjacency message format is shown in Figure 4 below.





























 Wadhwa, et al.         Expires October 28, 2011               [Page 13]

Internet-Draft                ANCP Protocol                   April 2011


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

                  Figure 4: ANCP Adjacency Message Format

   The fields of the ANCP adjacency message are as follows:

   Version (8 bits):  ANCP version, which is subject to negotiation.
      This is the key parameter by means of which ANCP messages can be
      distinguished from GSMP messages received over the same port.

   Message Type (8 bits):  always has value 10 (adjacency protocol).

   Timer (8 bits):  The Timer field is used to negotiate the timer value
      used in the adjacency protocol with the peer.  The timer specifies
      the nominal time between periodic adjacency protocol messages.  It
      is a constant for the duration of an ANCP session.  The Timer
      field is specified in units of 100ms, with a default value of 250
      (i.e., 25 seconds).

   M-flag (one bit):  used in the SYN message to prevent the NAS from
      synchronizing with another NAS, and the AN from synchronizing with
      another AN.  In the SYN message, always set to 1 by the NAS, and
      to 0 by the AN.  In other adjacency message types, always set to 0
      by the sender and ignored by the receiver.



 Wadhwa, et al.         Expires October 28, 2011               [Page 14]

Internet-Draft                ANCP Protocol                   April 2011


   Code (7 bits):  the adjacency protocol message type.  It MUST have
      one of the following values:

         Code = 1: SYN;

         Code = 2: SYNACK;

         Code = 3: ACK;

         Code = 4: RSTACK.

   Sender Name (48 bits):  For the SYN, SYNACK, and ACK messages, is the
      identifier of the entity sending the message.  The Sender Name is
      a 48-bit quantity that is unique within the operational context of
      the device.  A 48-bit IEEE 802 MAC address, if available, may be
      used for the Sender Name.  If the Ethernet encapsulation is used
      the Sender Name MUST be the Source Address from the MAC header.
      For the RSTACK message, the Sender Name field is set to the value
      of the Receiver Name field from the incoming message that caused
      the RSTACK message to be generated.

   Receiver Name (48 bits)  for the SYN, SYNACK, and ACK messages, is
      the name of the entity that the sender of the message believes is
      at the far end of the link.  If the sender of the message does not
      know the name of the entity at the far end of the link, this field
      SHOULD be set to zero.  For the RSTACK message, the Receiver Name
      field is set to the value of the Sender Name field from the
      incoming message that caused the RSTACK message to be generated.

   Sender Port (32 bits):  For the SYN, SYNACK, and ACK messages, is the
      local port number of the link across which the message is being
      sent.  For the RSTACK message, the Sender Port field is set to the
      value of the Receiver Port field from the incoming message that
      caused the RSTACK message to be generated.

   Receiver Port (32 bits):  For the SYN, SYNACK, and ACK messages, is
      what the sender believes is the local port number for the link,
      allocated by the entity at the far end of the link.  If the sender
      of the message does not know the port number at the far end of the
      link, this field SHOULD be set to zero.  For the RSTACK message,
      the Receiver Port field is set to the value of the Sender Port
      field from the incoming message that caused the RSTACK message to
      be generated.

   PType (4 bits):  PType is used to specify if partitions are used and
      how the Partition ID is negotiated.





 Wadhwa, et al.         Expires October 28, 2011               [Page 15]

Internet-Draft                ANCP Protocol                   April 2011


         Type of partition being requested:

         0 - no partition;

         1 - fixed partition request;

         2 - fixed partition assigned.

   PFlag (4 bits):  used to indicate the type of partition request.

         1 - new adjacency;

         2 - recovered adjacency.

      In case of a conflict between the peers' views of the value of
      PFlag, the lower value is used.

   Sender Instance (24 bits):  For the SYN, SYNACK, and ACK messages, is
      the sender's instance number for the link to the peer.  It is used
      to detect when the link comes back up after going down or when the
      identity of the entity at the other end of the link changes.  The
      instance number is a 24-bit number that is guaranteed to be unique
      within the recent past and to change when the link or node comes
      back up after going down.  Zero is not a valid instance number.
      For the RSTACK message, the Sender Instance field is set to the
      value of the Receiver Instance field from the incoming message
      that caused the RSTACK message to be generated.

   Partition ID (8 bits):  field used to associate the message with a
      specific partition of the AN.  The value of this field is
      negotiated during the adjacency procedure.  The AN makes the final
      decision, but will consider a request from the NAS.  If the AN
      does not support partitions, the value of this field MUST be 0.
      Otherwise, it MUST be non-zero.

   Receiver Instance (24 bits):  For the SYN, SYNACK, and ACK messages,
      is what the sender believes is the current instance number for the
      link, allocated by the entity at the far end of the link.  If the
      sender of the message does not know the current instance number at
      the far end of the link, this field SHOULD be set to zero.  For
      the RSTACK message, the Receiver Instance field is set to the
      value of the Sender Instance field from the incoming message that
      caused the RSTACK message to be generated.

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





 Wadhwa, et al.         Expires October 28, 2011               [Page 16]

Internet-Draft                ANCP Protocol                   April 2011


   # of Caps:  indicates the number of capability fields that follow.

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

   Capability Fields:  Each capability field indicates one ANCP
      capability supported by the sender of the adjacency message.
      Negotiation of a common set of capabilities to be supported within
      the ANCP session is described below.  The detailed format of a
      capability field is shown in Figure 5 and described below.


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Capability Type           |   Capability Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                                                               ~
      ~                   Capability Data                             ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 5: Capability Field

   The sub-fields of this structure are as follows:

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

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

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

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





 Wadhwa, et al.         Expires October 28, 2011               [Page 17]

Internet-Draft                ANCP Protocol                   April 2011


   o  Capability Type : DSL Topology Discovery = 0x01

         Access technology: DSL

         Length (in bytes) : 0

         Capability Data : NULL

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

   o  Capability Type : DSL Line Configuration = 0x02

         Access technology: DSL

         Length (in bytes) : 0

         Capability Data : NULL

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

   o  Capability Type : DSL Remote Line Connectivity Testing = 0x04

         Access technology: DSL

         Length (in bytes) : 0

         Capability Data : NULL

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

   In addition to the adjacency messages whose format is shown in
   Figure 6, ANCP adjacency procedures use the Adjacency Update message
   (Figure 6) to inform other NASs controlling the same AN partition
   when a particular NAS joins or loses an adjacency with that
   partition.













 Wadhwa, et al.         Expires October 28, 2011               [Page 18]

Internet-Draft                ANCP Protocol                   April 2011


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

                  Figure 6: The Adjacency Update Message

   The Adjacency Update message is identical to the general ANCP message
   header described in Section 3.6, but the field settings are in part
   specific to the Adjacency Update message.  The fields in this message
   are as follows:

   Version (8 bits):  the ANCP version negotiated and running in this
      adjacency.

   Message Type (8 bits):  always 85.

   Result (4 bits):  set to Ignore (0).

   Code (12 bits):  set to the total number of adjacencies currently
      established on this partition, from the point of view of the AN.

   Partition ID (8 bits):  the partition identifier of the partition for
      which this notification is being sent.

   Transaction Identifier (24 bits):  MUST be set to 0.

   I (1 bit), SubMessage number (15 bits):  set as described in
      Section 3.6.1.7.

   Length (16 bits):  set as described in Section 3.6.1.8.

3.5.2.  ANCP Adjacency Procedures

3.5.2.1.  Overview

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



 Wadhwa, et al.         Expires October 28, 2011               [Page 19]

Internet-Draft                ANCP Protocol                   April 2011


   Partition ID parameters and the set of capabilities that the
   adjacency will support.

   Once the adjacency has been established, its liveness is periodically
   tested.  The peers engage in an ACK message exchange at a frequency
   determined by the negotiated value of the Timer field.

   If an inconsistency, loss of contact, or protocol violation is
   detected, the detecting peer can force a restart of the
   synchronization process by sending an RSTACK message to the other
   end.

   Once an adjacency has been established, if more than one NAS has
   established an adjacency to the same partition, then the AN sends an
   Adjacency Update message to each such NAS to let it know how many
   established adjacencies the partition currently supports.  Similarly,
   if an adjacency is lost, the AN sends an Adjacency Update message to
   each of the remaining adjacent NASs to let them know about the change
   in status.

3.5.2.2.  Adjacency Protocol State Machine

   The adjacency protocol is described by the following rules and state
   tables.  It begins with the sending of a SYN by each end as soon as
   the transport connection has been established.  If at any point the
   operations A, B, C, or "Verify Adjacent State" defined below detect a
   mismatch, a log SHOULD be generated, identifying the fields concerned
   and the expected and received values for each.

   The rules and state tables use the following operations:

   o  The "Record Adjacency State" operation is defined in
      Section 3.5.2.3.2.

   o  The "Verify Adjacency State" operation consists of verifying that
      the contents of the incoming SYNACK message match the adjacency
      state values previously recorded.

   o  The procedure "Reset the link" is defined as:

      1.  Generate a new instance number for the link.

      2.  Delete the peer verifier (set to zero the values of Sender
          Instance, Sender Port, and Sender Name previously stored by
          the Record Adjacency State operation).

      3.  Send a SYN message(Section 3.5.2.3.1).




 Wadhwa, et al.         Expires October 28, 2011               [Page 20]

Internet-Draft                ANCP Protocol                   April 2011


      4.  Enter the SYNSENT state.

   o  The state tables use the following Boolean terms and operators.

      A.  The Sender Instance in the incoming message matches the value
          stored from a previous message by the "Record Adjacency State"
          operation.

      B.  The Sender Instance, Sender Port, Sender Name and Partition ID
          fields in the incoming message match the values stored from a
          previous message by the "Record Adjacency State" operation.

      C.  The Receiver Instance, Receiver Port, Receiver Name and
          Partition ID fields in the incoming message match the values
          of the Sender Instance, Sender Port, Sender Name and Partition
          ID currently sent in outgoing SYN, SYNACK, and ACK messages,
          except that the NAS always accepts the Partition ID value
          presented to it in a SYN or SYNACK message.

         "&&" Represents the logical AND operation.

         "||" Represents the logical OR operation.

         "!"  Represents the logical negation (NOT) operation.

   o  A timer is required for the periodic generation of SYN, SYNACK,
      and ACK messages.  The value of the timer is negotiated in the
      Timer field.  The period of the timer is unspecified but a value
      of 25 seconds is suggested.  Note that since ANCP uses a reliable
      transport protocol, the timer is unlikely to expire in any state
      other than ESTAB.

      There are two independent events: the timer expires, and a packet
      arrives.  The processing rules for these events are:

         Timer Expires: Reset Timer

            If state = SYNSENT Send SYN

            If state = SYNRCVD Send SYNACK

            If state = ESTAB Send ACK

         Packet Arrives:

            If incoming message is an RSTACK:





 Wadhwa, et al.         Expires October 28, 2011               [Page 21]

Internet-Draft                ANCP Protocol                   April 2011


               If (A && C && !SYNSENT) Reset the link

               Else discard the message.

            If incoming message is a SYN, SYNACK, or ACK:

               Response defined by the following State Tables.

            If incoming message is any other ANCP message and state !=
            ESTAB:

               Discard incoming message.

               If state = SYNSENT Send SYN (Note 1)

               If state = SYNRCVD Send SYNACK (Note 1)

         Note 1: No more than two SYN or SYNACK messages should be sent
         within any time period of length defined by the timer.

   o  State synchronisation across a link is considered to be achieved
      when the protocol reaches the ESTAB state.  All ANCP messages,
      other than adjacency protocol messages, that are received before
      synchronisation is achieved will be discarded.

3.5.2.2.1.  State Tables


   State: SYNSENT

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










 Wadhwa, et al.         Expires October 28, 2011               [Page 22]

Internet-Draft                ANCP Protocol                   April 2011


   State: SYNRCVD

  +====================================================================+
  |    Condition     |                Action               | New State |
  +==================+=====================================+===========+
  |   SYNACK && C    |  Verify Adjacency State; Send ACK   |   ESTAB   |
  +------------------+-------------------------------------+-----------+
  |   SYNACK && !C   |            Send RSTACK              |  SYNRCVD  |
  +------------------+-------------------------------------+-----------+
  |       SYN        | Record Adjacency State; Send SYNACK |  SYNRCVD  |
  +------------------+-------------------------------------+-----------+
  |  ACK && B && C   |              Send ACK               |   ESTAB   |
  +------------------+-------------------------------------+-----------+
  | ACK && !(B && C) |            Send RSTACK              |  SYNRCVD  |
  +====================================================================+




   State: ESTAB

  +====================================================================+
  |    Condition     |                Action               | New State |
  +==================+=====================================+===========+
  |  SYN || SYNACK   |           Send ACK (note 2)         |   ESTAB   |
  +------------------+-------------------------------------+-----------+
  |  ACK && B && C   |           Send ACK (note 3)         |   ESTAB   |
  +------------------+-------------------------------------+-----------+
  | ACK && !(B && C) |              Send RSTACK            |   ESTAB   |
  +====================================================================+


   Note 2: No more than two ACKs should be sent within any time period
   of length defined by the timer.  Thus, one ACK MUST be sent every
   time the timer expires.  In addition, one further ACK may be sent
   between timer expirations if the incoming message is a SYN or SYNACK.
   This additional ACK allows the adjacency protocol to reach
   synchronisation more quickly.

   Note 3: No more than one ACK should be sent within any time period of
   length defined by the timer.

3.5.2.3.  The Adjacency Protocol SYN Message

3.5.2.3.1.  Action By the Sender

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



 Wadhwa, et al.         Expires October 28, 2011               [Page 23]

Internet-Draft                ANCP Protocol                   April 2011


   Version:  SHOULD be set to the highest version of ANCP that the
      sender supports.

   Message Type:  MUST be set to 10.

   Timer:  SHOULD be set to the value configured in the AN or NAS
      sending the message.

   M Flag  MUST be set to 1 by the NAS, and 0 by the AN.

   Code:  MUST be set to 1 (SYN).

   Sender Name  set as described in Section 3.5.1.

   Receiver Name:  SHOULD be set to 0.

   Sender Port  set as described in Section 3.5.1.

   Receiver Port:  SHOULD be set to 0.

   PType:  set according to the following rules:

         Settings by the AN:

            0 - the AN does not support partitions;

            2 - the value of Partition ID contained in this message is
            assigned to the current partition.

         Settings by the NAS:

            0 - the NAS leaves the decision on partitioning to the AN
            (RECOMMENDED setting);

            1 - the NAS requests that the AN use the value of Partition
            ID contained in this message for the current partition.  The
            NAS MAY use this setting even if it has already received a
            SYN message from the AN, provided that the AN has indicated
            support for partitions.  The NAS MUST be prepared to use
            whatever value it receives in a subsequent SYN or SYNACK
            message, even if this differs from the requested value.

   PFlag:  set to the mode of adjacency setup (new adjacency vs.
      recovered adjacency) requested by the sender.  Warning: setting
      PFlag=1 runs the risk of state mismatch because ANCP does not
      provide the means for the NAS to audit the current state of the
      AN.




 Wadhwa, et al.         Expires October 28, 2011               [Page 24]

Internet-Draft                ANCP Protocol                   April 2011


   Sender Instance:  set as described in Section 3.5.1.

   Partition ID:  MUST be set to 0 if PType=0, otherwise set to the
      assigned or requested partition identifier value.

   Receiver Instance:  SHOULD be set to 0.

   # of Caps:  MUST be set to the number of Capability fields that
      follow.

   Total Length:  MUST be set to the total number of bytes in the
      Capability fields that follow.

   Capability Fields:  one Capability field MUST be present for each
      ANCP capability for which the sender wishes to advertise support.

3.5.2.3.2.  Action By the Receiver

   Upon receiving a validly-formed SYN message, the receiver first
   checks the value of the Version field.  If this value is not within
   the range of ANCP versions that the receiver supports, the message
   MUST be silently ignored.  Similarly, the message is silently ignored
   if the M-flag is 0 and the receiver is an AN, or if the M-flag is 1
   and the receiver is a NAS.  If these checks are passed and the
   receiver is in ESTAB state, it returns an ACK (as indicated by the
   ESTAB state table in Section 3.5.2.2.1).  The contents of the ACK
   MUST reflect the adjacency state as previously recorded by the
   receiver.

   Otherwise, the receiver MUST record the adjacency state as follows:

   Version:  the supported Version value received in the SYN message.
      This value MUST be used for all subsequent ANCP messages sent
      during the life of the adjacency.

   Timer:  the larger of the Timer value received in the SYN message and
      the value with which the receiver is configured.

   Sender Name:  the value of the Sender Name field in the SYN message
      just received.

   Receiver Name:  the value used by the receiver in the Sender Name
      field of SYN, SYNACK, and ACK messages it sends in this adjacency.

   Sender Port:  the value of the Sender Port field in the SYN message
      just received.





 Wadhwa, et al.         Expires October 28, 2011               [Page 25]

Internet-Draft                ANCP Protocol                   April 2011


   Receiver Port:  the value used by the receiver in the Sender Port
      field of SYN, SYNACK, and ACK messages it sends in this adjacency.

   Sender Instance:  the value of the Sender Instance field in the SYN
      message just received.

   PFlag:  the lesser of the value determined by local policy and the
      value received in the SYN message.  That is, preference is given
      to "0 - New adjacency" if there is a conflict.

   Partition ID:  if the SYN receiver is the AN, this is set to 0 if the
      AN does not support partitions, or to the non-zero value of the
      partition identifier it chooses to assign otherwise.  If the SYN
      receiver is the NAS, this is set to the value of the Partition ID
      field copied from the SYN.

   Receiver Instance:  the value used by the receiver in the Sender
      Instance field of SYN, SYNACK, and ACK messages it sends in this
      adjacency.

   Capabilities:  the set of ANCP capabilities that were offered in the
      SYN and are supported by the receiver.

3.5.2.4.  The Adjacency Protocol SYNACK Message

3.5.2.4.1.  Action By the Sender

   The SYNACK is sent in response to a successfully received SYN
   message, as indicated by the state tables.  The Version, Timer,
   PFlag, and Partition ID fields MUST be populated with the values
   recorded as part of adjacency state.  The # of Caps, Total Length,
   and Capability fields MUST also be populated in accordance with the
   Capabilities recorded as part of adjacency state.  The remaining
   fields of the SYNACK message MUST be populated as follows:

   Message Type:  MUST be 10.

   M-flag:  MUST be set to 0.

   Code:  MUST be 2 (SYNACK).

   PType:  MUST be 0 if the Partition ID value is 0, or 2 if the
      Partition ID value is non-zero.

   Sender Name:  MUST be set to the Receiver Name value recorded as part
      of adjacency state.





 Wadhwa, et al.         Expires October 28, 2011               [Page 26]

Internet-Draft                ANCP Protocol                   April 2011


   Receiver Name:  MUST be set to the Sender Name value recorded as part
      of adjacency state.

   Sender Port:  MUST be set to the Receiver Port value recorded as part
      of adjacency state.

   Receiver Port:  MUST be set to the Sender Port value recorded as part
      of adjacency state.

   Sender Instance:  MUST be set to the Receiver Instance value recorded
      as part of adjacency state.

   Receiver Instance:  MUST be set to the Sender Instance value recorded
      as part of adjacency state.

   If the set of capabilities recorded in the adjacency state is empty,
   then after sending the SYNACK the sender MUST raise an alarm to
   management, halt the adjacency procedure, and tear down the TCP
   session if it is not being used by another adjacency.  The sender MAY
   also terminate the IPSec security association if no other adjacency
   is using it.

3.5.2.4.2.  Action By the Receiver

   As indicated by the state tables, the receiver of a SYNACK first
   checks that the Receiver Name, Receiver Port, and Receiver Instance
   values match the Sender Name, Sender Port, and Sender Instance values
   it sent in SYN message that is being acknowledged.  The AN also
   checks that the PType and Partition ID match.  If any of these checks
   fail, the receiver sends an RSTACK as described in Section 3.5.2.6.1.

   The receiver next checks whether the set of capabilities provided in
   the SYNACK is empty.  If so, the receiver MUST raise an alarm to
   management and halt the adjacency procedure.

   Assuming that the SYNACK passes these checks, two cases arise.  The
   first possibility is that the receiver has already recorded adjacency
   state.  This will occur if the SYNACK is received while the receiver
   is in SYNRCVD state.  In this case, the Version, Timer, Sender Name,
   Sender Port, Sender Instance, PFlag, and capability-related fields in
   the SYNACK MUST match those recorded as part of adjacency state.  If
   a mismatch is detected, the receiver sends an RSTACK.  This is the
   "Verify Adjacency State" procedure shown in the SYNRCVD state table.

   If, on the other hand, the SYNACK is received while the receiver is
   in SYNSENT state, the receiver MUST record session state as described
   in Section 3.5.2.3.2.




 Wadhwa, et al.         Expires October 28, 2011               [Page 27]

Internet-Draft                ANCP Protocol                   April 2011


   In either case, if the receiver is the NAS, it MUST accept the
   Partition ID value provided in the SYNACK, updating its recorded
   adjacency state if necessary.

3.5.2.5.  The Adjacency Protocol ACK Message

3.5.2.5.1.  Actions By the Sender

   As indicated by the state tables, the ACK message is sent in a number
   of different circumstances.  The main-line usages are as a response
   to SYNACK, leading directly to the ESTAB state, and as a periodic
   test of liveness once the ESTAB state has been reached.

   The sender MUST populate the ACK from recorded adjacency state,
   exactly as described in Section 3.5.2.4.1.  The only difference is
   that Code MUST be set to 3 (ACK).

3.5.2.5.2.  Actions By the Receiver

   The required actions by the receiver are specified by the state
   tables.  In addition to the checks B and C, the receiver SHOULD
   verify that the remaining contents of the ACK match the recorded
   adjacency state at the receiver.  If that check fails the receiver
   MUST send an RSTACK as described in Section 3.5.2.6.1.

   Once the adjacency has been established, either peer can initiate the
   ACK exchange that tests for liveness.  To meet the restrictions on
   ACK frequency laid down in the notes to the state tables, it is
   desirable that only one such exchange occur during any one interval.
   Hence if a peer receives an ACK when in ESTAB state, it MUST reply to
   that ACK as directed by the state tables, but SHOULD NOT initiate
   another ACK exchange in the same interval.  To meet this objective,
   the receiver MUST reset its timer when it receives an ACK while in
   ESTAB state.

      It is, of course, possible that two exchanges happen because of
      race conditions.

3.5.2.6.  The Adjacency Protocol RSTACK Message

3.5.2.6.1.  Action By the Sender

   The RSTACK is sent in response to various error conditions as
   indicated by the state tables.  In general it leads to a restart of
   adjacency negotiations (although this takes a few steps when the
   original sender of the RSTACK is in ESTAB state).

   As indicated in Section 3.5.1, the Sender Name, Port, and Instance



 Wadhwa, et al.         Expires October 28, 2011               [Page 28]

Internet-Draft                ANCP Protocol                   April 2011


   fields in the RSTACK MUST be copied from the Receiver, Name, Port,
   and Instance fields in the message that caused the RSTACK to be sent.
   Similarly, the Receiver identifier fields in the RSTACK MUST be
   copied from the corresponding Sender identifier fields in the message
   that triggered the RSTACK.

   If the sender has recorded adjacency state, the Version, Timer,
   PType, PFlag, Partition ID, and capability-related fields SHOULD be
   set based on the recorded adjacency state.  Otherwise they SHOULD be
   the same as the sender would send in a SYN message.  The Message Type
   MUST be 10, the M-flag MUST be 0, and Code MUST be 4 (RSTACK).

3.5.2.6.2.  Action By the Receiver

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

3.5.2.7.  Loss of Synchronization

   Loss of synchronisation MAY be declared if after synchronisation is
   achieved:

   o  no valid ANCP messages are received in any period of time in
      excess of three times the value of the Timer field negotiated in
      the adjacency protocol messages, or

   o  a mismatch in adjacency state is detected.

   In either case the peer detecting the condition MUST send an RSTACK
   to the other peer as directed in Section 3.5.2.6.1, in order to
   initiate resynchronization.

   While re-establishing synchronisation with a controller, a switch
   SHOULD maintain its connection state, deferring the decision about
   resetting the state until after synchronisation is re-established.
   Once synchronisation is re-established the decision about resetting
   the connection state SHOULD be made based on the negotiated value of
   PFlag.

3.6.  ANCP General Message Formats

   This section describes the general format of ANCP messages other than
   the adjacency messages.  See Figure 7






 Wadhwa, et al.         Expires October 28, 2011               [Page 29]

Internet-Draft                ANCP Protocol                   April 2011


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

                   Figure 7: ANCP General Message Format

3.6.1.  The ANCP Message Header

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

3.6.1.1.  Version Field (8 bits)

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

3.6.1.2.  Message Type Field (8 bits)

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

3.6.1.3.  Result Field (4 bits)

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

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

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






 Wadhwa, et al.         Expires October 28, 2011               [Page 30]

Internet-Draft                ANCP Protocol                   April 2011


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

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

   Failure:  Res = 0x4 - Result value indicating that this is a response
      and that the request was not executed successfully.  The receiver
      of the response SHOULD take further action as indicated by the
      Result Code value and any diagnostic data contained in a Status-
      Info TLV included in the response.

3.6.1.4.  Result Code Field (12 bits)

   This field gives further information concerning the result in a
   response message.  It is mostly used to pass an error code in a
   failure response but can also be used to give further information in
   a success response message or an event message.  In a request
   message, the Result Code field is not used and MUST be set to 0x0 (No
   result).

   A number of Result Code values are specified below.  Specification of
   additional Result Code values in extensions or updates to this
   document MUST include the following information:

   o  Result Code value;

   o  One-line description;

   o  Where condition detected: (control application or ANCP agent);

   o  Further description (if any);

   o  Required additional information in the response message;

   o  Target (control application or ANCP agent at the peer that sent
      the original request);

   o  Action RECOMMENDED for the receiving ANCP agent

   In addition to any suggested action in the text which follows, a
   count of the number of times a given non-zero Result Code value was
   received SHOULD be provided for management.  Where an action includes
   resending of a request, a given request SHOULD NOT be re-sent more
   than once.




 Wadhwa, et al.         Expires October 28, 2011               [Page 31]

Internet-Draft                ANCP Protocol                   April 2011


   This document specifies the following Result Code values.

   Result Code value: 0x2

      *  One-line description: Invalid request message

      *  Where condition detected: ANCP agent

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

      *  Required additional information in the response message: none,
         if the response message is of the same type as the request.  As
         specified in Section 4.2 if the response message is a Generic
         Response message.

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

      *  Action RECOMMENDED for the receiving ANCP agent: The original
         request MAY be re-sent once only after a short delay.  Inform
         the control application with appropriate identification of the
         failed transaction if the second attempt fails or no second
         attempt is made.

   Result Code value: 0x6

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

      *  Where condition detected: control application

      *  Further description (if any): This Result Code value indicates
         a state mismatch between the NAS and AN control applications,
         possibly due to a race condition.

      *  Required additional information in the response message: if the
         request identified multiple access lines or the response is a
         Generic Response message, then the response MUST contain a
         Status-Info TLV encapsulating TLV(s) containing the line
         identifier(s) of the access lines that are not operational.

      *  Target: control application at the peer that sent the original
         request

      *  Action RECOMMENDED for the receiving ANCP agent: indicate the
         error and forward the line identifier(s) to the control



 Wadhwa, et al.         Expires October 28, 2011               [Page 32]

Internet-Draft                ANCP Protocol                   April 2011


         application.

   Result Code value: 0x13

      *  One-line description: Out of resources

      *  Where condition detected: ANCP protocol layer or control
         application

      *  Further description: (e.g., memory exhausted, etc.).  This
         Result Code value MUST be reported only by the AN, and
         indicates a condition that is probably unrelated to specific
         access lines (although it may be related to the specific
         request).

      *  Required additional information in the response message: none,
         if the response message is of the same type as the request.  As
         specified in Section 4.2 if the response message is a Generic
         Response message.

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

      *  Action RECOMMENDED for the receiving ANCP agent: If the NAS
         receives this Result Code value from multiple requests for the
         same AN in a short interval, it SHOULD reduce the rate at which
         it sends requests in proportion to the rate at which requests
         are failing with Result Code = 19.  It MAY retry individual
         requests.  If only a specific request is failing with Result
         Code = 19, the ANCP agent in the NAS MAY request the control
         application to decompose the request into simpler components if
         this is possible.

   Result Code value: 0x51

      *  One-line description: Request message type not implemented

      *  Where condition detected: ANCP agent

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

      *  Required additional information in the response message: none,
         if the response message is of the same type as the request.  As
         specified in Section 4.2 if the response message is a Generic
         Response message.





 Wadhwa, et al.         Expires October 28, 2011               [Page 33]

Internet-Draft                ANCP Protocol                   April 2011


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

      *  Action RECOMMENDED for the receiving ANCP agent: If the
         receiver of this Result Code value expects that support of the
         message type concerned is mandatory according to the
         capabilities negotiated for the session, it MAY re-send the
         message in case the message was corrupted in transit the first
         time.  If that fails, and use of the message type cannot be
         avoided, the ANCP agent MAY reset the adjacency by sending an
         RSTACK adjacency message (Section 3.5.2.6.1) where PType is set
         to 0 and Sender and Receiver Name, Port, and Instance are taken
         from recorded adjacency state.  If a reset does not eliminate
         the problem, the receiving ANCP agent SHOULD raise an alarm to
         management and then cease to operate.

   Result Code value: 0x53

      *  One-line description: Malformed message

      *  Where condition detected: ANCP agent

      *  Further description: This could be the result of corruption in
         transit, or an error in implementation at one end or the other.

      *  Required additional information in the response message: none,
         if the response message is of the same type as the request.  As
         specified in Section 4.2 if the response message is a Generic
         Response message.

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

      *  Action RECOMMENDED for the receiving ANCP agent: The request
         SHOULD be re-sent once to eliminate the possibility of in-
         transit corruption.

   Result Code value: 0x54

      *  One-line description: Mandatory TLV missing

      *  Where condition detected: ANCP agent

      *  Further description: none.

      *  Required additional information in the response message: the
         response message MUST contain a Status-Info message that
         encapsulates an instance of each missing mandatory TLV, where
         the length is set to zero and the value field is empty (i.e.,
         only the four-byte TLV header is present).



 Wadhwa, et al.         Expires October 28, 2011               [Page 34]

Internet-Draft                ANCP Protocol                   April 2011


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

      *  Action RECOMMENDED for the receiving ANCP agent: resend the
         message with the missing TLV(s), if possible.  Otherwise,
         report the error to the control application with an indication
         of the missing information required to construct the missing
         TLV(s).

   Result Code value: 0x55

      *  One-line description: Invalid TLV contents

      *  Where condition detected: ANCP agent

      *  Further description: the contents of one or more TLVs in the
         request do not match the specifications provided for the those
         TLVs.

      *  Required additional information in the response message: the
         response MUST contain a Status-Info TLV encapsulating the
         erroneous TLVs copied from the original request.

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

      *  Action RECOMMENDED for the receiving ANCP agent: correct the
         error and resend the request, if possible.  Otherwise, report
         the error to the control application with an indication of the
         erroneous information associated with the invalid TLV(s).

   Result Code value: 0x500

      *  One-line description: One or more of the specified ports do not
         exist

      *  Where condition detected: control application

      *  Further description (if any): this may indicate a configuration
         mismatch between the AN and the NAS or AAA.

      *  Required additional information in the response message: if the
         request identified multiple access lines or the response is a
         Generic Response message, then the response MUST contain a
         Status-Info TLV encapsulating TLV(s) containing the rejected
         line identifier(s).

      *  Target: control application at the peer that sent the original
         request




 Wadhwa, et al.         Expires October 28, 2011               [Page 35]

Internet-Draft                ANCP Protocol                   April 2011


      *  Action RECOMMENDED for the receiving ANCP agent: indicate the
         error and forward the line identifiers to the control
         application.

3.6.1.5.  Partition ID (8 bits)

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

3.6.1.6.  Transaction ID (24 bits)

   The Transaction ID is set by the sender of a request message to
   associate a response message with the original request message.
   Unless otherwise specified for a given message type, the Transaction
   ID in request messages MUST be set to a value in the range (1, 2^24 -
   1).  When used in this manner, the Transaction ID sequencing MUST be
   maintained independently for each message type within each ANCP
   adjacency.  Furthermore, it SHOULD be incremented by 1 for each new
   message of the given type, cycling back to 1 after running the full
   range.  For event messages, the Transaction ID SHOULD be set to zero.

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

3.6.1.7.  I flag and SubMessage Number (1 + 15 bits)

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

3.6.1.8.  Length (16 bits)

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

3.6.2.  The ANCP Message Body

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

   The general format of a TLV is shown in Figure 8:




 Wadhwa, et al.         Expires October 28, 2011               [Page 36]

Internet-Draft                ANCP Protocol                   April 2011


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

                       Figure 8: General TLV Format

   The fields of a TLV are defined as follows:

   Type (16 bits):  The TLV Type is an unsigned value identifying the
      TLV type and nature of its contents.  An IANA registry has been
      established for ANCP TLV Type codes.

   Length (16 bits):  The number of bytes of data in the Value field of
      the TLV, excluding any padding required to bring this TLV to a
      4-byte word boundary (see "Value" below).  If a TLV contains other
      TLVs, any padding in the contained TLVs MUST be included in the
      value of Length.  Depending on the specification of the TLV, the
      value of Length can be zero, a constant for all instances of the
      TLV, or a varying quantity.

   Value (variable):  The actual data carried by the TLV, if any.  The
      value field in each TLV MUST be padded with zeroes as required to
      align with a 4-byte word boundary.  The Value field of a TLV MAY
      include fixed fields and/or other TLVs.

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

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

3.7.  General Principles for the Design of ANCP Messages

   ANCP allows for two messaging constructs to support request/response
   interaction:

   a.  The same message type is used for both the request message and
       the response message.  The Result and Result Code field settings
       are used to differentiate between request and response messages.

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



 Wadhwa, et al.         Expires October 28, 2011               [Page 37]

Internet-Draft                ANCP Protocol                   April 2011


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

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

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

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


4.  Generally Useful ANCP Messages and TLVs

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

4.1.  Provisioning Message

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







 Wadhwa, et al.         Expires October 28, 2011               [Page 38]

Internet-Draft                ANCP Protocol                   April 2011


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

               Figure 9: Format of the Provisioning Message

   The message header field settings given below are REQUIRED in the
   Provisioning message.  The remaining message header fields MUST be
   set as specified in Section 3.6.1.  Which TLVs to carry in the
   Provisioning message is specified as part of the specification of the
   capabilities that use that message.  The Provisioning message MAY be
   used to carry data relating to more than one capability at once,
   assuming that the capabilities concerned can co-exist and have all
   been negotiated during adjacency establishment.

   Message Type:  MUST be set to 93.

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

   Result Code:  MUST be set to zero.

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

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

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

4.2.  Generic Response Message

   This section defines the Generic Response message.  The Generic
   Response message MAY be specified as the appropriate response to a
   message defined in an extension to ANCP, instead of a more specific



 Wadhwa, et al.         Expires October 28, 2011               [Page 39]

Internet-Draft                ANCP Protocol                   April 2011


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

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

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

   The format of the Generic Response message is shown in Figure 10

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           TCP/IP Encapsulating Header (Section 3.2)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                ANCP General Message Header                    |
   +                      (Section 3.6.1)                          +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Access line identifying TLV(s)                 |
   +                (copied from original request)                 +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Status-Info TLV                            |
   ~                     (Section 4.5)                             ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

           Figure 10: Structure of the Generic Response Message

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



 Wadhwa, et al.         Expires October 28, 2011               [Page 40]

Internet-Draft                ANCP Protocol                   April 2011


   Message Type:  MUST be set to 91.

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

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

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

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

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

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

4.3.  Target TLV

   Type:  0x1000 to 0x1020 depending on the specific content.  Only
      0x1000 has been assigned in this specification (see below).
      Support of any specific variant of the Target TLV is OPTIONAL
      unless the ANCP agent claims support for a capability that
      requires its use.

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

   Length:  Variable, depending on the specific object type.

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

   TLV Type 0x1000 is assigned to a variant of the Target TLV
   representing a single access line and encapsulating one or more sub-
   TLVs identifying the target.  Figure 11 is an example illustrating
   the TLV format for a single port identified by an Access-Loop-
   Circuit-ID TLV (0x0001) (Section 5.1.2.1).





 Wadhwa, et al.         Expires October 28, 2011               [Page 41]

Internet-Draft                ANCP Protocol                   April 2011


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

          Figure 11: Example of Target TLV For Single Access Line

4.4.   Command TLV

   Type:  0x0011

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

   Length:  Variable, depending on the specific contents.

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

4.5.  Status-Info TLV

   Name:  Status-Info

   Type:  0x0106






 Wadhwa, et al.         Expires October 28, 2011               [Page 42]

Internet-Draft                ANCP Protocol                   April 2011


   Description:  The Status-Info-TLV is intended to be a general
      container for warning or error diagnostics relating to commands
      and/or requests.  It is a supplement to the Result Code field in
      the ANCP general header.  The specifications for individual
      message types MAY indicate the use of this TLV as part of
      responses, particularly for failures.  As mentioned above, the
      Generic Response message will usually include an instance of the
      Status-Info TLV.  Support of the Status-Info TLV, both as sender
      and as receiver, is REQUIRED for all ANCP agents, regardless of
      what capabilities they support.

   Length:  Variable, depending on the specific contents.

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

      Reserved (8 bits):  see Section 3.4 for handling of reserved
         fields.

      Msg Type (8 bits):  Message Type of the request for which this TLV
         is providing diagnostics.

      Result Message Length (16 bits):  Number of bytes in the error
         message, excluding padding, but including the language tag and
         delimiter.  This MAY be zero if no error message is provided.

      Result Message:  Human-readable string providing information about
         the warning or error condition.  The initial characters of the
         string MUST be a language tag as described in [RFC5646],
         terminated by a colon (":").  The actual text string follows
         the delimiter.  The field is padded at the end with zeroes as
         necessary to extend it to a four-byte word boundary.

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

   Figure 12 illustrates the Status-Info TLV.













 Wadhwa, et al.         Expires October 28, 2011               [Page 43]

Internet-Draft                ANCP Protocol                   April 2011


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    TLV Type = 0x0106          |              Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Reserved   |  Msg Type     |      Error Message Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Error Message (padded to 4 byte boundary)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           optional sub-TLVs...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 12: The Status-Info TLV


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

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

   The next three sections of this document specify basic ANCP
   capabilities for use specifically in controlling Access Nodes serving
   DSL access (Tech Type = 0x05).  The same ANs could be serving other
   access technologies (e.g.  Metro-Ethernet, Passive Optical
   Networking, WiMax), in which case the AN will also have to support
   the corresponding other-technology-specific capabilities.  Those
   additional capabilities are outside the scope of the present
   document.

5.1.  DSL Access Line Identification

   Most ANCP messages involve actions relating to a specific access
   line.  Thus it is necessary to describe how access lines are
   identified within those messages.  This section defines four TLVs for
   that purpose and provides an informative description of how they are
   used.

5.1.1.  Control Context (Informative)

   Three types of identification are described in [TR-101] and provided
   for in the TLVs defined in this section:

   o  identification of an access line by its logical appearance on the
      user side of the Access Node;




 Wadhwa, et al.         Expires October 28, 2011               [Page 44]

Internet-Draft                ANCP Protocol                   April 2011


   o  identification of an access line by its logical appearance on the
      NAS side of the Access Node; and

   o  identification down to the user or host level as a supplement to
      access line identification in one of the other two forms.

   All of these identifiers originate with the AN control application,
   during the process of DSL topology discovery.  The control
   application chooses which identifiers to use and the values to place
   into them on a line-by-line basis, based on AN configuration and
   deployment considerations.

   Aside from its use in ANCP signalling, access line identification is
   also used in DHCP ([RFC2131], [RFC3315]) transactions involving hosts
   served by DSL.  Either the AN or the NAS can serve as a DHCP relay
   node.  [TR-101] requires the AN or NAS in this role to add access
   line identification in Option 82 (Information) ([RFC3046], with its
   IPv6 equivalent in [RFC4649]) to each DHCP request it forwards to the
   DHCP server.  It is desirable for efficiency that the identification
   used in this signalling should be the same as the identification used
   in ANCP messages.

   From the point of view of ANCP itself, the identifiers are opaque.
   From the point of view of the AN control application, the syntax for
   the user-side access line identifier is the same as specified in
   Section 3.9.3 of [TR-101] for DHCP Option 82.  The syntax for the
   ASCII form of the NAS-side access line identifier will be similar.

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

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

      Sections 3.8 and 3.9 of [TR-101] are contradictory on this point.
      It is assumed here that Section 3.9 is meant to be authoritative.

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



 Wadhwa, et al.         Expires October 28, 2011               [Page 45]

Internet-Draft                ANCP Protocol                   April 2011


   The NAS control application will use the identifying information it
   receives from the AN directly for some purposes.  For examples, see
   the introductory part of Section 3.9 of [TR-101].  For other
   purposes, the NAS will build a mapping between the unique access line
   identification provided by the AN, the additional identification of
   the user or host (where provided), and the IP interface on a
   particular host.  For access lines with static IP address assignment
   that mapping could be configured instead.

5.1.2.  TLVs For DSL Access Line Identification

   This section provides a normative specification of the TLVs that ANCP
   provides to carry the types of identification just described.  The
   Access-Loop-Circuit-ID TLV identifies an access line by its logical
   appearance on the user side of the Access Node.  Two alternatives,
   the Access-Aggregation-Circuit-ID-ASCII TLV and the Access-
   Aggregation-Circuit-ID-Binary TLV, identify an access line by its
   logical appearance on the NAS side of the Access Node.  It is
   unlikely that a given AN uses both of these TLVs, either for the same
   line or for different lines, since they carry equivalent information.
   Finally, the Access-Loop-Remote-Id TLV contains an operator-
   configured string that uniquely identifies the user on the associated
   access line, as described in Sections 3.9.1 and 3.9.2 of [TR-101].

   ANCP agents conforming to this section MUST satisfy the following
   requirements:

   o  ANCP agents MUST be able to build and send the Access-Loop-
      Circuit-ID TLV, the Access-Loop-Remote-Id TLV, and either the
      Access-Aggregation-Circuit-ID-ASCII TLV or the Access-Aggregation-
      Circuit-ID-Binary TLV (implementation choice), when passed the
      associated information from the AN control application.

   o  ANCP agents MUST be able to receive all four TLV types, extract
      the relevant information, and pass it to the control application.

   o  If the Access-Loop-Remote-Id TLV is present in a message, it MUST
      be accompanied by an Access-Loop-Circuit-ID TLV and/or an Access-
      Aggregation-Circuit-ID-xxx TLV with two VLAN identifiers.

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






 Wadhwa, et al.         Expires October 28, 2011               [Page 46]

Internet-Draft                ANCP Protocol                   April 2011


   o  If the Access-Aggregation-Circuit-ID-xxx TLV is present in a
      message with just one VLAN identifier, it MUST be accompanied by
      an Access-Loop-Circuit-ID TLV.

5.1.2.1.  Access-Loop-Circuit-ID TLV

   Type:  0x0001

   Description:  a locally administered human-readable string generated
      by or configured on the Access Node, identifying the corresponding
      access loop logical port on the user side of the Access Node.

   Length:  up to 63 bytes

   Value:  ASCII string

5.1.2.2.  Access-Loop-Remote-Id TLV

   Type:  0x0002

   Description:  an operator-configured string that uniquely identifies
      the user on the associated access line, as described in Sections
      3.9.1 and 3.9.2 of [TR-101].

   Length:  up to 63 bytes

   Value:  ASCII string

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

   Type:  0x0006

   Description:  This TLV identifies or partially identifies a specific
      access line by means of its logical circuit identifier on the NAS
      side of the Access Node.

      For Ethernet access aggregation, where a per-subscriber (stacked)
      VLAN can be applied (1:1 model as defined in [TR-101]), the TLV
      contains two value fields.  Each field carries a 12-bit VLAN
      identifier (which is part of the VLAN tag defined by IEEE 802.1Q).
      The first field MUST carry the inner VLAN identifier, while the
      second field MUST carry the outer VLAN identifier.

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




 Wadhwa, et al.         Expires October 28, 2011               [Page 47]

Internet-Draft                ANCP Protocol                   April 2011


      In the case of an ATM aggregation network, where the DSLAM is
      directly connected to the NAS (without an intermediate ATM
      switch), the VPI and VCI on the DSLAM uplink correspond uniquely
      to the DSL line on the DSLAM.  The Access-Aggregation-Circuit-ID-
      Binary TLV MAY be used to carry the VPI and VCI.  The first value
      field of the TLV MUST carry the VCI, while the second value field
      MUST carry the VPI.

      Each identifier MUST be placed in the low-order bits of its
      respective 32-bit field, with the higher-order bits set to zero.
      The ordering of the bits of the identifer MUST be the same as when
      the identifier is transmitted on the wire to identify an Ethernet
      frame or ATM cell.

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

   Length:  4 or 8 bytes

   Value:  one or two 32-bit binary fields.


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

          Figure 13: The Access-Aggregation-Circuit-ID-Binary TLV

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

   Type:  0x0003

   Description:  This TLV transmits the ASCII equivalent of the Access-
      Aggregation-Circuit-ID-Binary TLV.  As mentioned in the previous
      section, the AN control application will use a format similar to
      that specified in Section 3.9.3 of [TR-101] for the format of the
      "circuit-id".

      As an extension to the present document, the Access Node could
      convey to the NAS the characteristics (e.g., bandwidth) of the
      uplink on the Access Node.  This TLV or the binary equivalent
      defined above then serves the purpose of uniquely identifying the



 Wadhwa, et al.         Expires October 28, 2011               [Page 48]

Internet-Draft                ANCP Protocol                   April 2011


      uplink whose characteristics are being defined.  The present
      document does not specify the TLVs needed to convey the uplink
      characteristics.

   Length:  up to 63 bytes

   Value:  ASCII string


6.  ANCP Based DSL Topology Discovery

   Section 3.1 of [RFC5851] describes the requirements for the DSL
   Topology Discovery capability.

6.1.  Control Context (Informative)

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

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

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

   o  whenever the AN control application wishes to signal that a line
      attribute has changed.

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

   o  when a new adjacency with the NAS is established, for each DSL
      loop that is provisioned but not synchronized at that time;

   o  whenever a DSL loop that is equipped in an AN but administratively
      disabled is signalled as "IDLE"; and

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

   The AN control application passes information to identify the DSL
   loop to ANCP to include in the Port Up or Port Down message, along
   with information relating to DSL loop attributes.

   In the case of bonded copper loops to the customer premise (as per
   DSL multi-pair bonding described by [G.988.1] and [G.988.2]), the AN
   control application requests that ANCP send DSL-specific Port Up and
   Port Down messages for the aggregate "DSL bonded circuit"



 Wadhwa, et al.         Expires October 28, 2011               [Page 49]

Internet-Draft                ANCP Protocol                   April 2011


   (represented as a single logical port) as well as the individual DSL
   loops of which it is comprised.  The information relating to DSL line
   attributes that is passed by the AN control application is aggregate
   information.

   ANCP generates the DSL-specific Port Up or Port Down message and
   transfers it to the NAS.  ANCP on the NAS side passes an indication
   to the NAS control application that a DSL Port Up or Port Down
   message has been received along with the information contained in the
   message.

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

   Figure 14 summarizes the interaction.


   1.   Home            Access                          NAS
       Gateway           Node

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

   2.   Home            Access                          NAS
       Gateway           Node

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

   3.   Home            Access                          NAS
       Gateway           Node

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

          Figure 14: ANCP Message Flow For DSL Topology Discovery

6.2.  Protocol Requirements

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





 Wadhwa, et al.         Expires October 28, 2011               [Page 50]

Internet-Draft                ANCP Protocol                   April 2011


6.2.1.  Protocol Requirements On the AN Side

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

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

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

6.2.2.  Protocol Requirements On the NAS Side

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

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

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

6.3.  ANCP Port UP and Port DOWN Event Message Descriptions

   The format of the ANCP Port UP and Port DOWN Event messages is shown
   in Figure 15.





















 Wadhwa, et al.         Expires October 28, 2011               [Page 51]

Internet-Draft                ANCP Protocol                   April 2011


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           TCP/IP Encapsulating Header (Section 3.2)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                ANCP General Message Header                    |
   +                      (Section 3.6.1)                          +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Unused (20 bytes)                          ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |x|x|x|x|x|x|x|x| Message Type  |   Tech Type   |  Reserved     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     # of TLVs                 | Extension Block length (bytes)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                 Access line identifying TLV(s)                ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                DSL-Line-Attributes TLV                        |
   ~        (MANDATORY in Port Up, OPTIONAL in Port Down)          ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

    Figure 15: Format Of the ANCP Port Up and Port Down Event Messages
                        For DSL Topology Discovery

   See Section 3.6.1 for a description of the ANCP general message
   header.  The Message Type field MUST be set to 80 for Port Up, 81 for
   Port Down.  The 12 bit Result Code field MUST be set to 0.  The 4 bit
   Result field MUST be set to 0 (signifying Ignore).  The 24-bit
   Transaction Identifier field MUST be set to 0.  Other fields in the
   general header MUST be set as described in Section 3.6.

   The five word Unused field is a historical leftover.  The handling of
   unused/reserved fields is described in Section 3.4.

   The remaining message fields belong to the "extension block", and are
   described as follows:







 Wadhwa, et al.         Expires October 28, 2011               [Page 52]

Internet-Draft                ANCP Protocol                   April 2011


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

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

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

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

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

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

6.4.  Procedures

6.4.1.  Procedures On the AN Side

   The AN-side ANCP agent creates and transmits a DSL-specific Port Up
   or Port Down message when requested by the AN control application and
   presented with the information needed to build a valid message.  It
   is RECOMMENDED that the Access Node use a dampening mechanism per DSL
   loop to control the rate at which state changes are communicated to
   the NAS.

   At the top level, the extension block within a DSL-specific Port Up
   or Port Down message MUST include TLVs from Section 5.1.2 to identify
   the DSL loop.

   TLVs presenting DSL line attributes (i.e., the TLVs specified in
   Section 6.5) MUST be encapsulated within the DSL-Line-Attributes TLV.
   When the DSL-Line-Attributes TLV is present in a message, it MUST
   contain at least one such TLV and will generally contain more than
   one.  In the Port Up message, the DSL-Line-Attributes TLV MUST be
   present.  In the Port Down message, the DSL-Line-Attributes TLV MAY
   be present.

6.4.2.  Procedures On the NAS Side

   The NAS-side ANCP agent MUST be prepared to receive Port Up and Port
   Down messages for a given DSL loop or logical port at any time after
   negotiation of an adjacency has been completed.  It is possible for
   two Port Up messages in succession to be received for the same DSL
   loop without an intervening Port Down message, and vice versa.



 Wadhwa, et al.         Expires October 28, 2011               [Page 53]

Internet-Draft                ANCP Protocol                   April 2011


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

   If the received message passes validation, the NAS-side ANCP agent
   extracts the information from the TLVs contained in the message and
   presents that information along with an indication of reported event
   type to the NAS control application.  If validation of individual
   TLVs fails but the message as a whole can be processed, the NAS-side
   ANCP agent "may" pass the valid message contents to the NAS control
   application.

6.5.  TLVs For DSL Line Attributes

   As specified above, the DSL-Line-Attributes TLV is inserted into the
   Port Up or Port Down message at the top level.  The remaining TLVs
   defined below are encapsulated within the DSL-Line-Attributes TLV.

6.5.1.  DSL-Line-Attributes TLV

   Type:  0x0004

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

   Length:  variable (up to 1024 bytes)

   Value:  one or more encapsulated TLVs corresponding to DSL line
      attributes.  The DSL-Line-Attributes TLV MUST contain at least one
      TLV when it is present in a Port Up or Port Down message.  The
      actual contents are determined by the AN control application.

6.5.2.  DSL-Type TLV

   Type:  0x0091

   Description:  Indicates the type of transmission system in use.

   Length:  4 bytes






 Wadhwa, et al.         Expires October 28, 2011               [Page 54]

Internet-Draft                ANCP Protocol                   April 2011


   Value:  32 bit unsigned integer

         ADSL1 = 1

         ADSL2 = 2

         ADSL2+ = 3

         VDSL1 = 4

         VDSL2 = 5

         SDSL = 6

         OTHER = 0

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

   Type:  0x0081

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

   Length:  4 bytes

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

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

   Type:  0x0082

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

   Length:  4 bytes

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

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

   Type:  0x0083

   Description:  Minimum upstream net data rate desired by the operator.

   Length:  4 bytes

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






 Wadhwa, et al.         Expires October 28, 2011               [Page 55]

Internet-Draft                ANCP Protocol                   April 2011


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

   Type:  0x0084

   Description:  Minimum downstream net data rate desired by the
      operator.

   Length:  4 bytes

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

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

   Type:  0x0085

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

   Length:  4 bytes

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

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

   Type:  0x0086

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

   Length:  4 bytes

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

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

   Type:  0x0087

   Description:  Maximum net upstream data rate desired by the operator.

   Length:  4 bytes

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

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







 Wadhwa, et al.         Expires October 28, 2011               [Page 56]

Internet-Draft                ANCP Protocol                   April 2011


   Type:  0x0088

   Description:  Maximum net downstream data rate desired by the
      operator.

   Length:  4 bytes

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

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

   Type:  0x0089

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

   Length:  4 bytes

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

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

   Type:  0x008A

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

   Length:  4 bytes

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

6.5.13.  Maximum-Interleaving-Delay-Upstream TLV

   Type:  0x008B

   Description:  maximum one way interleaving delay.

   Length:  4 bytes

   Value:  Time in ms as a 32 bit unsigned integer

6.5.14.  Actual-Interleaving-Delay-Upstream TLV

   Type:  0x008C







 Wadhwa, et al.         Expires October 28, 2011               [Page 57]

Internet-Draft                ANCP Protocol                   April 2011


   Description:  Value corresponding to the interleaver setting.

   Length:  4 bytes

   Value:  Time in ms as a 32 bit unsigned integer

6.5.15.  Maximum-Interleaving-Delay-Downstream TLV

   Type:  0x008D

   Description:  maximum one way interleaving delay.

   Length:  4 bytes

   Value:  Time in ms as a 32 bit unsigned integer

6.5.16.  Actual-Interleaving-Delay-Downstream

   Type:  0x008E

   Description:  Value corresponding to the interleaver setting.

   Length:  4 bytes

   Value:  Time in ms as a 32 bit unsigned integer

6.5.17.  DSL-Line-State TLV

   Type:  0x008F

   Description:  The state of the DSL line.

   Length:  4 bytes

   Value:  32 bit unsigned integer

         SHOWTIME = 1

         IDLE = 2

         SILENT = 3

6.5.18.  Access-Loop-Encapsulation TLV








 Wadhwa, et al.         Expires October 28, 2011               [Page 58]

Internet-Draft                ANCP Protocol                   April 2011


   Type:  0x0090

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

   Length:  3 bytes

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

         Byte 1: Data Link

            ATM AAL5 = 0

            ETHERNET = 1

         Byte 2: Encapsulation 1

            NA = 0

            Untagged Ethernet = 1

            Single-tagged Ethernet = 2

            Double-tagged Ethernet = 3

         Byte 3: Encapsulation 2

            NA = 0

            PPPoA LLC = 1

            PPPoA NULL = 2

            IPoA LLC = 3

            IPoA NuLL = 4

            Ethernet over AAL5 LLC with FCS = 5

            Ethernet over AAL5 LLC without FCS = 6

            Ethernet over AAL5 NULL with FCS = 7




 Wadhwa, et al.         Expires October 28, 2011               [Page 59]

Internet-Draft                ANCP Protocol                   April 2011


            Ethernet over AAL5 NULL without FCS = 8

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

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    TLV Type = 0x0090          |        Length = 3             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Data link     |    Encaps 1   |    Encaps 2   | Padding (=0)  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 16: The Access-Loop-Encapsulation TLV


7.  ANCP based DSL Line Configuration

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

7.1.  Control Context (Informative)

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

     Home            Access               NAS             RADIUS/AAA
    Gateway           Node                             Policy Server

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

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

                          <----------------
                            Port Management message
                            (line configuration)

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



 Wadhwa, et al.         Expires October 28, 2011               [Page 60]

Internet-Draft                ANCP Protocol                   April 2011


   The NAS could update the line configuration as a result of a
   subscriber service change (e.g. triggered by the policy server).
   Figure 18 summarizes the interaction.

User     Home            Access         NAS
        Gateway           Node

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

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

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

   Figure 18: Message flow - ANCP Mapping For Updated Line Configuration

7.2.  Protocol Requirements

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

7.2.1.  Protocol Requirements On the NAS Side

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

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

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

7.2.2.  Protocol Requirements On the AN Side

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

   The AN-side ANCP agent MUST be able to receive and validate DSL-



 Wadhwa, et al.         Expires October 28, 2011               [Page 61]

Internet-Draft                ANCP Protocol                   April 2011


   specific Port Management (line configuration) messages according to
   the format specified in Section 7.3.

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

7.3.  ANCP Port Management (Line Configuration) Message Format

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

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           TCP/IP Encapsulating Header (Section 3.2)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                ANCP General Message Header                    |
   +                      (Section 3.6.1)                          +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Unused (12 bytes)                       ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Unused (2 bytes)       |  Function=8   | X-Function=0  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Unused (4 bytes)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |x|x|x|x|x|x|x|x| Message Type  |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     # of TLVs               | Extension Block length (bytes)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                 Access line identifying TLV(s)                ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                Line configuration TLV(s)                      ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

       Figure 19: Port Management Message For DSL Line Configuration

   See Section 3.6 for a description of the ANCP general message header.



 Wadhwa, et al.         Expires October 28, 2011               [Page 62]

Internet-Draft                ANCP Protocol                   April 2011


   The Message Type field MUST be set to 32.  The 12 bit Result Code
   field MUST be set to 0x0.  The 4 bit Result field MUST be set to
   either 1 (NAck) or 2 (AckAll), as determined by policy on the NAS.
   The 24-bit Transaction Identifier field MUST be set to a positive
   value.  Other fields in the general header MUST be set as described
   in Section 3.6.

   The handling of the various unused/reserved fields is described in
   Section 3.4.

   The remaining message fields are described as follows:

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

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

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

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

   Reserved (16 bits):  reserved for future use.

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

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

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

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

   Use of the Port Management message for configuration MAY also be
   generalized to other access technologies, if the respective



 Wadhwa, et al.         Expires October 28, 2011               [Page 63]

Internet-Draft                ANCP Protocol                   April 2011


   capabilities specify use of access line identifiers appropriate to
   those technologies in place of the identifiers defined in
   Section 5.1.2.

7.4.  Procedures

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

7.4.1.  Procedures On the NAS Side

   When requested by the NAS control application and presented with the
   necessary information to do so, the NAS-side agent MUST create and
   send a Port Management message with the fixed fields set as described
   in the previous section.  The message MUST contain one or more TLVs
   to identify an access line according the requirements of
   Section 5.1.2.  The NAS MUST include one or more TLVs to configure
   line service parameters for that line.  Section 7.5 currently
   identifies only one such TLV, Service-Profile-Name, but other TLVs
   MAY be added by extensions to ANCP.

7.4.2.  Procedures On the AN Side

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

   The AN-side ANCP agent SHOULD validate each message against the
   specifications given in Section 7.3 and the TLV specifications given
   in Section 5.1.2 and Section 7.5.  If it finds an error it MUST
   return a Port Management response message which copies the Port
   Management request as it was received, but has the Result header
   field set to 0x04 (Failure) and the Result Code field set to the
   appropriate value.  The AN-side agent MAY add a Status-Info TLV
   (Section 4.5) to provide further information on the error,
   particularly if this is recommended in Section 3.6.1.4 for the given
   Result Code value.  If it does so, the various length fields and the
   # of TLVs field within the message MUST be adjusted accordingly.

   If the received message passes validation, the AN-side ANCP agent
   "must" extract the information from the TLVs contained in the message
   and present that information to the AN control application.  In
   addition, if the Result header field was set to 0x2 (AckAll) in the
   original request, the AN-side agent "must" indicate to the AN control
   application that a response is required.  When the AN control
   application indicates that it has processed the request successfully,
   the AN-side agent MUST return a Port Management response message
   which duplicates the request except that the Result header field is



 Wadhwa, et al.         Expires October 28, 2011               [Page 64]

Internet-Draft                ANCP Protocol                   April 2011


   set to 0x3 (Success).  (The Result Code field, as in the original
   request, has value 0.)

7.5.  TLVs For DSL Line Configuration

   Currently only the following TLV is specified for DSL line
   configuration.  More TLVs may be defined in a future version of this
   specification or in ANCP extensions for individual service attributes
   of a DSL line (e.g. rates, interleaving delay, multicast channel
   entitlement access-list).

7.5.1.  Service-Profile-Name TLV

   Type:  0x0005

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

   Length:  up to 64 bytes

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


8.  ANCP-Based DSL Remote Line Connectivity Testing

   The use case and requirements for ANCP-Based DSL remote line
   connectivity testing are specified in Section 3.3 of [RFC5851]

8.1.  Control Context (Informative)

   The NAS control application initiates a request for remote
   connectivity testing for a given access loop.  The NAS control
   application can provide loop count and timeout test parameters and
   opaque data for its own use with the request.  The loop count
   parameter indicates the number of test messages or cells to be used.
   The timeout parameter indicates the longest that the NAS control
   application will wait for a result.

   The request is passed in a Port Management (OAM) message.  If the NAS
   control application has supplied test parameters, they are used,
   otherwise the AN control application uses default test parameters.
   If a loop count parameter provided by the NAS is outside the valid
   range, the AN does not execute the test, but returns a result
   indicating that the test has failed due to an invalid parameter.  If
   the test takes longer than the timeout value (default or provided by
   the NAS) the AN control application can return a failure result
   indicating timeout or else can send no response.  The AN control



 Wadhwa, et al.         Expires October 28, 2011               [Page 65]

Internet-Draft                ANCP Protocol                   April 2011


   application can provide a human-readable string describing the test
   results, for both failures and successes.  If provided, this string
   is included in the response.  Responses always include the opaque
   data, if any, provided by the NAS control application.

   Figure 20 summarizes the interaction.

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

                Figure 20: Message Flow For ANCP based OAM

8.2.  Protocol Requirements

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

8.2.1.  Protocol Requirements On the NAS Side

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

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

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

8.2.2.  Protocol Requirements On the AN Side

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

   The AN-side ANCP agent MUST be able to receive and validate DSL-



 Wadhwa, et al.         Expires October 28, 2011               [Page 66]

Internet-Draft                ANCP Protocol                   April 2011


   specific Port Management (OAM) messages according to the format
   specified in Section 8.3.

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

8.3.  Port Management (OAM) Message Format

   The Port Management message for DSL line testing has the same format
   as for DSL line configuration (see Section 7.3), 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.

   The Port Management (OAM) message is illustrated in Figure 21.



























 Wadhwa, et al.         Expires October 28, 2011               [Page 67]

Internet-Draft                ANCP Protocol                   April 2011


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

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

    Figure 21: Port Management Message For DSL Line Remote Connectivity
                                  Testing

8.4.  Procedures

   From the point of view of ANCP, it is permissible to attempt line
   connectivity testing regardless of the state of the line.  However,
   testing could fail in some states due to technology limitations.

8.4.1.  NAS-Side Procedures

   When requested by the NAS control application and presented with the
   necessary information to do so, the NAS-side agent creates and sends



 Wadhwa, et al.         Expires October 28, 2011               [Page 68]

Internet-Draft                ANCP Protocol                   April 2011


   a Port Management (OAM) request with the fixed fields set as
   described in the previous section.  The message MUST contain one or
   more TLVs to identify an access line according the requirements of
   Section 5.1.2.  The NAS MAY include the Opaque-Data TLV and/or the
   OAM-Loopback-Test-Parameters TLV (defined in Section 8.5) to
   configure the loopback test for that line.

8.4.2.  AN-Side Procedures

   The AN-side ANCP agent SHOULD validate each message against the
   specifications given in Section 8.3 and the TLV specifications given
   in Section 5.1.2 and Section 8.5.  If it finds an error it MUST
   return a Port Management response message which copies the Port
   Management request as it was received, but has the Result header
   field set to 0x04 (Failure) and the Result Code field set to the
   appropriate value.  Result Code value 0x509 as described below MAY
   apply, as well as the other Result Code values documented in
   Section 3.6.1.4.  Result Code value 0x509 SHOULD be used if the OAM-
   Loopback-Test-Parameters TLV is present with an invalid value of the
   Count field.  The AN-side agent MAY add a Status-Info TLV
   (Section 4.5) to provide further information on the error,
   particularly if this is recommended in Section 3.6.1.4 for the given
   Result Code value.  If it does so, the various length fields and the
   # of TLVs field within the message MUST be adjusted accordingly.

   If the received message passes validation, the AN-side ANCP agent
   extracts the information from the TLVs contained in the message and
   presents that information to the AN control application.  It MUST NOT
   generate an immediate response to the request, but MUST instead wait
   for the AN control application to indicate that the response should
   be sent.

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

   0x500:  Specified access line does not exist.  See the documentation
      of Result Code 0x500 in Section 3.6.1.4 for more information.  The
      Result header field MUST be set to Failure (0x4).

   0x501:  Loopback test timed out.  The Result header field MUST be set
      to Failure (0x4).






 Wadhwa, et al.         Expires October 28, 2011               [Page 69]

Internet-Draft                ANCP Protocol                   April 2011


   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.  The Result header field MUST
      be set to Failure (0x04).

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

   All other fields of the request including the TLVs MUST be copied
   into the response unchanged, except that in a successful response the
   OAM-Loopback-Test-Parameters TLV MUST NOT appear.  If the AN control
   application has provided the necessary information, the AN-side agent
   MUST also include an instance of the OAM-Loopback-Test-Response-
   String TLV in the response.

8.5.  TLVs For the DSL Line Remote Connectivity Testing Capability

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

8.5.1.  OAM-Loopback-Test-Parameters TLV

   Type:  0x0007

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

   Length:  2 bytes

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

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

         Byte 2: Timeout.  Upper bound on the time in seconds that the
         NAS will wait for a response from the DSLAM.  The value 0 MAY
         be used to indicate that the DSLAM MUST use a locally



 Wadhwa, et al.         Expires October 28, 2011               [Page 70]

Internet-Draft                ANCP Protocol                   April 2011


         determined value for the timeout.

   The OAM-Loopback-Test-Parameters TLV is illustrated in Figure 22

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    TLV Type = 0x0007          |        Length = 2             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Count       |  Timeout      |         Padding (=0)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

8.5.2.  Opaque-Data TLV

   Type:  0x0008

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

   Length:  8 bytes

   Value:  Two 32 bit unsigned integers.

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

   Type:  0x0009

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

   Length:  up to 128 bytes

   Value:  UTF-8 encoded string of text.


9.  IANA Considerations

   IANA NOTE: please replace "RFCXXXX" with the number of this
   specification.






 Wadhwa, et al.         Expires October 28, 2011               [Page 71]

Internet-Draft                ANCP Protocol                   April 2011


9.1.  Summary

   This section requests the following IANA actions:

   o  establishment of the following new ANCP registries:

         ANCP Message Types;

         ANCP Result Codes;

         ANCP Port Management Functions;

         ANCP Technology Types;

         ANCP Command Codes;

         ANCP TLV Types;

         ANCP Capabilities.

   o  establishment of a new joint GSMP/ANCP version registry;

   o  addition of ANCP as another user of TCP port 6068 in the port
      number registry at http://www.iana.org/assignments/port-numbers.
      The current user is GSMP.

   All of these actions are described in detail below except for the
   port registration, for which the final point above should provide
   sufficient information.

9.2.  IANA Actions

9.2.1.  ANCP Message Type Registry

   IANA is requested to create a new registry, Access Network Control
   Protocol (ANCP) Message Types.  Additions to that registry are
   permitted by Standards Action, as defined by [RFC5226].  The values
   for Message Type MAY range from 0 to 255, but new Message Types
   SHOULD be assigned values sequentially from 90 onwards (noting that
   91 and 93 are already assigned).  The initial contents of the ANCP
   Message Types registry are as follows:










 Wadhwa, et al.         Expires October 28, 2011               [Page 72]

Internet-Draft                ANCP Protocol                   April 2011


             +--------------+--------------------+-----------+
             | Message Type | Message Name       | Reference |
             +--------------+--------------------+-----------+
             | 10           | Adjacency Protocol | RFCXXXX   |
             | 32           | Port Management    | RFCXXXX   |
             | 80           | Port Up            | RFCXXXX   |
             | 81           | Port Down          | RFCXXXX   |
             | 85           | Adjacency Update   | RFCXXXX   |
             | 91           | Generic Response   | RFCXXXX   |
             | 93           | Provisioning       | RFCXXXX   |
             +--------------+--------------------+-----------+

9.2.2.  ANCP Result Code Registry

   IANA is requested to create a new registry, Access Network Control
   Protocol (ANCP) Result Codes.  The documentation of new Result Codes
   MUST include the following information:

   o  Result Code value TBD (as assigned by IANA);

   o  One-line description;

   o  Where condition detected: (control application or ANCP agent);

   o  Further description (if any);

   o  Required additional information in the response message;

   o  Target (control application or ANCP agent at the peer that sent
      the original request);

   o  Action RECOMMENDED for the receiving ANCP agent

   The values for Result Code are expressed in hexadecimal, and MAY
   range from 0x0 to 0xFFFFFF.  The range 0x0 to 0xFFF is reserved for
   allocation by the criterion of IETF Review, as defined by [RFC5226].
   IANA SHOULD allocate new Result Code values from this range
   sequentially beginning at 0x100.  The range 0x1000 onwards is
   allocated by the criterion of Specification Required, as defined by
   [RFC5226].  IANA SHOULD allocate new Result Code values from this
   range sequentially beginning at 0x1000.  The initial contents of the
   ANCP Message Types registry are as follows:









 Wadhwa, et al.         Expires October 28, 2011               [Page 73]

Internet-Draft                ANCP Protocol                   April 2011


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

9.2.3.  ANCP Port Management Function Registry

   IANA is requested to create a new Access Network Control Protocol
   (ANCP) Port Management Function registry, with the following initial
   entries.  Additions to this registry will be by Standards Action, as
   defined by [RFC5226].  Values may range from 0 to 255.  IANA SHOULD
   assign values sequentially beginning with 1, taking account of the
   values already assigned below.

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

    +----------------+-----------------------------------+-----------+
    | Function Value | Function Name                     | Reference |
    +----------------+-----------------------------------+-----------+
    | 0              | Reserved                          | RFCXXXX   |
    | 8              | Configure Connection Service Data | RFCXXXX   |
    | 9              | Remote Loopback                   | RFCXXXX   |
    +----------------+-----------------------------------+-----------+





 Wadhwa, et al.         Expires October 28, 2011               [Page 74]

Internet-Draft                ANCP Protocol                   April 2011


9.2.4.  ANCP Technology Type Registry

   IANA is requested to create a new Access Network Control Protocol
   (ANCP) Technology Type registry, with additions by Expert Review, as
   defined by [RFC5226].  The Technology Type MUST designate a distinct
   access transport technology.  Values may range from 0 to 255.  IANA
   SHOULD assign new values sequentially beginning at 2, taking into
   account of the values already assigned below.  The initial entries
   are as follows:

        +-----------------+--------------------------+-----------+
        | Tech Type Value | Tech Type Name           | Reference |
        +-----------------+--------------------------+-----------+
        | 0               | Not technology dependent | RFCXXXX   |
        | 1               | PON                      | RFCXXXX   |
        | 5               | DSL                      | RFCXXXX   |
        | 255             | Reserved                 | RFCXXXX   |
        +-----------------+--------------------------+-----------+

9.2.5.  ANCP Command Code Registry

   IANA is requested to create a new Access Network Control Protocol
   (ANCP) Command Code registry, with additions by Standards Action, as
   defined by [RFC5226].  Values may range from 0 to 255.  IANA SHOULD
   assign new values sequentially beginning with 1.  The initial entry
   is as follows:

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

9.2.6.  ANCP TLV Type Registry

   IANA is requested to create a new Access Network Control Protocol
   (ANCP) TLV Type registry.  Values are expressed in hexadecimal and
   may range from 0x0000 to 0xFFFF.  Additions in the range 0x0000 to
   0x1FFF are by IETF Review, as defined by [RFC5226].  IANA SHOULD
   assign new values in this range sequentially beginning at 0x100 and
   taking account of the assignments already made below.  Additions in
   the range 0x2000 to 0xFFFF are by Specification Required, again as
   defined by [RFC5226].  IANA SHOULD assign new values in this range
   sequentially beginning at 0x2000.  In both cases, the documentation
   of the TLV MUST provide:

   o  a TLV name following the convention used for the initial entries
      (capitalized words separated by hyphens);



 Wadhwa, et al.         Expires October 28, 2011               [Page 75]

Internet-Draft                ANCP Protocol                   April 2011


   o  a brief description of the intended use;

   o  a precise description of the contents of each fixed field,
      including its length, type, and units (if applicable);

   o  identification of any mandatory encapsulated TLVs;

   o  an indication of whether optional TLVs may be encapsulated, with
      whatever information is available on their identity (could range
      from a general class of information to specific TLV names,
      depending on the nature of the TLV being defined.

   The initial entries are as follows:

   +----------+--------------------------------------------+-----------+
   | Type     | TLV Name                                   | Reference |
   | Code     |                                            |           |
   +----------+--------------------------------------------+-----------+
   | 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                        | 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   |
   | 0x0011   | Command                                    | RFCXXXX   |
   | 0x0081   | Actual-Net-Data-Upstream                   | RFCXXXX   |
   | 0x0082   | Actual-Net-Data-Rate-Downstream            | RFCXXXX   |
   | 0x0083   | Minimum-Net-Data-Rate-Upstream             | RFCXXXX   |
   | 0x0084   | Minimum-Net-Data-Rate-Downstream           | RFCXXXX   |
   | 0x0085   | Attainable-Net-Data-Rate-Upstream          | RFCXXXX   |
   | 0x0086   | Attainable-Net-Data-Rate-Downstream        | RFCXXXX   |
   | 0x0087   | Maximum-Net-Data-Rate-Upstream             | RFCXXXX   |
   | 0x0088   | Maximum-Net-Data-Rate-Downstream           | RFCXXXX   |
   | 0x0089   | Minimum-Net-Low-Power-Data-Rate-Upstream   | RFCXXXX   |
   | 0x008A   | Minimum-Net-Low-Power-Data-Rate-Downstream | RFCXXXX   |
   | 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   |
   | 0x0106   | Status-Info                                | RFCXXXX   |
   | 0x1000   | Target (single access line variant)        | RFCXXXX   |



 Wadhwa, et al.         Expires October 28, 2011               [Page 76]

Internet-Draft                ANCP Protocol                   April 2011


   | 0x1001 - | Reserved for Target variants               | RFCXXXX   |
   | 0x1020   |                                            |           |
   +----------+--------------------------------------------+-----------+

9.2.7.  ANCP Capability Type Registry

   IANA is requested to create a new Access Network Control Protocol
   (ANCP) Capability Type registry, with additions by Standards Action
   as defined by [RFC5226].  Values may range from 0 to 255.  IANA
   SHOULD assign values sequentially beginning at 5.  The specification
   for a given capability MUST indicate the Technology Type value with
   which it is associated.  The specification MUST further indicate
   whether the capability is associated with any capability data.
   Normally a capability is expected to be defined in the same document
   that specifies the implementation of that capability in protocol
   terms.  The initial entries in the ANCP capability registry are as
   follows:

   +-------+------------------------+--------+-------------+-----------+
   | Value | Capability Type Name   | Tech   | Capability  | Reference |
   |       |                        | Type   | Data?       |           |
   +-------+------------------------+--------+-------------+-----------+
   | 0     | Reserved               |        |             | RFCXXXX   |
   | 1     | DSL Topology Discovery | 5      | No          | RFCXXXX   |
   | 2     | DSL Line Configuration | 5      | No          | RFCXXXX   |
   | 3     | Reserved               |        |             | RFCXXXX   |
   | 4     | DSL Line Testing       | 5      | No          | RFCXXXX   |
   +-------+------------------------+--------+-------------+-----------+

9.2.8.  Joint GSMP / ANCP Version Registry

   IANA is requested to create a new joint GSMP / ANCP Version registry.
   Additions to this registry are by Standards Action as defined by
   [RFC5226].  Values may range from 0 to 255.  Values for the General
   Switch Management Protocol (GSMP) MUST be assigned sequentially
   beginning with 4 for the next version.  Values for the Access Network
   Control Protocol (ANCP) MUST be assigned sequentially beginning with
   50 for the present version.  The initial entries are as follows:

                 +---------+----------------+-----------+
                 | Version | Description    | Reference |
                 +---------+----------------+-----------+
                 | 1       | GSMP Version 1 | RFC1987   |
                 | 2       | GSMP Version 2 | RFC2297   |
                 | 3       | GSMP Version 3 | RFC3292   |
                 | 50      | ANCP Version 1 | RFCXXXX   |
                 +---------+----------------+-----------+




 Wadhwa, et al.         Expires October 28, 2011               [Page 77]

Internet-Draft                ANCP Protocol                   April 2011


10.  Security Considerations

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

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

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

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

   o  The protocol solution MUST offer replay protection.

   o  The protocol solution MUST provide data-origin authentication.

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

   o  The protocol solution SHOULD offer confidentiality protection.

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

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

   For secure transport, either the combination of IPsec with IKEv2
   (references below) or the use of TLS [RFC5246] will meet the
   requirements listed above.  However, the use of TLS has been
   rejected.  The deciding point is a detail of protocol design that was
   unavailable when [RFC5713] was written.  The ANCP adjacency is a
   major point of vulnerability for denial-of-service attacks.  If the
   adjacency can be shut down, either the AN clears its state pending
   reestablishment of the adjacency, or the possibility of mismatches
   between the AN's and NAS's view of state on the AN is opened up.  Two
   ways to cause an adjacency to be taken down are to modify messages so
   that the ANCP agents conclude that they are no longer synchronized,



 Wadhwa, et al.         Expires October 28, 2011               [Page 78]

Internet-Draft                ANCP Protocol                   April 2011


   or to attack the underlying TCP session.  TLS will protect message
   contents, but not the TCP connection.  One has to use either IPsec or
   the TCP authentication option [RFC5925] for that.  Hence the
   conclusion that ANCP MUST run over IPsec with IKEv2 for
   authentication and key management.

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

   IKEv2 [RFC5996] is also REQUIRED, to meet the requirements for mutual
   authentication and authorization.  Since the NAS and AN MAY be in
   different trust domains, the use of certificates for mutual
   authentication could be the most practical approach.  However, this
   is up to the operator(s) concerned.

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


11.  Acknowledgements

   The authors would like to thank everyone who provided comments or
   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, and the further comments provided by Mykyta Yevstifeyev,
   Brian Carter, Ben Campbell, Alexey Melnikov, Adrian Farrel, Robert
   Sparks, Peter St. Andre, Sean Turner, and Dan Romascanu.


12.  References

12.1.  Normative References

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

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



 Wadhwa, et al.         Expires October 28, 2011               [Page 79]

Internet-Draft                ANCP Protocol                   April 2011


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

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

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

   [RFC5646]  Phillips, A. and M. Davis, "Tags for Identifying
              Languages", BCP 47, RFC 5646, September 2009.

   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
              "Internet Key Exchange Protocol Version 2 (IKEv2)",
              RFC 5996, September 2010.

12.2.  Informative References

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

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

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

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

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC4649]  Volz, B., "Dynamic Host Configuration Protocol for IPv6
              (DHCPv6) Relay Agent Remote-ID Option", RFC 4649,
              August 2006.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security



 Wadhwa, et al.         Expires October 28, 2011               [Page 80]

Internet-Draft                ANCP Protocol                   April 2011


              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

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

   [RFC5851]  Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S.
              Wadhwa, "Framework and Requirements for an Access Node
              Control Mechanism in Broadband Multi-Service Networks",
              RFC 5851, May 2010.

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

   [TR-058]   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 (now the Broadband Forum), "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.

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

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


Authors' Addresses

   Sanjay Wadhwa
   Alcatel-Lucent


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





 Wadhwa, et al.         Expires October 28, 2011               [Page 81]

Internet-Draft                ANCP Protocol                   April 2011


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

   Phone:
   Fax:
   Email: jmoisand@juniper.net


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

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


   Norbert Voigt
   Nokia Siemens Networks
   Siemensallee 1
   Greifswald  17489
   Germany

   Email: norbert.voigt@nsn.com


   Tom Taylor (editor)
   Huawei Technologies
   Ottawa
   Canada

   Email: tom111.taylor@bell.net














 Wadhwa, et al.         Expires October 28, 2011               [Page 82]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/