Network Working Group Name                                     Sanjay                                         S.  Wadhwa
     Internet Draft                                         Juniper Networks
Internet-Draft                                                J. Moisand
Intended status: Standards Track                          S. Subramanian
Expires: Jan 14, May 7, 2009                                  Jerome Moisand
                                                            Juniper Networks

                                                            Swami Subramanian                                    Juniper Networks

                                                            Thomas
                                                                T.  Haag
                                                            T-Systems

                                                            Norbert
                                                               T-systems
                                                                N. Voigt
                                                                 Siemens

                                                            July 14,
                                                             R. Maglione
                                                          Telecom Italia
                                                        November 3, 2008

    Protocol for Access Node Control Mechanism in Broadband Networks

                           draft-ietf-ancp-protocol-03.txt
                      draft-ietf-ancp-protocol-04

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with section Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

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

   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on Jan 14, May 7, 2009.

     Copyright Notice

        Copyright (C) The IETF Trust (2008).

Abstract

   This document describes proposed extensions to the GSMPv3 protocol to
   allow its use in a broadband environment, as a control plane between
   Access Nodes (e.g.  DSLAM) and Broadband Network Gateways (e.g.
   NAS).  These proposed extensions are required to realize a protocol
   for "Access Node Control" mechanism as described in [ANCP-FRAMEWORK].

   The resulting protocol with the proposed extensions to GSMPv3
   [RFC3292] is referred to as "Access Node Control Protocol" (ANCP).
   This document currently focuses on specific use cases of access node
   control mechanism for topology discovery, line configuration, and OAM
   as described in ANCP framework document [ANCP-FRAMEWORK].  It is
   intended to be augmented by additional protocol specification for
   future use cases considered in scope by the ANCP charter.

   ANCP framework document [ANCP-FRAMEWORK] describes the ANCP use-cases
   in detail.  Illustrative text for the use-cases is included here to
   help the protocol implementer understand the greater context of ANCP
   protocol interactions.

Table of Contents

        1

   1.  Specification Requirements . . . . . . . . . . . . . . . . . .  4

        2
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4

           2.1   Terminology..............................................5
        3
     2.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Broadband Access Aggregation                                   6

           3.1 . . . . . . . . . . . . . . . . .  5
     3.1.  ATM-based broadband aggregation..........................6
           3.2 aggregation  . . . . . . . . . . . . .  5
     3.2.  Ethernet-based broadband aggregation.....................7
        4 aggregation . . . . . . . . . . .  7
   4.  Access Node Control Protocol . . . . . . . . . . . . . . . . .  7
     4.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  8

           4.1   Overview.................................................8
           4.2   ANCP based Access Topology Discovery.....................9
              4.2.1    Goals..............................................9
              4.2.2    Message Flow.......................................9
           4.3   ANCP based Line Configuration...........................10
              4.3.1    Goals.............................................10
              4.3.2    Message Flow......................................11
           4.4   ANCP based Transactional Multicast......................13
           4.5
     4.2.  ANCP based OAM..........................................14
              4.5.1    Message Flow......................................14
        5  Access Node Control Protocol (ANCP) 15

           5.1   ANCP/TCP connection establishment.......................17
           5.2   ANCP Connection keep-alive..............................17
           5.3   Capability negotiation..................................18
           5.4   GSMP Message Extensions for Access Node Control.........21
              5.4.1    General Extensions................................21
              5.4.2 Topology Discovery Extensions.....................23
              5.4.3    Line Configuration Extensions.....................33
              5.4.4    OAM Extensions....................................36
           5.5   ATM-specific considerations.............................39
           5.6   Ethernet-specific considerations........................39
        6  IANA Considerations  40

        7  Security Considerations 40

        8  References  40

        Author's Addresses 42

        Full Copyright Statement 42

        Copyright (C) . . . . . . . . . . .  8
       4.2.1.  Goals  . . . . . . . . . . . . . . . . . . . . . . . .  8
       4.2.2.  Message Flow . . . . . . . . . . . . . . . . . . . . .  9
     4.3.  ANCP based Line Configuration  . . . . . . . . . . . . . . 10
       4.3.1.  Goals  . . . . . . . . . . . . . . . . . . . . . . . . 10
       4.3.2.  Message Flow . . . . . . . . . . . . . . . . . . . . . 11
     4.4.  ANCP based Transactional Multicast . . . . . . . . . . . . 13
       4.4.1.  Goals  . . . . . . . . . . . . . . . . . . . . . . . . 13
       4.4.2.  Message Flow . . . . . . . . . . . . . . . . . . . . . 14
     4.5.  ANCP based OAM . . . . . . . . . . . . . . . . . . . . . . 14
       4.5.1.  Message Flow . . . . . . . . . . . . . . . . . . . . . 15
   5.  Access Node Control Protocol (ANCP)  . . . . . . . . . . . . . 15
     5.1.  ANCP/TCP connection establishment  . . . . . . . . . . . . 19
     5.2.  ANCP Connection keep-alive . . . . . . . . . . . . . . . . 21
     5.3.  Capability negotiation . . . . . . . . . . . . . . . . . . 21
     5.4.  GSMP Message Extensions for Access Node Control  . . . . . 24
       5.4.1.  General Extensions . . . . . . . . . . . . . . . . . . 24
       5.4.2.  Topology Discovery Extensions  . . . . . . . . . . . . 25
       5.4.3.  Line Configuration Extensions  . . . . . . . . . . . . 35
       5.4.4.  OAM Extensions . . . . . . . . . . . . . . . . . . . . 38
       5.4.5.  Multicast Extensions . . . . . . . . . . . . . . . . . 41
         5.4.5.1.  General well known TLVs  . . . . . . . . . . . . . 42
           5.4.5.1.1.  Target TLV . . . . . . . . . . . . . . . . . . 42
           5.4.5.1.2.  Command TLV  . . . . . . . . . . . . . . . . . 43
           5.4.5.1.3.  Status-Info TLV  . . . . . . . . . . . . . . . 44
         5.4.5.2.  Multicast Replication Control Message  . . . . . . 45
         5.4.5.3.  Multicast Status Message . . . . . . . . . . . . . 52
     5.5.  ATM-specific considerations  . . . . . . . . . . . . . . . 53
     5.6.  Ethernet-specific considerations . . . . . . . . . . . . . 54
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 55
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 55
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 55
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 55
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 55
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
   Intellectual Property and Copyright Statements . . . . . . . . . . 59

1.  Specification Requirements

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

2.  Introduction

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

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

   This draft defines extensions and modifications to GSMPv3 (specified
   in [RFC3292]) and certain new mechanisms to realize a control plane
   between a service-oriented layer 3 edge device (the NAS) and a layer2
   Access Node (e.g.  DSLAM) in order to perform QoS-related, service-
   related and subscriber-related operations.  The control protocol as a
   result of these extensions and mechanisms is referred to as "Access
   Node Control Protocol" (ANCP).

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

   ANCP uses a subset of GSMPv3 messages to implement currently defined
   use-cases.  These relevant GSMPv3 messages are identified in section
   Section 5.  GSMPv3 procedures with suitable extensions, as used by
   ANCP, are described in sections Section 5.1, Section 5.2 and
   Section 5.3.  GSMPv3 general extensions and GSMPv3 message specific
   extensions required by ANCP are described in sub-sections of
   Section 5.4.  In addition to specifying extensions and modifications
   to relevant GSMP messages applicable to ANCP, this draft also defines
   the usage of these messages by ANCP.  Not all the fields in relevant
   GSMP messages are used by ANCP.  This draft indicates the value that
   ANCP should set for the fields in these GSMP messages.

2.1.  Terminology

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

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

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

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

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

   o  DSL multi-pair bonding: method for bonding (or aggregating)
      multiple xDSL lines into a single bi-directional logical link,
      henceforth referred to in this draft as "DSL bonded circuit".  DSL
      "multi-pair" 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.

3.   Broadband Access Aggregation

3.1.  ATM-based broadband aggregation

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

   The Regional/Access Network consists of the Regional Network, Network
   Access Server, and the Access Network as show in Figure 1.  Its
   primary function is to provide end-to-end transport between the
   customer premises and the NSP or ASP.  The Access Node terminates the
   DSL signal.  It could consist of DSLAM in the central office, or
   remote DSLAM, or a Remote Access Multiplexer (RAM).  Access node is
   the first point in the network where traffic on multiple DSL lines
   will be aggregated onto a single network.  The NAS performs multiple
   functions in the network.

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

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

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

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

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

               Figure 1: ATM Broadband Aggregation Topology

3.2.  Ethernet-based broadband aggregation

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

4.  Access Node Control Protocol

4.1.   Overview

   A dedicated control protocol between NAS and access nodes can
   facilitate "NAS managed" tight QOS control in the access network,
   simplified OSS infrastructure for service management, optimized
   multicast replication to enable video services over DSL, subscriber
   statistics retrieval on the NAS for accounting purposes, and fault
   isolation capability on the NAS for the underlying access technology.
   This dedicated control plane is referred to as "Access Node Control
   Protocol" (ANCP).  This document specifies relevant extensions to
   GSMPv3 as defined [RFC3292] to realize ANCP.

   Following sections discuss the use of ANCP for implementing:

   o  Dynamic discovery of access topology by the NAS to provide tight
      QOS control in the access network.

   o  Pushing to the access-nodes, subscriber and service data retrieved
      by the NAS from an OSS system (e.g. radius server), to simplify
      OSS infrastructure for service management.

   o  Optimized, "NAS controlled and managed" multicast replication by
      access-nodes at L2 layer.

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

   In addition to DSL, alternate broadband access technologies (e.g.
   Metro-Ethernet, Passive Optical Networking, WiMax) will have similar
   challenges to address, and could benefit from the same approach of a
   control plane between a NAS and an Access Node (e.g.  OLT), providing
   a unified control and management architecture for multiple access
   technologies, hence facilitating migration from one to the other
   and/or parallel deployments.

   GSMPv3 is an ideal fit for implementing ANCP.  It is extensible and
   can be run over TCP/IP, which makes it possible to run over different
   access technologies.

4.2.  ANCP based Access Topology Discovery

4.2.1.   Goals

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

   Following section describes ANCP messages that allow the Access Node
   (e.g.  DSLAM) to communicate to the NAS, access network topology
   information and any corresponding updates.

   Some of the parameters that can be communicated from the DSLAM to the
   NAS include DSL line state, actual upstream and downstream net data
   rates of a synchronized DSL link, maximum attainable upstream and
   downstream net data rates, interleaving delay etc.  Topology
   discovery is specifically important in case the net data rate of the
   DSL line changes over time.  The DSL net data rate may be different
   every time the DSL modem is turned on.  Additionally, during the time
   the DSL modem is active, data rate changes can occur due to
   environmental conditions (the DSL line can get "out of sync" and can
   retrain to a lower value).

4.2.2.  Message Flow

   When a DSL line initially comes up or resynchronizes to a different
   rate, the DSLAM generates and transmits a GSMP PORT UP EVENT message
   to the NAS.  The extension field in the message carries the TLVs
   containing DSL line specific parameters.  On a loss of signal on the
   DSL line, a GSMP PORT DOWN message is generated by the DSLAM to the
   NAS.  In order to provide expected service level, NAS needs to learn
   the initial attributes of the DSL line before the subscriber can log
   in and access the provisioned services for the subscriber.  Figure 2
   summarizes the interaction.

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

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

            <----- Port UP (EVENT Message)  <----- DSL
                  (updated line parameters)      Resynch
   2.  NAS ------------------ Access ----------- Home ------ Subscriber
                               Node             Gateway

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

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

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

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

4.3.  ANCP based Line Configuration

4.3.1.   Goals

   Following dynamic discovery of access topology (identification of DSL
   line and its attributes) as assisted by the mechanism described in
   the previous section (topology discovery), the NAS could then query a
   subscriber management OSS system (e.g.  RADIUS server) to retrieve
   subscriber authorization data (service profiles, aka user
   entitlement).  Most of such service mechanisms are typically enforced
   by the NAS itself, but there are a few cases where it might be useful
   to push such service parameter to the DSLAM for local enforcement of
   a mechanism (e.g.  DSL-related) on the corresponding subscriber line.
   One such example of a service parameter that can be pushed to the
   DSLAM for local enforcement is DSL "interleaving delay".  Longer
   interleaving delay (and hence stringent error correction) is required
   for a video service to ensure better video "quality of experience",
   whereas for a VoIP service or for "shoot first" gaming service, a
   very short interleaving delay is more appropriate.  Another relevant
   application is downloading per subscriber multicast channel
   entitlement information in IPTV applications where the DSLAM is
   performing IGMP snooping or IGMP proxy function.  Using ANCP, the NAS
   could achieve the goal of pushing line configuration to the DSLAM by
   an interoperable and standardized protocol.

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

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

4.3.2.  Message Flow

   Triggered by topology information reporting a new DSL line or
   triggered by a subsequent user session establishment (PPP or DHCP),
   the NAS may send line configuration information (e.g. reference to a
   DSL profile) to the DSLAM using GSMP Port Management messages.  The
   NAS may get such line configuration data from a policy server (e.g.
   RADIUS).  Figure 3 summarizes the interaction.

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

   Figure 3: Message flow - ANCP mapping for Initial Line Configuration

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

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

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

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

   The format of relevant extensions to port management message is
   defined in section Section 5.4.3.  The line configuration models
   could be viewed as a form of delegation of authorization from the NAS
   to the DSLAM.

4.4.  ANCP based Transactional Multicast

4.4.1.  Goals

   Typical IP multicast in access networks involves the NAS terminating
   user requests for receiving multicast channels via IGMP.  The NAS
   authorizes the subscriber, and dynamically determines the multicast
   subscription rights for the subscriber.  Based on the user's
   subscription, the NAS can replicate the same multicast stream to
   multiple subscribers.  This leads to a waste of access bandwidth if
   multiple subscribers access network services via the same access-node
   (e.g.  DSLAM).  The amount of multicast replication is of the order
   of number of subscribers rather than the number of access-nodes.  It
   is ideal for NAS to send a single copy of the multicast stream to a
   given access-node, and let the access-node perform multicast
   replication by layer2 means (e.g.  ATM point-to-multipoint cell
   replication or Ethernet data-link bridging) for subscribers behind
   the access-node.  However, operationally, NAS is the ideal choice to
   handle subscriber management functions (authentication,
   authorization, accounting and address management), multicast policies
   such as per-channel authorization, and complex multicast routing
   protocols.  Therefore, some means is needed for the NAS to setup
   multicast replication state in the access-nodes.  In ATM access
   networks, ANCP can be used by the NAS to setup P2MP cross-connects in
   the DSLAMs.  Protocol support for this use-case is defined in section
   Section 5.4.5

4.4.2.  Message Flow

   The Multicast Replication Control Message is sent by the NAS to the
   AN with a directive to either join or leave one or more multicast
   flows.  The AN will use a Multicast Status Message when conveying the
   outcome of the directive.  The message flows in Figure 5 illustrates
   the behavior of the AN in case of receiving a Multicast Replication
   Control Message.

   +----------+    +-------+     +-----+        ANCP          +-----+
   |Subscriber|    | Home  |     | AN  |<-------------------->| NAS |
   +----------+    |Gateway|     +-----+                      +-----+
         |         +-------+         |                           |
         |            |              | Multicast-Replication-Crl |
         |            |              |(Target,add, Flowi..Flowj) |
         |            |              |<--------------------------|
         |       Mcast Flow 1        |                           |
         |<==========================+                           |
         |            |              |     Multicast-Status      |
         |            |              |-------------------------->|
         |            |              |                           |
         |            |              | Multicast-Replication-Crl |
         |            |              |(Target,delete,Flowi.Flowj)|
         |            |              |<--------------------------|
         |            |              |                           |
         |  <Stop Replication of     X                           |
         |            Mcast Flow 1>  |     Multicast-Status      |
         |            |              |-------------------------->|

              Figure 5: NAS-Controlled Multicast Replication

4.5.  ANCP based OAM

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

   A simple solution based on ANCP can provide NAS with an access-line
   test capability and to some extent fault isolation.  Controlled by a
   local management interface the NAS can use an ANCP operation to
   trigger the access-node to perform a loopback test on the local-loop
   (between the access-node and the CPE).  The access-node can respond
   via another ANCP operation the result of the triggered loopback test.

   In case of ATM based local-loop the ANCP operation can trigger the
   access-node to generate ATM (F4/F5) loopback cells on the local loop.
   In case of Ethernet, the access-node can trigger an Ethernet loopback
   message(per EFM OAM) on the local-loop.

4.5.1.  Message Flow

   "Port Management" message can be used by the NAS to request access
   node to trigger a "remote loopback" test on the local loop.  The
   result of the loopback test can be asynchronously conveyed by the
   access node to the NAS in a "Port Management" response message.  The
   format of relevant extensions to port management message is defined
   in section The format of relevant extensions to port management
   message is defined in section Section 5.4.4.  Figure 6 summarizes the
   interaction.

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

                  Figure 6: Message Flow: ANCP based OAM

5.  Access Node Control Protocol (ANCP)

   ANCP uses a subset of GSMPv3 messages described in [RFC3292] to
   implement currently defined use-cases.  GSMPv3 general message
   format, used by all GSMP messages other than adjacency protocol
   messages, is defined in section 3.1.1 of GSMPv3 [RFC3292].  ANCP
   modifies this base GSMPv3 message format.  The modified GSMPv3
   message format is defined as follows:

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

                 Figure 7: Modified GSMPv3 message format

   The IETF Trust (2007) 42

        Intellectual Property 43

        Acknowledgment 43 8-bit version field in the base GSMPv3 message header is split
   into two 4 bit fields for carrying the version and a sub-version of
   the GSMP protocol.  ANCP uses version 3 and sub-version 1  Specification Requirements of the GSMP
   protocol.  An ANCP implementation SHOULD always set the version field
   to 3, and the sub-version field to 1.  The Result field in the
   message header has been modified to be 4 bits long, and the Code
   field to be 12 bits long.

   Version:

        The version number of the GSMP protocol being used in this
        session.  ANCP uses version 3.

   Sub-Version:

        The sub-version number of the GSMP protocol being used in this
        session.  ANCP uses sub-version 1 of the GSMP protocol.

   Result:

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

         Ignore:

            Res = 0x00 - Ignore this field on receipt and follow the
            procedures specified for the received message type.

         Nack:

            Res = 0x01 - Result code indicating that no response is
            expected to the message other than in cases of failure
            caused during the processing of the message contents or that
            of the contained directive(s).

         AckAll:

            Res = 0x02 - Result code indicating that a response to the
            message is requested in all cases.  It is specifically
            intended to be used in some cases for Request messages only,
            and is not to be used in Event messages.

         Success:

            Res = 0x03 - Set by receiver to indicate successful
            execution of all directives in the corresponding Request
            message.

         Failure:

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

   Message-Type:

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
        NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", GSMP and "OPTIONAL" ANCP message type.

   Code:

      This field gives further information concerning the result in
        this document are a
      response message.  It is mostly used to pass an error code in a
      failure response but can also be interpreted as described used to give further information
      in RFC 2119.

     2  Introduction

        DSL is a widely deployed access technology for Broadband Access for
        Next Generation Networks. Several specifications like [TR-059, TR-
        058, TR-092] describe possible architectures for these access
        networks. success response message or an event message.  In a request
      message, the scope of these specifications are code field is not used and is set to zero.  In an
      adjacency protocol message, the delivery Code field is used to determine
      the function of
        voice, video the message.

   Partition ID:

      This field is a 8 bit number which signifies a partition on the
      AN. [ TBD How AN and data services.

        When deploying value-added services across DSL access networks,
        special attention regarding quality NAS agree on the partition numbers.  Possible
      options:

      1 - The partition ID could be configured on the AN and learnt by
      NAS in the adjacency message;

      2 - The partition ID could be statically configured on the NAS as
      part of configuring the neighbor information.]

   Transaction ID:

      24-bit field set by the sender of a Request message to associate a
      Response message with the original Request message.  The receiver
      of service and service control is
        required, which implies a tighter coordination between network
        elements Request message reflects the transaction ID from the Request
      message in the broadband access network without burdening corresponding Response message.  For event
      messages, the OSS
        layer.

        This draft defines extensions transaction identifier SHOULD be set to zero.  The
      Transaction Identifier is not used, and modifications the field is not present,
      in the adjacency protocol.  The specific use of transaction ID as
      applicable to GSMPv3 (specified multicast use case is defined in [RFC3292]) Section 5.4.5

   I flag:

      An ANCP implementation SHOULD set "I" and certain new mechanisms subMessage fields to realize a control plane
        between a service-oriented layer 3 edge device (the NAS) and a layer2
        Access Node (e.g. DSLAM) in order 1
      to perform QoS-related, service-
        related and subscriber-related operations. The control protocol as a
        result signify no fragmentation.

   Length:

      Length of these extensions the GSMP message including its header fields and mechanisms defined
      GSMP message body.

   Additional General Message Information:

   o  Any field in a GSMP message that is referred to unused or defined as "Access
        Node Control Protocol" (ANCP).

        ANCP uses
      "reserved" MUST be set to zero by the option of transporting GSMPv3 over TCP/IP. TCP
        encapsulation for GSMPv3 is defined in [RFC3293]. GSMPv3
        encapsulation directly over Ethernet sender and ATM as ignored by the
      receiver;

   o  Flags that are undefined will be designated as: x: reserved.

   Following are the relevant GSMPv3 messages defined in [RFC3293]
        is not considered for [RFC3292], that
   are currently used by ANCP.

        ANCP uses a subset of  Other than the message types explicitly
   listed below, no other GSMPv3 messages to implement currently defined
        use-cases. are used by ANCP currently.

   o  Event Messages

      *  Port UP Message

      *  Port DOWN Message

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

   o  Port Management Messages

      *  These relevant GSMPv3 messages are identified in section
        5. GSMPv3 procedures with suitable extensions, as used by ANCP, ANCP "line configuration" use-case
         and ANCP OAM use-case.

   o  Adjacency Protocol Messages

      *  These messages are
        described in sections 5.1, 5.2 used to bring up a protocol adjacency
         between a NAS and 5.3. GSMPv3 general extensions an AN.

   ANCP modifies and extends few basic GSMPv3 message specific procedures.  These
   modifications and extensions required by ANCP are summarized below, and described in
        sub-sections of 5.4. In addition to specifying extensions and
        modifications to relevant GSMP messages applicable to ANCP, this
        draft also defines the usage of these messages by ANCP. Not all the
        fields
   more detail in relevant GSMP messages are used by ANCP. This draft
        indicates the value that succeeding sections.

   o  ANCP should set provides support for the fields in these GSMP
        messages. However, to understand the basic semantics of various
        fields in GSMP messages, the reader is referred to [RFC3292].

     2.1 Terminology

        o Access Node (AN): Network device, usually located at a service
          provider central office or street cabinet that terminates access
          (local) loop connections from subscribers. In case the access loop
          is a Digital Subscriber Line (DSL), capability negotiation mechanism
      between ANCP peers by extending the Access Node provides DSL
          signal termination, and is referred to as DSL Access Multiplexer
          (DSLAM).

        o Network Access Server (NAS): Network element which aggregates
          subscriber traffic from a number of Access Nodes. The NAS is an
          injection point for policy management GSMPv3 adjacency protocol.
      This mechanism and IP QoS corresponding adjacency message extensions are
      defined in section Section 5.3

   o  TCP connection establishment procedure in ANCP deviates slightly
      from the access
          network. IT is also referred to connection establishment in GSMPv3 as Broadband Network Gateway (BNG)
          or Broadband Remote Access Server (BRAS). specified in
      [RFC3293].  This is described in section Section 5.1

   o Home Gateway (HGW): Network element that connects subscriber
          devices to the Access Node  ANCP makes GSMPv3 messages extensible and the access network. In case of DSL,
          the Home Gateway is a DSL network termination that could either
          operate as a layer 2 bridge or as a layer 3 router. In the latter
          case, such flexible by adding a device is also referred
      general "extension block" to as a Routing Gateway (RG).

        o Net Data Rate: portion of the total data rate end of the DSL line that
          can be used relevant GSMPv3
      messages.  The "extension block" contains a TLV structure to transmit actual user carry
      information (e.g. ATM cells of
          Ethernet frames). It excludes overhead that pertains relevant to the
          physical transmission mechanism (e.g. trellis coding in case each ANCP use-case.  The format of
          DSL). This the
      "extension block" is defined in section 3.39 of ITU-T G.993.2. Section 5.4.1.1.

   o DSL line (synch) rate: the total data rate of the DSL line,
          including the overhead attributable to

5.1.  ANCP/TCP connection establishment

   ANCP will use TCP for exchanging protocol messages [RFC3293]. defines
   the physical transmission
          mechanism.

        o DSL multi-pair bonding: method GSMP message encapsulation 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 TCP.  The TCP session is initiated
   from the DSLAM (access node) to combine the data rates NAS (controller).  This is
   necessary to avoid static provisioning on two or more copper pairs, and deliver the aggregate data rate NAS for all the DSLAMs
   that are being served by the NAS.  It is easier to configure a given
   DSLAM with the single customer.  ITU-T recommendations G.998.1 and G.998.2
          respectively describe ATM and Ethernet based multi-pair bonding.

     3  Broadband Access Aggregation

     3.1 ATM-based broadband aggregation

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

        The Regional/Access Network consists IP address of the Regional Network, Network
        Access Server, and NAS that serves the Access Network as show in Fig 1. Its primary
        function DSLAM.
   This is a deviation from [RFC3293] which indicates that the
   controller initiates the TCP connection to the switch.

   When GSMP messages are sent over a TCP connection a four-byte TLV
   header field is prepended to provide end-to-end transport between the customer
        premises and GSMP message to provide delineation
   of GSMP messages within the NSP or ASP. The Access Node terminates TCP stream.

       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 (0x88-0C)         |           Length              |
      |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                         GSMP Message                          ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 8: GSMPv3 with TCP/IP Encapsulation message format

   Type

        This 2-byte field indicates the DSL
        signal. It could consist type code of DSLAM in the central office, or remote
        DSLAM, or a Remote Access Multiplexer (RAM). Access node following
        message.  The type code for GSMP messages is 0x88-0C (i.e., the first
        point in
        same as GSMP's Ethertype).

   Length

        This 2-byte unsigned integer indicates the network where traffic on multiple DSL lines will be
        aggregated onto a single network.

        The total length of the
        GSMP message only.  It does not include the 4-byte TLV header.

   NAS performs multiple functions in listens for incoming connections from the access nodes.  Port
   6068 is used for TCP connection.  Adjacency protocol messages, which
   are used to synchronize the network. The NAS and access-nodes and maintain
   handshakes, are sent after the TCP connection is established.  ANCP
   messages other than adjacency protocol messages may be sent only
   after the
        aggregation point for adjacency protocol has achieved synchronization.

   In the subscriber traffic. It provides aggregation
        capabilities (e.g. IP, PPP, ATM) case of ATM access, a separate PVC (control channel) capable
   of transporting IP would be configured between the Regional/Access Network NAS and the NSP or ASP. These include traditional ATM-based offerings and
        newer, more native IP-based services. This includes support DSLAM for
        Point-to-Point
   ANCP messages.

   In case of an Ethernet access/aggregation network, a typical practice
   is to send the Access Node Control Protocol messages over ATM (PPPoA) and PPP over a dedicated
   Ethernet
        (PPPoE), as well as direct IP services encapsulated over Virtual LAN (VLAN) using a separate VLAN identifier (VLAN
   ID).

5.2.  ANCP Connection keep-alive

   GSMPv3 defines an
        appropriate layer 2 transport.

        Beyond aggregation, NAS adjacency protocol.  The adjacency protocol is also used
   to synchronize states across the injection point for policy
        management and IP QoS in link, to negotiate which version of
   the Regional/Access Networks. In order GSMP protocol to
        allow IP QoS support over an existing non-IP-aware layer 2 access
        network without using multiple layer 2 QoS classes, use, to discover the identity of the entity at
   the other end of a mechanism based
        on hierarchical scheduling link, and to detect when it changes.  GSMP is used. This mechanism defined in [TR-
        059], preserves IP QoS over the ATM network a
   hard state protocol.  It is therefore important to detect loss of
   contact between the NAS switch and controller, and to detect any change of
   identity of switch or controller.  No protocol messages other than
   those of the
        RGs by carefully controlling downstream traffic in adjacency protocol may be sent across the NAS, so that
        significant queuing and congestion does not occur further down link until the
        ATM network. This is
   adjacency protocol has achieved by using a diffserv-aware hierarchical
        scheduler in synchronization.  There are no
   changes to the base GSMP adjacency protocol for implementing ANCP.

   The NAS that will account for downstream trunk
        bandwidths and DSL synch rates.
        [ANCP-FRAMEWORK] provides detailed definition and functions of each
        network element set the M-flag in the broadband reference architecture.

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

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

                       Fig.1  ATM Broadband Aggregation Topology

     3.2 Ethernet-based broadband aggregation SYN message (signifying it is the
   master).  Once the adjacency is established, periodic adjacency
   messages (type ACK) are exchanged.  The Ethernet aggregation network architecture builds on the Ethernet
     bridging/switching concepts defined default ACK interval as
   advertised in IEEE 802. The Ethernet
     aggregation network provides traffic aggregation, class of service
     distinction, and customer separation the adjacency messages is 10 sec for ANCP.  It SHOULD
   be configurable and traceability. VLAN tagging is an implementation choice.  It is recommended
   that both ends specify the same timer value.  However, it is not
   necessary for the timer values to match.

   The GSMP adjacency message defined in IEEE 802.1Q [RFC3292] is extended for ANCP
   and being enhanced by IEEE 802.1ad is used as
     standard virtualization mechanism shown in the Ethernet aggregation network. section 5.3 immediately following this section.  The aggregation devices are "provider edge bridges" defined
   8-bit "version" field in IEEE
     802.ad.
     Stacked VLAN tags provide one possible way the adjacency protocol messages is modified
   to create equivalent carry the version and sub-version of
     "virtual paths" the GSMP protocol for version
   negotiation.  ANCP uses version 3 and "virtual circuits" sub-version 1 of GSMP protocol.
   The semantics and suggested values for Code, "Sender Name", "Receiver
   Name", "Sender Instance", and "Receiver Instance" fields are as
   defined in the aggregation network. [RFC3292].  The
     "outer" vlan could "Sender Port", and "Receiver Port" should
   be used set to create a form of "virtual path" between a
     given DSLAM and a given NAS. And "inner" VLAN tags 0 by both ends.  The pType field should be set to create a form of
     "virtual circuit" 0.  The
   pFlag should be set to 1.

   If the adjacency times out on a per DSL line basis. This is 1:1 VLAN allocation
     model. An alternative model is either end, due to bridge sessions from multiple
     subscribers behind a DSLAM into not receiving an
   adjacency message for a single VLAN in duration of (3 * Timer value), where the aggregation
     network. This
   timer value is N:1 VLAN allocation model. Architectural and
     topological models of an Ethernet aggregation network in context of DSL
     aggregation are defined in [TR101].

     4  Access Node Control Protocol

     4.1 Overview

        A dedicated control protocol between NAS and access nodes can
        facilitate "NAS managed" tight QOS control specified in the access network,
        simplified OSS infrastructure for service management, optimized
        multicast replication to enable video services over DSL, subscriber
        statistics retrieval on adjacency message, all the NAS for accounting purposes, state
   received from the ANCP neighbor should be cleaned up, and fault
        isolation capability on the TCP
   connection should be closed.  The NAS would continue to listen for the underlying access technology.
        This dedicated control plane is referred
   new connection requests.  The DSLAM will try to as "Access Node Control
        Protocol" (ANCP). This document specifies relevant extensions re-establish the TCP
   connection and both sides will attempt to
        GSMPv3 re-establish the adjacency.

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

5.3.  Capability negotiation

   The adjacency message as defined in [RFC3292] is extended to realize ANCP.

        Following sections discuss carry
   technology specific "Capability TLVs".  Both the use NAS and the access
   node will advertise supported capabilities in the originated
   adjacency messages.  If a received adjacency message indicates
   absence of ANCP support for implementing:

          . Dynamic discovery of access topology a capability that is supported by the NAS
   receiving device, it will turn off the capability locally and will
   send an updated adjacency message with the capability turned off to provide tight
             QOS control
   match the received capability set.  This process will eventually
   result in both sides agreeing on the access network.

          . Pushing to minimal set of supported
   capabilities.  The adjacency will not come up unless the access-nodes, subscriber and service data
             retrieved capabilities
   advertised by the NAS from an OSS system (e.g. radius server), to
             simplify OSS infrastructure for service management.

          . Optimized, "NAS controlled controller and managed" multicast replication by
             access-nodes the controlled device match.

   After initial synchronization, if at L2 layer.

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

        In addition to DSL, alternate broadband access technologies (e.g.
        Metro-Ethernet, Passive Optical Networking, WiMax) mismatch is
   detected, the adjacency will have similar
        challenges to address, and could benefit from be brought down (RSTACK will be
   generated by the same approach device detecting the mismatch), and synchronization
   will be re-attempted.

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

                                 Figure 9

   The format of a
        control plane between a NAS and an Access Node (e.g. OLT), providing
        a unified control and management architecture for multiple access
        technologies, hence facilitating migration from one capability TLV is:

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

                         Figure 10: Capability TLV

   The Tech Type field type indicates the technology to which the other
        and/or parallel deployments.

        GSMPv3
   capability extension applies.  For access node control in case of DSL
   networks, new type "DSL" is an ideal fit proposed.  The value for implementing ANCP. It this field is extensible and
        can be run over TCP/IP, which makes it possible to run over different
        access technologies.

     4.2 ANCP based Access Topology Discovery

     4.2.1 Goals

        [TR-059] discusses various queuing/scheduling mechanisms to avoid
        congestion
   0x05.  This is the first available value in the access network while dealing with multiple flows
        with distinct QoS requirements. Such mechanisms require range that is not
   currently allocated.  It will need to be reserved with IANA.

   Capability length is the NAS
        gains knowledge about number of actual bytes contained in the topology
   value portion of the access network, TLV.  The TLV is padded to a 4-octet alignment.
   Therefore, a TLV with no data will contain a zero in the various
        links being used and their respective net length field
   (if capability data rates. Some is three octets, the length field will contain a
   three, but the size of the
        information required actual TLV is somewhat dynamic in nature (e.g. DSL sync
        rate, and therefore also eight octets).  Capability
   data field can be empty if the net data rate), hence cannot come from capability is just a
        provisioning and/or inventory management OSS system. Some of boolean.  In case
   the
        information varies less frequently (e.g. capacity of capability is a DSLAM uplink),
        but nevertheless needs to be kept strictly in sync between boolean, it is inferred from the actual
        capacity presence of the uplink and the image
   TLV (with no data).

   Capability data provides the NAS has flexibility to advertise more than mere
   presence or absence of it. a capability.  Capability types can be
   registered with IANA.  Following section describes capabilities are defined for ANCP as
   applied to DSL access:

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

          Length (in bytes) : 0

          Capability Data : NULL

   2.  Capability Type : Line-Configuration = 0x02

          Length (in bytes) : 0

          Capability Data : NULL

   3.  Capability Type : Transactional-Multicast = 0x03 (controller i.e.
       NAS terminates IGMP messages from subscribers, and via l2 control
       protocol, signals state to the access-nodes (e.g.  DSLAMs) to
       enable layer2 replication of multicast streams.  In ATM access
       network this implies that allow NAS instructs the access-node to setup
       a P2MP cross-connect.  The details of this will be covered in a
       separate ID.

          Length (in bytes) : 0

          Capability Data : NULL

   4.  Capability Type : OAM = 0x04

          Length (in bytes) : 0

          Capability Data : NULL

5.4.  GSMP Message Extensions for Access Node
        (e.g. DSLAM) Control

5.4.1.  General Extensions

   Extensions to communicate GSMP messages for various use-cases of "Access Node
   Control" mechanism are defined in sections Section 5.4.2 to
   Section 5.4.5.  However, sub-sections Section 5.4.1.1 below define
   extensions to GSMP that have general applicability.

5.4.1.1.  Extension TLV

   In order to the NAS, access network topology
        information provide flexibility and any corresponding updates.

        Some of the parameters that can be communicated from the DSLAM extensibility certain GSMP
   messages such as "PORT MANAGEMENT" and "EVENT" messages defined in
   [RFC3292] have been modified to the
        NAS include DSL line state, actual upstream and downstream net data
        rates of an extension block that
   follows a synchronized DSL link, maximum attainable upstream and
        downstream net data rates, interleaving delay etc. Topology discovery
        is specifically important TLV structure.  Individual messages in case the net data rate following
   sections describe the usage and format of the DSL line
        changes over time. The DSL net data rate may extension block.

   All Extension TLVs will be different every time
        the DSL modem is turned on. Additionally, during the time the DSL
        modem is active, data rate changes can occur due to environmental
        conditions (the DSL line can get "out of sync" and can retrain to a
        lower value).

     4.2.2 designated as follow:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |x|x|x|x|x|x|x|x| Message Flow

     When a DSL line initially comes up or resynchronizes to a different
     rate, the DSLAM generates Type  |   Tech Type   | Block Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                         Extension Value                       ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 11: Extension TLV

      x: Reserved Flags
         These are generally used by specific messages and transmits a GSMP PORT UP EVENT message will be
         defined in those messages.

      Message Type

         An 8-bit field corresponding to the NAS. The message type where the
         extension block is used.

      Tech Type

         An 8-bit field in indicating the message carries applicable technology type value.
         The Message Type plus the TLVs containing
     DSL line specific parameters. On Tech Value uniquely define a loss single
         Extension Type and can be treated as a single 16 bit extension
         type.  "Tech Type" value of signal on the 0x05 SHOULD be used by ANCP for DSL line, a
     GSMP PORT DOWN message is generated
         technology.

            0x00 Extension block not it use.

            0x01 - 0x04 Already in use by various technologies

            0x05 DSL

            0x06 - 0xFE Reserved

            0xFF Base Specification Use

      Block Length

         A 8-bit field indicating the DSLAM to length of the NAS. In order to
     provide expected service level, NAS needs to learn Extension Value
         field in bytes.  When the initial
     attributes Tech Type = 0x00, the length value
         MUST be set to 0.

      Extension Value

         A variable length field that is an integer number of 32 bit
         words long.  The Extension Value field is interpreted according
         to the DSL line before specific definitions provided by the subscriber can log messages in and access
     the provisioned services for the subscriber.

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

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

                 <----- Port UP (EVENT Message)  <----- DSL
                       (updated line parameters)       Resynch
         2.  NAS ----------------------- Access ----------- Home ------ Subscriber
                                    Node          Gateway

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

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

                Fig 2. Message flow (ANCP mapping) for topology discovery
         following sections..

5.4.2.  Topology Discovery Extensions

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

     4.3 ANCP based Line Configuration

     4.3.1 Goals

        Following dynamic discovery of access topology (identification of DSL
        line and its attributes) as assisted by the mechanism described in
        the previous section (topology discovery), the NAS could then query a
        subscriber management OSS system (e.g. RADIUS server) to retrieve
        subscriber authorization data (service profiles, aka user
        entitlement). Most of such service mechanisms are typically enforced
        by the NAS itself, but there are a few cases where it might be useful
        to push such service parameter to the DSLAM for local enforcement of
        a mechanism (e.g. DSL-related) on the corresponding subscriber line.
        One such example of a service parameter that can SHOULD be pushed to the
        DSLAM for local enforcement is DSL "interleaving delay". Longer
        interleaving delay (and hence stringent error correction) is required
        for a video service to ensure better video "quality of experience",
        whereas for a VoIP service or for "shoot first" gaming service, a
        very short interleaving delay is more appropriate. Another relevant
        application is downloading per subscriber multicast channel
        entitlement information in IPTV applications where the DSLAM is
        performing IGMP snooping or IGMP proxy function. Using ANCP, the NAS
        could achieve the goal of pushing line configuration to the DSLAM by
        an interoperable and standardized protocol.

        If a subscriber wants to choose a different service, it can require
        an OPEX intensive reconfiguration of the line via a network operator,
        possibly implying a business-to-business transaction between an ISP
        and an access provider. Using ANCP for
   generated when a line configuration from first comes UP, or any of the
        NAS dramatically simplifies attributes of the OSS infrastructure for service
        management, allowing fully centralized subscriber-related service
        data (e.g. RADIUS server back-end) and avoiding complex cross-
        organization B2B interactions.

        The best way to
   line change e.g. the line parameters would be by using profiles.
        These profiles (DSL profiles for re-trains to a different services) are pre- rate or one or
   more of the configured on line attributes are administratively modified.

   Also, when the DSLAMs. The NAS can then indicate ANCP session first comes up, the DSLAM SHOULD transmit
   a reference PORT UP message to the right DSL profile via ANCP. Alternatively, discrete DSL
        parameters can also be conveyed by the NAS in ANCP.

     4.3.2 Message Flow

     Triggered by topology information reporting for each line that is up.  When a new DSL
   line goes down (idle or triggered
     by a subsequent user session establishment (PPP or DHCP), silent), the NAS may
     send line configuration information (e.g. reference DSLAM SHOULD transmit an Event
   message with PORT DOWN message type (81) to the NAS.  It is
   recommended that the DSLAMs use a dampening mechanism per DSL profile) to
     the DSLAM using GSMP Port Management messages. The NAS may get such line
     configuration data from a policy server (e.g. RADIUS). Figure 3
     summarizes to
   control the rate of state changes per DSL line, communicated to the
   NAS.

   Not all the fields in GSMP Event message are applicable to ANCP.  The
   fields that are not applicable MUST be set to zero by the interaction.

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

        Fig 3. Message flow - ANCP mapping for Initial Line Configuration sender
   and ignored by the ANCP receiver.  The NAS may update fields in the line configuration due PORT UP and PORT
   DOWN messages to a subscriber service
     change (e.g. triggered be set by the policy server). Figure 4 summarizes ANCP sender, and corresponding
   handling by the
     interaction.

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

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

                    Fig 4. Message flow - ANCP mapping for Updated Line Configuration receiver is described below.

   The format of relevant extensions version field MUST be set to port management message is 3, and the sub field MUST be set to
   1.  As defined in section 5.4.3. [RFC3292], the one byte Message Type field MUST be
   set to 80 for PORT UP Event message, and to 81 for PORT DOWN Event
   Message.  The line configuration models could 8 bit Code field MUST be
        viewed as a form of delegation of authorization from the NAS set to 0.  The 4 bit Result
   field MUST be set to 0 (signifying Ignore.)  If a PORT UP message
   with a Result field set to 0 is received by the
        DSLAM.

     4.4 ANCP based Transactional Multicast

        Typical IP multicast in access networks involves the NAS terminating
        user requests for receiving multicast channels via IGMP. The NAS
        authorizes the subscriber, and dynamically determines the multicast
        subscription rights for the subscriber. Based on the user's
        subscription, the NAS can replicate the same multicast stream to
        multiple subscribers. This leads to a waste of access bandwidth if
        multiple subscribers access network services via the same access-node
        (e.g. DSLAM). The amount of multicast replication is of
   able to process the order of
        number of subscribers rather than message correctly, the number of access-nodes.

        It is ideal for NAS MUST NOT generate any
   ANCP message in response to send a single copy of the multicast stream to
        a given access-node, and let PORT UP.  If the access-node perform multicast
        replication PORT UP message
   received cannot be processed correctly by layer2 means (e.g. ATM point-to-multipoint cell
        replication or Ethernet data-link bridging) for subscribers behind the access-node. However, operationally, NAS is (e.g. the ideal choice to
        handle subscriber management functions (authentication,
        authorization, accounting and address management), multicast policies
        such as per-channel authorization, and complex multicast routing
        protocols. Therefore, some means message
   is needed for malformed) the NAS to setup
        multicast replication state in the access-nodes. In ATM access
        networks, MAY respond with an ANCP can be used by Error Message (TBD)
   containing the NAS reason of the failure.  The 24-bit Transaction
   Identifier field MUST be set to setup P2MP cross-connects in 0.  The "I" bit and the DSLAMs. Protocol support for this use-case will SubMessage
   field MUST be provided in
        future.

     4.5 ANCP based OAM

        In a mixed Ethernet set to 1 to signify no fragmentation.  The Length field
   is two bytes and ATM access network (including MUST contain the length of the local
        loop), it is desirable to provide similar mechanisms for connectivity
        checks message (including
   header and fault isolation, as those used the payload) in an ATM based
        architecture. This can be achieved using an ANCP based mechanism
        until end-to-end Ethernet OAM mechanisms bytes.

   The "Port" field, "Port Session Number" field and "Event Sequence
   Number" field are more widely implemented
        in various network elements.

        A simple solution based on ANCP can provide NAS with an access-line
        test capability 4 bytes each, and MUST be set to some extent fault isolation. Controlled 0 by a
        local management interface the NAS can ANCP
   sender.  LABEL field in event messages is defined as a TLV in
   [RFC3292].  ANCP does NOT use the Label TLV.  In both PORT UP and
   PORT DOWN event messages an ANCP operation to
        trigger the access-node to perform a loopback test on sender MUST treat the local-loop
        (between Label field,
   immediately following the access-node "Event Sequence Number" field, as a fixed 8
   byte field, and the CPE). MUST set these 8 bytes to 0.  The access-node can respond
        via another ANCP operation receiver MUST NOT
   interpret the result of LABEL field as a TLV and MUST ignore the triggered loopback test. 8 bytes
   immediately following the "Event Sequence Number" field.  In case future
   versions of ATM based local-loop ANCP, if necessary, the un-used fields in GSMP Event
   message, which do not have ANCP operation specific semantics, can trigger the
        access-node to generate ATM (F4/F5) loopback cells on the local loop. be used
   partially or completely, by re-naming appropriately, and associating
   valid semantics with these fields.

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

   In case of Ethernet, the access-node can trigger an Ethernet loopback
        message(per EFM OAM) on bonded copper loops to the local-loop.

     4.5.1 Message Flow

        "Port Management" message can be used customer premise (as per DSL
   multi-pair bonding described by [G.988.1] and [G.988.2]), the NAS to request access
        node DSLAM
   MUST report the aggregate net data rate and other attributes for the
   "DSL bonded circuit" (represented as a single logical port) to trigger the
   NAS in a "remote loopback" test on PORT UP message.  Any change in the local loop. The
        result aggregate net data rate
   of the loopback test can "DSL bonded circuit" (due to a change in net data rate of
   individual constituent DSL lines or due to change in state of the
   individual constituent DSL lines) MUST be asynchronously conveyed reported by the
        access node DSLAM to
   the NAS in a "Port Management" response PORT UP message.  The
        format of relevant extensions to port management message is defined
        in section 5.4.4.

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

     5  Access Node Control Protocol (ANCP)

        ANCP uses a subset MUST also report the
   "aggregate" state of GSMPv3 messages described in [RFC3292] the "DSL bonded circuit" to
        implement currently defined use-cases. GSMPv3 general message format,
        used by all GSMP messages other than adjacency protocol messages, is
        defined in section 3.1.1 of GSMPv3 RFC [RFC3292]. ANCP modifies this
        base GSMPv3 message format. The modified GSMPv3 message format is
        defined as follows: the NAS via PORT UP
   and PORT DOWN messages.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vers  |  Sub  | Message Type  | Result|        Code           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Partition ID  |            Transaction Identifier             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|      SubMessage Number      |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Port                              |
           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Port Session Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Event Sequence Number                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                             Label                             +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |x|x|x|x|x|x|x|x| Message Payload Type  |   Tech Type   | Block Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                         Extension Value                       ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 12

   The 8-bit version field in format of the base GSMPv3 message header "Extension Value" field for Tech Type "DSL" is split
        into two as
   follows :

        0 1 2 3 4 bit fields for carrying the version and 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     # of TLVs               | Extension Block length (bytes)  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                            TLVs                               ~
       ~                                                               ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 13: Extension Value

   The "Extension Value" contains one or more TLVs to identify a sub-version DSL
   line and define its characteristics.  A TLV can consist of multiple
   sub-TLVs.  First 2 byte of the GSMP protocol. ANCP uses version 3 and sub-version 1 "Extension Value" contains the number
   of TLVs that follow.  The next 2 bytes contain the GSMP
        protocol. An ANCP implementation SHOULD always set total length of
   the version TLVs carried in the extension block in bytes (existing "Block
   Length" field in the GSMP message is limited to 3, 255 bytes and the sub-version is not
   sufficient).

   General format of a TLV is :

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

                          Figure 14:  General TLV

   The value field in each TLV is padded to 1. a 4-octet alignment.  The Result
   Length field in each TLV contains the message
        header has been modified to be 4 bits long, and the Code field to be
        12 bits long. The definition and semantics actual number of all the fields bytes in the
        header are described in section 3.1.1 of GSMPv3 RFC [RFC3292]. An
        ANCP implementation SHOULD set "I" and subMessage fields to 1 to
        signify no fragmentation.

        Following are
   TLV (not including the relevant GSMPv3 messages defined in [RFC3292], that
        are currently used padding if present).  If a TLV is not
   understood by ANCP. Other than the message NAS, it is silently ignored.  Currently defined
   types explicitly
        listed below, no other GSMPv3 messages are used by ANCP currently.

       o Event Messages

           o Port UP message

           o Port DOWN message

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

       o Port Management Messages

           These messages are used by ANCP "line configuration" use-case and
           ANCP OAM use-case.

       o Adjacency Protocol Messages

           These messages start from 0x01.

   Following TLVs are used to bring up a protocol adjacency between currently defined:

   1.  Type (Access-Loop-Circuit-ID = 0x01): This is a
           NAS mandatory TLV and
       contains an AN.

        The basic format and semantics identifier of various fields in these GSMPv3
        messages identified above are described in GSMPv3 RFC [RFC3292].
        However, the subscriber's connection to the
       access node (i.e. "local loop").  The "local loop" can be ATM
       based or Ethernet based.  The "Access Loop Circuit ID" has local
       significance at the access node.  The exact usage of these messages by ANCP, along with relevant
        modifications and extensions required by ANCP, are described in
        sections 5.3, 5.4.1, 5.4.2 and 5.4.3 on the NAS is
       beyond the scope of this document. Messages  The format used
        by ANCP multicast use-case will be described in future versions of
        this document.

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

           o ANCP provides support for a capability negotiation mechanism
              between "local
       loop" identification in ANCP peers messages MUST be identical to what
       is used by extending the GSMPv3 adjacency protocol.
              This mechanism and corresponding adjacency message extensions
              are defined in section 5.3.

           o TCP connection establishment procedure access nodes in ANCP deviates
              slightly from subscriber signaling messages when
       the connection establishment in GSMPv3 access nodes act as
              specified in [RFC3293]. This is described "signaling relay agents" as outlined in section 5.1.

           o ANCP makes GSMPv3 messages extensible
       [RFC3046] and flexible by adding a
              general "extension block" [TR-101].

          Length : (up to 63 bytes)

          Value : ASCII string

          For an ATM based local loop the end string consists of the relevant GSMPv3
              messages. The "extension block" contains a TLV structure to
              carry slot/port
          and VPI/VCI information relevant corresponding to each ANCP use-case. The format of the "extension block" is defined in section 5.4.1.1.

     5.1 ANCP/TCP connection establishment

        ANCP will use TCP subscriber's DSL
          connection.  Default syntax for exchanging protocol messages. [RFC3293] defines the GSMP message encapsulation for TCP. string inserted by the
          access node as per [TR-101] is:

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

          The Access-Node-Identifier uniquely identifies the access node
          in the access network.  The TCP   session is
        initiated from slot/port and VPI/VCI uniquely
          identifies the DSLAM (access node) DSL line on the access node.  Also, there is
          one to one correspondence between DSL line and the NAS (controller). This VC between
          the access node and the NAS.

          For local loop which is necessary Ethernet based (and tagged), the
          string consists of slot/port and VLAN tag corresponding to avoid static provisioning on the NAS
          subscriber.  Default syntax for all the
        DSLAMs that are being served string inserted by the NAS. It
          access node as per [TR-101] is:

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

   2.  Type (Access-Loop-Remote-Id = 0x02): This is easier an optional TLV and
       contains an identifier to configure uniquely identify a
        given DSLAM with user on a local
       loop on the single IP address of access node.  The exact usage on the NAS that serves the
        DSLAM. This is a deviation from [RFC3293] which indicates out of
       scope of this document.  It is desirable that the
        controller initiates format used for
       the TCP connection field is similar to what is used by the switch.

        NAS listens for incoming connections from access nodes in
       subscriber signaling messages when the access nodes. Port 6068
        is used for TCP connection. Adjacency protocol messages, which are
        used nodes act as
       "signaling relay agents" as outlined in [RFC3046] and [TR-101].

          Length : (up to 63 bytes)

          Value : ASCII string

   3.  Type (Access-Aggregation-Circuit-ID-Binary = 0x06)

          Length : (8 bytes)
          Value : two 32 bit integers

          For ethernet access aggregation, where a per-subscriber
          (stacked) VLAN can be applied (1:1 model defined in [TR-101]),
          the VLAN stack provides a convenient way to uniquely identify
          the DSL line.  The outer VLAN is equivalent to synchronize virtual path
          between a DSLAM and the NAS and access-nodes inner VLAN is equivalent to a
          virtual circuit on a per DSL line basis.  In this scenario,
          any subscriber data received by the access node and maintain handshakes,
        are sent after
          transmitted out the TCP connection is established. ANCP messages other
        than adjacency protocol messages may uplink to the aggregation network will be sent only after
          tagged with the adjacency
        protocol has achieved synchronization.

        In VLAN stack assigned by the case of ATM access, a separate PVC (control channel) capable
        of transporting IP would be configured between NAS and access node

          This TLV can carry the VLAN tags assigned by the access node
          in the DSLAM for ANCP messages.

     5.2 ANCP Connection keep-alive

        GSMPv3 defines an adjacency protocol.  The adjacency protocol is used
        to synchronize states across the link, to negotiate which version of VLAN tags can uniquely identify the GSMP protocol to use,
          DSL line being referred to discover in the identity of ANCP messages, assuming the entity at
          VLAN tags are not in any way translated in the other end of a link, aggregation
          network and to detect when it changes. GSMP is are unique across physical ports.  Each 32 bit
          integer (least significant bits) contains a
        hard state protocol. It 12 bit VLAN
          identifier (which is therefore important to detect loss of
        contact between switch and controller, and to detect any change of
        identity part of switch or controller. No protocol messages other than
        those the VLAN tag defined by IEEE
          802.1Q).

          Also, in case of an ATM aggregation network, where the DSLAM
          is directly connected to the NAS (without an intermediate ATM
          switch), the adjacency protocol may be sent across two values can contain VPI and VCI on the link until DSLAM
          uplink (and can uniquely identify the
        adjacency protocol has achieved synchronization. There are no changes DSL line on the DSLAM).

          This is optional.

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

          Length : (up to 63 bytes)

          Value : ASCII string

          This field contains information pertaining to an uplink on the base GSMP adjacency protocol
          access node.  For Ethernet access aggregation, assuming the
          access node assigns VLAN tags (1:1 model), typical format for implementing ANCP.
          the string is:

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

          The NAS will set slot/port corresponds to the M-flag in ethernet uplink on the SYN message (signifying it is access
          node towards the
        master). Once NAS.

          For an ATM aggregation network, typical format for the adjacency is established, periodic adjacency
        messages (type ACK) are exchanged. The default ACK interval as
        advertised string
          is:

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

          This TLV allows the NAS to associate the information contained
          in the adjacency ANCP messages is 10 sec for ANCP. It SHOULD be
        configurable and is an implementation choice. It is recommended that
        both ends specify to the same timer value. However, it is not necessary
        for DSL line on the timer values to match.

        The GSMP adjacency message defined access node.

          If the access node inserts this string in [RFC3292] is extended for the ANCP
        and is shown messages,
          when referring to local loop characteristics (e.g.  DSL line
          in section 5.3 immediately following this section. The
        8-bit "version" field case of a DSLAM), then it should be able to map the
          information contained in the adjacency protocol messages is modified string uniquely to carry the version and sub-version of local loop
          (e.g.  DSL line).

          On the GSMP protocol for version
        negotiation. ANCP uses version 3 and sub-version 1 of GSMP protocol.
        The semantics and suggested values for Code, "Sender Name", "Receiver
        Name", "Sender Instance", and "Receiver Instance" fields are as
        defined NAS, the information contained in [RFC3292]. The "Sender Port", and "Receiver Port" should this string can be set
          used to 0 by both ends. The pType field should be set derive an "aggregation network" facing construct (e.g.
          an IP interface) corresponding to 0. the local loop (e.g.  DSL
          line).  The
        pFlag should association could be set to 1.

        If the adjacency times out based on either end, due "local
          configuration" on the NAS.

          The access node can also convey to not receiving an
        adjacency message for a duration the NAS, the
          characteristics (e.g. bandwidth) of (3 * Timer value), where the
        timer value is specified in uplink on the adjacency message, all access
          node.  This TLV then serves the state
        received from purpose of uniquely
          identifying the ANCP neighbor should uplink whose characteristics are being
          defined.  A separate set of sub-TLVs will be cleaned up, defined for the
          uplink characteristics (TBD).

          This TLV is optional.

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

          Length : variable (up to 1024 bytes)

          Value : This is a mandatory TLV and consists of one or more
          Sub-TLVs corresponding to DSL line attributes.  No sub-TLVs
          other than the TCP
        connection should "DSL type" and "DSL line state" SHOULD be closed. The NAS would continue to listen for new
        connection requests.
          included in a PORT DOWN message.

          The DSLAM will try to re-establish general format of the TCP
        connection and both sides will attempt sub-TLVs is identical to re-establish the adjacency. general
          TLV format.  The handling defined above will need some modifications when ANCP
        graceful restart procedures are defined. These procedures will be
        defined value field in each sub-TLV is padded to a separate draft.

     5.3 Capability negotiation
          4-octet alignment.  The adjacency message as defined Length field in [RFC3292] is extended to carry
        technology specific "Capability TLVs". Both the NAS and each sub-TLV contains
          the access
        node will advertise supported capabilities actual number of bytes in the originated
        adjacency messages. If a received adjacency message indicates absence TLV (not including the
          padding if present).  Current defined sub-TLV types are start
          from 0x81.

          Following sub-TLVs are currently defined :

          +  Type (DSL-Type = 0x91) : Defines the type of support for transmission
             system in use.  This is a capability that mandatory TLV.

                Length : (4 bytes)

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

          +  Type (Actual-Net-Data-Upstream = 0x81): Actual upstream net
             data rate on a DSL line.  This is supported by the receiving
        device, it will turn off the capability locally and will send an
        updated adjacency message with the capability turned off to match a mandatory TLV.

                Length : (4 bytes)

                Value : (Rate in Kb/sec)

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

                Length : (4 bytes)

                Value : (Rate in Kb/sec)

          +  Type (Minimum-Net-Data-Rate-Upstream = 0x83) : Minimum net
             data rate desired by the
        received capability set. operator.  This process will eventually result is optional.

                Length : (4 bytes)

                Value : (Rate in both
        sides agreeing on the minimal set of supported capabilities. The
        adjacency will not come up unless the capabilities advertised Kb/sec)

          +  Type (Minimum-Net-Data-Rate-Downstream = 0x84) : Minimum
             net data rate desired by the
        controller and the controlled device match.

        After initial synchronization, if at anytime a capability mismatch operator.  This is
        detected, the adjacency will be brought down (RSTACK will optional.

                Length : (4 bytes)

                Value : (Rate in Kb/sec)

          +  Type (Attainable-Net-Data-Rate-Upstream = 0x85) : Maximum
             net upstream rate that can be
        generated by the device detecting attained on the mismatch), and synchronization
        will be re-attempted.

            0                   1                   2                   3
            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |   Ver |  Sub  | Message Type  |     Timer     |M|     Code    |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                          Sender Name                          |
           +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                               |                               |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DSL line.
             This is an optional TLV.

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

          +
           |                         Receiver Name                         |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                          Sender Port                          |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                         Receiver Port                         |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           | PType | PFlag |               Sender Instance                 |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           | Partition ID  |              Receiver Instance                |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           | Tech  Type     | # of TLVs     | Total Length                  |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                                                               |
           ~                   Capability TLVs                             ~
           |                                                               |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         The format of capability TLV is:

           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |     Capability (Attainable-Net-Data-Rate-Downstream = 0x86) : Maximum
             net downstream rate that can be attained on the DSL line.
             This is an optional TLV.

                Length : (4 bytes)

                Value : (Rate in Kb/sec)

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

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

        The Tech : (4 bytes)

                Value : (Rate in Kb/sec)

          +  Type field type indicates (Maximum-Net-Data-Rate-Downstream = 0x88) : Maximum
             net data rate desired by the technology to which operator.  This is optional.

                Length : (4 bytes)

                Value : (Rate in Kb/sec)

          +  Type (Minimum-Net-Low-Power-Data-Rate-Upstream = 0x89) :
             Minimum net data rate desired by the
        capability extension applies. For access node control operator in case of DSL
        networks, new type "DSL" low power
             state.  This is proposed. The value for this field optional.

                Length : (4 bytes)

                Value : (Rate in Kb/sec)

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

                Length : (4 bytes)

                Value : (Rate in Kb/sec)

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

                Length : (4 bytes)
                Value : (Time in msec)

          +  Type (Actual-Interleaving-Delay-Upstream = 0x8C) : Value
             corresponding to the range that interleaver setting.  This is not
        currently allocated. It will need to be reserved with IANA.

        Capability length
             optional.

                Length : (4 bytes)

                Value : (Time in msec)

          +  Type (Maximum-Interleaving-Delay-Downstream = 0x8D) :
             maximum one way interleaving delay.  This is the number of actual bytes contained optional.

                Length : (4 bytes)

                Value : (Time in msec)

          +  Type (Actual-Interleaving-Delay-Downstream = 0x8E) : Value
             corresponding to the
        value portion of the TLV. The TLV interleaver setting.  This is padded to a 4-octet alignment.
        Therefore, a TLV with no data will contain a zero
             optional.

                Length : (4 bytes)

                Value : (Time in msec)

          +  Type (DSL line state = 0x8F) : The state of the length field
        (if capability data DSL line.
             For PORT UP message, at this time, the TLV is three octets, optional
             (since the length field will contain a
        three, but message type implicitly conveys the size state of the actual TLV is eight octets).

        Capability data field can be empty if the capability is just a
        boolean. In case
             line).  For PORT DOWN, the capability TLV is a boolean, mandatory, since it is inferred from
             further communicates the
        presence state of the TLV (with no data). Capability data provides the
        flexibility to advertise more than mere presence or absence of a
        capability. Capability types can be registered with IANA. Following
        capabilities are defined for ANCP line as applied to DSL access:

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

                Length (in bytes) : 0

             Capability Data : NULL

          2. Capability Type : Line-Configuration = 0x02

             Length (in (4 bytes)

                Value : 0

             Capability Data : NULL

          3. Capability Type : Transactional-Multicast { SHOWTIME = 0x01, IDLE = 0x02, SILENT = 0x03 (controller
             i.e. NAS terminates IGMP messages from subscribers, and via l2              control protocol, signals state to }

          +  Type (Access Loop Encapsulation = 0x90) : The data link
             protocol and, optionally the encapsulation overhead on the access-nodes (e.g.

             DSLAMs) to enable layer2 replication of multicast streams. In
             ATM
             access network loop.  This is an optional TLV.  However, when this implies that NAS instructs
             TLV is present, the access-
             node to setup a P2MP cross-connect. data link protocol MUST minimally be
             indicated.  The details of this will encapsulation overhead can be
             covered in a separate ID. optionally
             indicated.

                Length (in bytes) : 0

             Capability Data : NULL

          4. Capability Type : OAM = 0x04

             Length (in (3 bytes)
                Value : 0

             Capability Data : NULL

     5.4 GSMP Message Extensions for Access Node Control

     5.4.1 General Extensions

        Extensions The three bytes (most to GSMP messages for various use-cases least significant) and
                valid set of "Acess Node
        Control" mechanism values for each byte are defined in sections 5.4.2 to 5.4.4. However,
        sub-sections 5.4.1.1 and 5.4.1.2 below define extensions to GSMP that
        have general applicability.

     5.4.1.1  Extension TLV

        In order to provide flexibility and extensibility certain GSMP
        messages such as "PORT MANAGEMENT" and "EVENT" messages defined in
        [RFC3292] have been modified to include an extension block that
        follows a below.

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

                   Encaps 1 (1 byte): {

                      NA = 0,

                      Untagged Ethernet = 1,

                      Single-tagged Ethernet = 2}

                   Encaps 2 (1 byte):{

                      NA = 0,

                      PPPoA LLC = 1

                      PPPoA NULL = 2,

                      IPoA LLC = 3,

                      IPoA NuLL = 4,

                      Ethernet over AAL5 LLC with FCS = 5,

                      Ethernet over AAL5 LLC without FCS = 6,

                      Ethernet over AAL5 NULL with FCS = 7,

                      Ethernet over AAL5 NULL without FCS = 8}

             If this TLV structure. Individual messages in the following
        sections describe the usage and format of the extension block.

           All Extension TLVs will is present, the Data Link protocol MUST be designated
             indicated as follow:

            0                   1                   2                   3
            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |x|x|x|x|x|x|x|x| Message Type  |   Tech Type   | Block Length  |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                                                               |
           ~                         Extension Value                       ~
           |                                                               |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           x: Reserved Flags

              These are generally used by specific messages and will be defined in those messages.

           Message Type

              An 8-bit field corresponding to the message type where above.  However, the
              extension block is used.

           Tech Type

              An 8-bit field indicating Access Node can
             choose to not convey the applicable technology type value.
              The Message Type plus encapsulation on the Tech Value uniquely define a single
              Extension Type and can be treated as access loop
             by specifying a single 16 bit extension
              type. "Tech Type" value of 0x05 SHOULD be used by ANCP 0 (NA) for DSL
              technology.

              0x00          Extension the two encapsulation
             fields

5.4.3.  Line Configuration Extensions

   The Port Management message format defined in [RFC3292] has been
   modified to contain an extension block not it use.

              0x01 - 0x04   Already (described above in use by various technologies

              0x05          DSL

              0x06 - 0xFE   Reserved

              0xFF          Base Specification Use

           Block Length
              A 8-bit field indicating section
   Section 5.4.1.1) at the length end of the Extension Value
              field in bytes.  When the Tech Type = 0x00, message.  Also, the length value
              MUST be set to 0.

           Extension Value

              A variable length field that is an integer number of 32 bit
              words long.  The Extension Value original two
   byte Function field is interpreted according has been modified to contain one byte for the
   Function field indicating a specific definitions provided action to be taken by the messages
   recipient of the message, and one byte for X-Function field, which
   could further qualify the action specified in the
              following sections.

     5.4.2 Topology Discovery Extensions

     The Function field.

   Any Function specific data MUST be carried in the extension block.

   Not all the fields in GSMP Event message with PORT UP Port Management message type (80) is used for
     conveying DSL line attributes are applicable to the NAS.
   ANCP.  The message SHOULD fields that are not applicable MUST be
     generated when a line first comes UP, or any of set to zero by the attributes of
   ANCP sender and ignored by the
     line change e.g. ANCP receiver.

   The NAS uses the line re-trains to a different rate or one or more
     of extension block in the configured line Port Management messages to
   convey service attributes are administratively modified. Also,
     when the ANCP session first comes up, of the DSLSM SHOULD transmit a PORT
     UP message DSL lines to the NAS DSLAM.  TLVs are
   defined for each line that is up. When a DSL line goes
     down (idle or silent), the DSLAM SHOULD transmit an Event message with
     PORT DOWN message type (81) to the NAS. It is recommended that identification and service data for the
     DSLAMs use a dampening mechanism per DSL line
   lines.  Port number is set to control 0 in the rate of
     state changes per DSL line, communicated message.  A new action type
   "Configure Connection Service Data" (value 0x8) is defined.  The
   "Function" field is set to the NAS.

     Not all action type.  This action type
   indicates to the fields in GSMP Event message are applicable device being controlled (Access Node i.e.  DSLAM) to ANCP. The
     fields that are not applicable are set
   apply service configuration data contained in the extension value
   (TLVs), to 0 by the ANCP sender, and
     ignored DSL line (identified by one of the receiver. The fields TLVs in the PORT UP and PORT DOWN
     messages to
   extension value).  For the action type "Configure Connection Service
   Data", X-Function field MUST be set by the ANCP sender, and corresponding handling by to 0.  The Tech Type field is
   extended with new type "DSL".  The value for this field is 0x05.
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vers  |  Sub  | Message Type  | Result|        Code           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Partition ID  |            Transaction Identifier             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|      SubMessage Number      |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Port                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Port Session Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Event Sequence Number                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|x|x|x|x|x|x|x|   Duration    |    Function   | X-Function    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Event Flags         |        Flow Control Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |x|x|x|x|x|x|x|x| Message Type  |   Tech Type   | Block Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                         Extension Value                       ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 15

   The format of the
     ANCP receiver "Extension Value" field is described below. as follows:

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     # of TLVs               | Extension Block length (bytes)  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                            TLVs                               ~
       ~                                                               ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 16: Extension Value

   The version "Extension Value" field MUST be set to 3, contains one or more TLVs containing DSL
   line identifier and desired service attributes of the sub field MUST be set to 1.
     As defined in [RFC3292], the one DSL line.
   First 2 byte Message Type field MUST be set to
     80 for PORT UP Event message, and to 81 for PORT DOWN Event Message. The
     4 bit Result field and of the 8 bit Code field MUST both be set to 0. The
     24-bit Transaction Identifier field MUST be set to 0. The "I" bit and "Extension Value" contains the SubMessage field MUST be set to 1 to signify no fragmentation. number of TLVs
   that follow.  The
     Length field is two next 2 bytes and MUST contain the total length of the message
     (including header and the payload)
   extension block in bytes.

     The "Port" field, "Port Session Number" field and "Event Sequence
     Number" field are 4 bytes each, and MUST be set to 0 by the ANCP sender.
     LABEL (existing "Block Length" field in event messages is defined as a TLV in [RFC 3292]. ANCP
     does NOT use the Label TLV. In both PORT UP GSMP
   message is limited to 255 bytes and PORT DOWN event messages
     an ANCP sender MUST treat the Label field, immediately following the
     "Event Sequence Number" field, as is not sufficient).

   General format of a fixed TLV is:

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 byte field, and MUST set
     these 9 0 1 2 3 4 5 6 7 8 bytes to 0. 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Type                  |          Length               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                            Value                              ~
       ~                                                               ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 17:  General TLV

   The receiver MUST not interpret the LABEL value field as is padded to a 4-octet alignment.  The Length field
   in each TLV and MUST ignore contains the 8 actual number of bytes immediately following in the "Event
     Sequence Number" field. In future versions of ANCP, if necessary TLV (not
   including the
     un-used fields in GSMP Event message, which do padding if present).  If a TLV is not have ANCP specific
     semantics, can be used partially or completely, understood by re-naming
     appropriately, and associating valid semantics with these fields.

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

     In case of bonded copper loops to the customer premise (as per DSL
     multi-pair bonding described by [G.998.1] and [G.998.2]),
   access-node, it is silently ignored.  Depending upon the DSLAM MUST
     report deployment
   scenario, the aggregate net data rate and other attributes for NAS may specify "Access Loop Circuit-ID" or the "DSL
     bonded circuit" (represented "Access
   Aggregation Circuit-ID") as a single logical port) to the NAS defined in a
     PORT UP message. Any change section Section 5.4.1.
   Following TLVs can appear in the aggregate net data rate of the "DSL
     bonded circuit" (due this message:

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

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

   o  Type (Service-Profile-Name = 0x05): Reference to a change in net pre-configured
      profile on the DSLAM that contains service specific data rate of individual
     constituent DSL lines or due for the
      subscriber.

         Length : (up to change in state of 64 bytes)

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

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

5.4.4.  OAM Extensions

   GSMP "Port Management" message (type 32) SHOULD be reported used by the DSLAM NAS to
   trigger access node to run a loopback test on the NAS local loop.  The
   message format is defined in a
     PORT UP message. section Section 5.4.2.  The DSLAM MUST also report the "aggregate" state of the
     "DSL bonded circuit" version
   field SHOULD be set to the NAS via PORT UP and PORT DOWN messages.

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Vers  |  Sub  | Message Type  | Result|        Code           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Partition ID  |            Transaction Identifier             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |I|      SubMessage Number      |           Length              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                             Port                              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                      Port Session Number                      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                     Event Sequence Number                     |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        +                             Label                             +
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |x|x|x|x|x|x|x|x| Message Type  |   Tech Type   | Block Length  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        ~                         Extension Value                       ~
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and sub-version field SHOULD be set to 1.
   The format of remaining fields in the "Extension Value" field for Tech Type "DSL" is
        as follows :

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |             # of TLVs         | Extension block length (bytes)|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        ~                                                               ~
        ~                           TLVs                                ~
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GSMP header have standard semantics.  The "Extension Value" contains one or more TLVs
   function type used in the request message SHOULD be set to identify a DSL line "remote
   loopback" (type = 0x09).  The port, "port session number", "event
   sequence number", duration, "event flags", "flow control flags" and define its characteristics. A TLV can consist of multiple sub-TLVs.
     First 2 byte of the "Extension Value" contains
   code fields SHOULD all be set to 0.  The result field SHOULD be set
   to "AckAll" to indicate requirement for the number of TLVs that
     follow. access node to send a
   success or failure response.  The next 2 bytes transaction ID SHOULD contain a
   sequence number inserted by the total length of the TLVs carried NAS in each request that it
   generates.

   Not all the extension block in bytes (existing "Block Length" field fields in the GSMP Port Management message is limited are applicable to 255 bytes and is
   ANCP.  The fields that are not sufficient).

        General format of a TLV is :

         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            Type               |             Length            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        ~                                                               ~
        ~                           Value                               ~
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ applicable MUST be set to zero by the
   ANCP sender and ignored by the ANCP receiver.

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

   The TLV format is defined above in section Section 5.4.2.  The value
   field is padded to a 4-octet alignment.  The Length field in each TLV
   contains the actual number of bytes in the TLV (not including the
   padding if present).  If a TLV is not understood by the NAS, it is
   silently ignored. Currently  Depending upon the deployment scenario, the NAS
   may specify "Access Loop Circuit-ID" or the "Access Aggregation
   Circuit-ID") as defined types start from 0x01. in section Section 5.4.1.  Following TLVs are currently defined:

       1. can
   appear in this message:

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

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

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

   o  Type (OAM-Loopback-Test-Parameters = 0x07): Parameters related to
      loopback test.  This is a mandatory TLV and
          contains an identifier of the subscriber's connection to the access
          node (i.e.  "local loop"). The "local loop" can be ATM based or
          Ethernet based. The "Access Loop Circuit ID" has local significance
          at the access node. The exact usage on the NAS is beyond the scope
          of optional TLV.  If this document. The format used for "local loop" identification
          in ANCP messages MUST be identical to what TLV is used by the access
          nodes not
      present in subscriber signaling messages when the access nodes act as
          "signaling relay agents" as outlined in [RFC3046] and [TR-101]. request message, the DSLAM SHOULD use locally
      determined default values for the test parameters.

         Length : (upto 63 (4 bytes)

         Value : ASCII string.

          For an ATM based two 1 byte numbers described below (listed in order of
         most to least significant).  Thus, the 4 bytes consist of 1
         byte of Count, followed by 1 byte of Timeout, followed by two
         pad bytes of zero.

         +  Count (1 byte) : Number of loopback cells/messages that
            should be generated on the local loop the string consists as part of slot/port the
            loopback test.  The NAS SHOULD restrict the "count" to be
            greater than 0 and
          VPI/VCI information corresponding less than or equal to 32.  The DSLAM
            SHOULD discard the subscriber's DSL
          connection. Default syntax request for a loopback test, if the string inserted by the access
          node as per [TR101] is:

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

          The Access-Node-Identifier uniquely identifies the access node in
            received test parameters contain an out of range value for
            the access network. "count" field.  The slot/port and VPI/VCI uniquely identifies
          the DSL line on the access node. Also, there is one DSLAM MAY optionally send a failure
            response to one
          correspondence between DSL line and the VC between the access node
          and NAS with the NAS.

           For local loop which is Ethernet based (and tagged), code "invalid test parameter".

         +  Timeout (1 byte) : Upper bound on the string
           consists of slot/port and VLAN tag corresponding to time in seconds that
            the
           subscriber. Default syntax NAS would wait for a response from the string inserted DSLAM.  If the
            total time taken by the access
           node as per [TR101] is:

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

       2. Type (Access-Loop-Remote-Id = 0x02): This is an optional TLV and
          contains an identifier DSLAM to uniquely identify a user on complete a local loop
          on the access node. The exact usage on test with
            requested parameters, exceeds the NAS is out of scope specified "timeout" value,
            it can choose to omit the generation of
          this document. It is desirable that a response to the format used
            NAS.  DSLAM SHOULD use a locally determined value for the field
            "timeout", if the received value of the "timeout" parameter
            is similar to what 0.

   o  Type (Opaque-Data = 0x08) : This is used by the access nodes an optional TLV.  If present
      in subscriber
          signaling messages when the access nodes act as "signaling relay
          agents" as outlined request message, the DSLAM SHOULD reflect it back in [RFC3046] and [TR101].

          Length : (upto 63 bytes)

          Value  :  ASCII string

       3. Type (Access-Aggregation-Circuit-ID-Binary = 0x06) the
      response unmodified
         Length : (8 bytes)

         Value : two Two 32 bit integers.

          For ethernet access aggregation, where a per-subscriber (stacked)
          VLAN can be applied (1:1 model defined in [TR101]), integers inserted by the VLAN stack
          provides a convenient way NAS (not to uniquely identify be
         interpreted by the DSL line. DSLAM, but just reflected back in the
         response).

   The
          outer VLAN is equivalent to virtual path between access node generates a DSLAM and success or failure response when it deems
   the
          NAS and inner VLAN loopback test to be complete.  "Port Management" message (type
   32) is equivalent used.  The result field SHOULD be set to a virtual circuit on a per DSL
          line basis. In this scenario, any subscriber data received by success or failure.
   The function type SHOULD be set to 0x09.  The transaction ID SHOULD
   be copied from the
          access node and transmitted out sequence number contained in the uplink corresponding
   request.  The other parameters not explicitly defined here SHOULD be
   set as specified in the request message above.  The code field SHOULD
   be set to a value in the aggregation
          network will range 0x500 to 0x5ff (to be tagged reserved with
   IANA) to indicate the VLAN stack assigned by status of the executed test.  The valid values
   defined are (can be extended in future):

      0x500 : Specified access
          node

          This TLV line does not exist

      0x501 : Loopback test timed out

      0x502 : Reserved

      0x503 : DSL line status showtime

      0x504 : DSL line status idle

      0x505 : DSL line status silent

      0x506 : DSL line status training

      0x507 : DSL line integrity error

      0x508 : DSLAM resource not available

      0x509 : Invalid test parameter

   The Extension value can carry contain one or more TLVs including the VLAN tags assigned by TLV to
   identify the access node in line on which the
          ANCP messages. The VLAN tags can uniquely identify test was performed, and details
   from executing the DSL test.  The access line
          being referred identifier SHOULD be
   identical to what was contained in the ANCP messages, assuming the VLAN tags are
          not request.  The relevant TLVs
   are:

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

   o  Type (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in the aggregation network and are unique
          across physical ports. Each 32 bit integer (least significant bits)
          contains a 12 bit VLAN identifier (which is part of the VLAN tag
      section Section 5.4.1
   o  Type (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined by IEEE 802.1Q).

          Also, in case of an ATM aggregation network, where the DSLAM is
          directly connected to
      section Section 5.4.1

   o  Type (Opaque-Data = 0x08) : Data inserted by the NAS (without an intermediate ATM switch), in the two values can contain VPI and VCI on
      request reflected back by the DSLAM uplink (and can
          uniquely identify DSLAM.

         Length : (up to 8 bytes)

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

          This TLV is optional.

       4.

   o  Type (Access-Aggregation-Circuit-ID-ASCII (OAM-Loopback-Test-Response-String = 0x03) 0x09)

         Length : (upto 63 (up to 128 bytes)

         Value : Suitably formatted ASCII string.

          This field contains information pertaining to an uplink on string containing useful
         details about the
          access node. For Ethernet access aggregation, assuming test that the access
          node assigns VLAN tags (1:1 model), typical format NAS will display for the string
          is:

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

          The slot/port corresponds to the ethernet uplink on
         operator, exactly as received from the access node
          towards DSLAM (no manipulation/
         interpretation by the NAS.

          For NAS).  This is an optional TLV, but it is
         strongly recommended, that in case of ATM aggregation network, typical format for based local loop, the string is:

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

          This TLV allows
         DSLAM at the NAS to associate very least indicates via this TLV, the information contained in total
         loopback cells generated and the total loopback cells
         successfully received as part of executing the requested
         loopback test.

5.4.5.  Multicast Extensions

   The format of the ANCP messages to Multicast message starts with the DSL line on common GSMP
   header as in the access node.

          If case of the existing ANCP implementation.  Following
   is the format of this header:

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

                          Figure 18: ANCP Header
   The Result field takes one of the access node inserts this string values defined in the ANCP messages, when
          referring Section 5.

   The Transaction Identifier field is used to local loop characteristics (e.g. DSL line in case of distinguish between
   request messages and to associate a
          DSLAM), then it should be able response message to map the information contained in a request.
   Applications that require such response correlation MUST set the string uniquely
   Transaction Identifier to a value in the local loop (e.g. DSL line).

          On the NAS, the information contained range (1, 2^24 - 1).  When
   used in this string can be used to
          derive an "aggregation network" facing construct (e.g. an IP
          interface) corresponding to manner, the local loop (e.g. DSL line). The
          association could Transaction Identifier sequencing MUST be based on "local configuration" on
   maintained independently for each ANCP adjacency and per message
   type.  Furthermore, it SHOULD be incremented linearly for each new
   message of the NAS.

          The access node can also convey given type, cycling back to 1 after running the NAS, the characteristics
          (e.g. bandwidth) of the uplink on full
   range.  Message types not requiring response message correlation
   SHOULD set the access node. This TLV then
          serves Transaction Id field to 0x0.  In the purpose event of uniquely identifying an ANCP
   transport protocol failure, all pending ANCP messages destined to the uplink whose
          characteristics are being defined. A separate set of sub-TLVs will
   disconnected recipient can be defined for discarded until the uplink characteristics (TBD).

          This TLV transport is optional.

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

          Length : variable (up to 1024 bytes)

          Value : This re-
   established following which the Transaction Identifier is a mandatory TLV and consists of one or more Sub-
          TLVs corresponding to DSL line attributes. No sub-TLVs other than re-
   initialized.

   The value of the "DSL type" and "DSL line state" SHOULD be included Transaction Identifier in a PORT
          DOWN message.

          The general format Response message MUST be
   set to that of the sub-TLVs is identical respective Request message.  This allows the
   Requester to correlate the general TLV
          format. The value field in each sub-TLV is padded Response to a 4-octet
          alignment. the original Request.  The Length field
   Transaction Identifier is not used in each sub-TLV contains ANCP adjacency messages.  Also,
   other ANCP applications not requiring it SHOULD set the actual
          number of bytes Transaction
   Identifier to 0x0 in their messages.

   All TLVs within the TLV (not including ANCP message have to be 32 bit aligned, and when
   necessary padded with 0s to the 32 bit boundary.  The padding if present).
          Current defined sub-TLV types are start from 0x81.

          Following sub-TLVs are currently defined :

          . Type (DSL-Type = 0x91) : Defines the type of transmission system
             in use. This is a mandatory TLV.

             Length :  (4 bytes)

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

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

            Length  :  (4 bytes)

            Value   : (Rate not
   reflected in Kb/sec)

          . Type (Actual-Net-Data-Rate-Downstream = 0x82) : Actual
             downstream net data rate on a DSL line. the message length field.

5.4.5.1.  General well known TLVs

   This is a mandatory TLV.

             Length :  (4 bytes)

             Value  :  (Rate in Kb/sec)
          . Type (Minimum-Net-Data-Rate-Upstream = 0x83) : Minimum net data
             rate desired by section contains the definitions of three general well known
   TLVs.  These TLVs are intended to be re-usable across different
   Multicast messages.

5.4.5.1.1.  Target TLV

   The Target TLV (TBD) is intended to be a general well known TLV
   allowing the operator. This representation of different types of objects.  Its use
   is optional.

            Length  :  (4 bytes)

            Value   : (Rate in Kb/sec)

          . not restricted to any specific Message Type.

        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 (Minimum-Net-Data-Rate-Downstream = 0x84) : Minimum net
             data rate desired by Target          |        Target-TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                         Target Info                           ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Target TLV:

             TLV (0xTBD) indicating the operator. This is optional. type of target being addressed.
             Numbers TBC.  Tentative 0x1000 for single Access-Port.

   Target TLV Length:

             Length  :  (4 bytes)

            Value   : (Rate in Kb/sec)

          . Type (Attainable-Net-Data-Rate-Upstream = 0x85) : Maximum net
             upstream rate that bytes of Target Info.  Excludes TLV header

   Target Info:

             Target information as defined for each the given target.
             The field can consist of sub-TLVs.

   In its simplest form, when targeting a single access line the Target-
   TLV will be attained on set to a value of (0xTBD), and carry in its payload one
   or more sub-TLVs identifying the DSL line. This is target.  The following example
   illustrates the message format for a single port identified by an
             optional TLV.

            Length  :  (4 bytes)

             Value   : (Rate in Kb/sec)

          . Type (Attainable-Net-Data-Rate-Downstream = 0x86) : Maximum net
             downstream rate
   Access-Loop-Circuit-ID TLV (0x0001) that can could be attained on the DSL line. This is
             an optional TLV.

            Length  :  (4 bytes)

            Value   : (Rate in Kb/sec)

          . derived from a
   Port-UP message:

        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 (Maximum-Net-Data-Rate-Upstream = 0x87) : Maximum net data
             rate desired by the  operator. This is optional. Target          |        Target-TLV Length  :  (4 bytes)

            Value   : (Rate in Kb/sec)

          . Type (Maximum-Net-Data-Rate-Downstream = 0x88) : Maximum net
             data rate desired by the operator. This is optional.      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Access-Loop-Circuit-ID=0x0001 |       Circuit-ID Length  :  (4 bytes)

            Value   : (Rate in Kb/sec)
          . Type (Minimum-Net-Low-Power-Data-Rate-Upstream = 0x89) : Minimum
             net data rate desired by the operator in low power state. This       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                    Access Loop Circuit ID                     ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.4.5.1.2.   Command TLV

   The Command TLV (TBD) is optional.

            Length  :  (4 bytes)

            Value   : (Rate in Kb/sec)

          . Type (Minimum-Net-Low-Power-Data-Rate-Downstream = 0x8A) :
             Minimum net data rate desired by intended to be a general well known TLV
   allowing the operator in low power
             state. This is optional.

            Length  :  (4 bytes)

            Value   : (Rate in Kb/sec)

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

            Length  :  (4 bytes)

            Value   : (Time or more command directives in msec)

          . Type (Actual-Interleaving-Delay-Upstream = 0x8C) : Value
             corresponding a TLV
   oriented message.  The semantics of the command are allowed to be
   specified for each message type, ie different message types that
   choose to carry the interleaver setting. This is optional.

            Length  :  (4 bytes)

            Value   : (Time in msec)

          . Command TLV are expected to define the meaning of
   the content of the payload, which could be re-used from those already
   defined elsewhere if appropriate.

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     TLV Type (Maximum-Interleaving-Delay-Downstream = 0x8D) : maximum
             one way interleaving delay. This is optional. Command        |       Command-TLV Length  :  (4 bytes)

            Value   : (Time in msec)

          .      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                         Command Info                          ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Additional sub-TLV Type (Actual-Interleaving-Delay-Downstream = 0x8E) : Value
             corresponding   |   Additional sub-TLV Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                   Additional sub-TLV data                     ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Command TLV:

             TLV (0xTBD) indicating the contents to be one or more
             command directives.

   Command TLV Length:

             Combined length in bytes of the interleaver setting. This is optional.

            Length  :  (4 bytes)

            Value   : (Time data in msec)
          . Type (DSL line state = 0x8F) : Command Info and
             sub-TLV.  Excludes the Command TLV header

   Commad-Info:

             Command information as defined for each message type.  The state
             field can consist of sub-TLVs.

   Additional sub-TLV:

             Additional sub-TLVs can be present in a command TLV.  Any
             such sub-TLVs must directly follow each command.

   Additional sub-TLV Length:

             Number of actual bytes contained in the DSL line. For
             PORT UP message, at this time, the value portion of
             each additional sub-TLV

5.4.5.1.3.  Status-Info TLV

   The Status-info-TLV is optional (since intended to be a general well known TLV used
   to convey the
             message type implicitly conveys status code regarding commands and/or requests.  The
   format of the state Status-Info-TLV (TBD) is shown below.

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    TLV Type = Status-info     |        Status TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Result Code   |  Cmnd Nmbr    |      Error Message Length     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Error Message (aligned to 4 bytes length)              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           sub-TLVs...                                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   Status-info TLV:

             TLV (0xTBD) conveying the status or error response of a
             command

   Status TLV Length:

             Specifies the line). For PORT
             DOWN, length in bytes of the Status Info TLV
             payload.  Excludes the TLV is mandatory, since it further communicates header

   Result Code:

             Conveys the
             state of result code for the line as IDLE command or SILENT.

            Length  :  (4 bytes)

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

          . Type (Access Loop Encapsulation = 0x90) : The data link protocol
             and, optionally message, as
             defined by the encapsulation overhead on application.

   Cmnd Nmbr:

             Contains the access loop.
             This command number copied from the Request
             message.  The value of 0 is used whenever the error is not
             specific to a command.

   Error Message Length:

             Contains the length of an optional TLV. However, when this TLV error message or 0 if
             none.

   TLVs:

             This field is present, the
             data link protocol MUST minimally be indicated. The
             encapsulation overhead can be optionally indicated.

              Length  :  (3 bytes)

              Value : The three bytes (most to least significant) of indeterminate length, and valid
              set contains zero or
             more of values for each byte are defined below.

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

                                         ETHERNET = 1}

                    Encaps 1 (1 byte): {NA = 0,

                                        Untagged Ethernet = 1,

                                        Single-tagged Ethernet = 2}

                    Encaps 2 (1 byte):{ NA = 0,

                                     PPPoA LLC = 1,

                                     PPPoA NULL = 2,

                                     IPoA LLC = 3,

                                     IPoA NuLL = 4,

                                     Ethernet over AAL5 LLC with FCS = 5,

                                     Ethernet over AAL5 LLC without FCS = 6,

                                     Ethernet over AAL5 NULL the TLVs associated with FCS = 7,
                                     Ethernet over AAL5 NULL without FCS = 8}

     If this TLV is present, the Data Link protocol MUST be indicated as
     defined above. However, Status-info-TLV.

5.4.5.2.  Multicast Replication Control Message

   The Multicast Replication Control Message Type 0x90 (TBC) is sent by
   the Access Node can choose NAS to not convey the
     encapsulation AN with a directive to either add (join) or delete
   (leave) one or more multicast flows on the access loop by specifying a value target object identified in
   the content of 0 (NA) for the
     two encapsulation fields.

     5.4.3 Line Configuration Extensions

     The Port Management message.  An AN will use a Multicast Status
   message format defined in [RFC3292] has been
     modified to contain an extension block (described above in section
     5.4.1.1) at when conveying the end outcome of the message. Also, directive, and this message
   type is covered in Section 5.4.5.3.

   The sender of a Multicast Replication Control message MUST set the original two byte Function
   Result field has been modified to contain one byte for either "AckAll" or "NAck", and SHOULD use "NAck" by
   default.  Furthermore it SHOULD use the Function same Result field
     indicating a specific action to code for
   all Multicast Replication Control Messages sent, i.e.  Result field
   changes SHOULD be taken by the recipient of avoided.  The sender MUST populate the
     message, and one byte ANCP
   Transaction Identifier field with a distinct non-zero, linearly
   incrementing value for X-Function field, which could further qualify
     the action specified each Request per adjacency, as described in
   Section 5.4.5 .

   The ANCP Multicast Replication Control message payload contains the Function field. Any Function specific data
     MUST be carried
   following TLVs:

        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 = Target TLV      |     Length of Target-Info     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                      Value = Target-Info                      ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Type = Command TLV       |    Length of Command Info     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                      Value = Command Info                     ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Target:

      See Section 5.4.5.1.1.  The Target TLV (0xTBD) can only feature
      once in the extension block. a Multicast Replication Control Message.  Only one such
      TLV is allowed in this message type.

   Length of Target-Info:

             See Section 5.4.5.1.1

   Target Info:

             See Section 5.4.5.1.1

   Command TLV:

             The NAS uses Command TLV (0xTBD) contains the extension block in multicast flow
             directive(s) for the Port Management messages to
     convey service attributes target and any additional parameters
             passed via sub-TLVs.  See Section 5.4.5.1.2

   Length of Command Info:

             Includes sub-TLVs.  See Section 5.4.5.1.2

   Command Info:

             Command information as defined in section
             Section 5.4.5.1.2.

   The contents of the DSL lines to Command TLV for the DSLAM. TLVs Multicast Replication Control
   Message are defined for DSL line identification and service data for the DSL lines.
     Port number is set to be as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Command Code  |R O M   Flags  |         Command Length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Addr Family   | Encoding Type |  Multicast Source Address     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++++++|
       | Addr Family   | Encoding Type |  Multicast Flow Address       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++++++-+

   Command Code:

             Command directive: 0x01 - Add; 0x02 - Delete; 0x03 - Delete
             All.

   Command Length:

             Length in bytes of each Command including multicast flow
             address, but excluding the message. A new action type "Configure
     Connection Service Data" (value 0x8) is defined. The "Function" field is
     set to the action type. This action type indicates to Command Code header and flags.

   Flags:

             8 bit General purpose Flag field.  Currently the device being
     controlled (Access Node i.e. DSLAM) following
             flags are defined:

             R -
                       Resource Admitted Flag.  Set to apply service configuration data
     contained 1 in the extension value (TLVs), an add
                       command to indicate that the DSL line (identified flow resources have
                       been reserved by
     one of the TLVs admission control, 0 otherwise.
                       Not used in delete command.

             O -

                       Flow Accounting.  When set in add command
                       indicates that byte accounting for the extension value). For flow is to
                       commence.

             M -

                       When set indicates that multicast flow is SSM and
                       the address-family-element set MUST specify the
                       source and group addresses.  When not set
                       indicates that multicast flow is ASM and address-
                       family-element MUST specify the action type "Configure
     Connection Service Data", X-Function group address,
                       and the Source Address field MUST be set is to 0. be omitted.

   Address Family:

             The Tech
     Type field is extended with new type "DSL". address family used

   The value for this field is
     0x05. unicast source address/mask follows the format defined in
   [IANAAEA]

   Encoded-Unicast-address: Takes the following format:
   0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Vers  |  Sub Addr Family   | Message Encoding Type | Result|        Code           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Partition ID  |            Transaction Identifier             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |I|      SubMessage Number      |           Length              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                             Port                              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                      Port Session Number                      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                     Event Sequence Number                     |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |R|x|x|x|x|x|x|x|   Duration    |    Function   | X-Function     Unicast Address           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++++++++
   Encoded-Unicast-address: Takes the following format:
   0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Event Flags         |        Flow Control Flags     |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |x|x|x|x|x|x|x|x| Message Type Addr Family   |   Tech Encoding Type | Block Length  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        ~                         Extension Value                       ~
        |     Unicast Address           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++++++++

   Encoding Type:

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

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |             # type of TLVs         | Extension Block length (bytes)|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        ~                                                               ~
        ~                            TLVs                               ~
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ encoding used within a specific Address Family.
             The "Extension Value" field contains one or more TLVs containing DSL
        line identifier value `0' is reserved for this field, and desired service attributes of the represents
             the DSL line.
        First 2 byte native encoding of the "Extension Value" contains the number of TLVs
        that follow. Address Family.

             The next 2 bytes contain the total length of address as represented by the
        extension block in bytes (existing "Block Length" field in given Address Family and
             Encoding Type.

   Address:

             The address as represented by the GSMP
        message is limited to 255 bytes given Address Family and
             Encoding Type.

   The padding will be done after both addresses so that it is not sufficient).

        General format of a TLV is: 32-bit
   aligned.  As an example for IPv4:

       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 CmdCode=0x01  |0 0 1   Flags  |         Command Length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 0x1| Enc Type  0x0 |
        ~                                                               ~
        ~                           Value                               ~
        |    Src Address first 2 bytes  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        The value field is padded to a 4-octet alignment. The Length field in
        each TLV contains the actual number of
       | Src Address last 2 bytes in the TLV (not
        including the padding if present). If a TLV is not understood by the
        access-node, it is silently ignored. Depending upon the deployment
        scenario, the NAS may specify "Access Loop Circuit-ID" or the "Access
        Aggregation Circuit-ID") as defined in section 5.4.1. Following TLVs
        can appear in this message:

       oType (Access-Loop-Circuit-ID = 0x01) : defined in section 5.4.1

       oType (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in
          section 5.4.1.

       oType (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in section
          5.4.1.

       oType (Service-Profile-Name = 0x05): Reference to a pre-configured
          profile on the DSLAM that contains service specific data for the
          subscriber.

           Length : (upto 64      | AddrFamily 0x1|  Enc Type 0x0 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Multicast Address (4 bytes)

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

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

     5.4.4 OAM Extensions

        GSMP "Port Management" message (type 32) SHOULD be used by the NAS to
        trigger access node to run a loopback test on the local loop. The
        message format above example, no padding is defined in section 5.4.2. The version field SHOULD
        be set to 3 and sub-version field SHOULD required.

   A received Multicast Replication Control Message containing an
   unrecognized Target TLV MUST be set communicated to 1. The remaining
        fields in the GSMP header have standard semantics. The function type
        used sender as an
   error in a Multicast Status Message indicating the request message SHOULD be set to "remote loopback" (type
        = 0x09). "Unrecognised port
   Type - 0x04" error.  The port, "port session number", "event sequence number",
        duration, "event flags", "flow control flags" and code fields SHOULD
        all be set reception of a Multicast Replication Control
   Message, or any ANCP message, that is found to 0. The result field SHOULD be set have mandatory TLVs
   missing is to "AckAll" be addressed as part of a ANCP base protocol mechanism
   yet to
        indicate requirement be defined.

   Each Multicast Replication Control Message may contain one or more
   command directives, each encapsulated by their own Command TLVs.  The
   sender MUST use separate Command TLVs for the access node each distinct multicast
   flow.  When successive commands relate to send a success given Target and flow,
   the state of features controlled or failure
        response. The transaction ID SHOULD contain a sequence number
        inserted affected by the NAS flags as well as by
   optional attributes received in each request the Multicast Replication Control
   message, are to be interpreted as replacing any such previous state
   for that it generates. The extension
        field format is also defined above port and flow.  As an example, successive Multicast
   Replication Control messages containing add commands for a given port
   and flow, but differing in section 5.4.2. The extension
        value field can contain one or more TLVs including the access-line
        identifier on accounting flag setting should be
   interpreted as affecting the DSLAM and OAM test characteristics desired by state of the
        NAS. accounting feature.

   The TLV format recipient of a Multicast Replication Control message is defined above to run an
   implicit directive numbering across the multiple directives in section 5.4.2. the
   message.  The value field numbering is
        padded to start from 0x01 for each directive in a 4-octet alignment.
   given ANCP Multicast Replication Control message, and be restarted
   for subsequent messages.  The Length field recipient MUST process the directives
   in each TLV contains the actual number order of bytes in reception, and use the TLV (not including derived directive number in
   any response messages, besides the padding if
        present). If Transaction ID.

   The processing/execution of multiple directives contained in a TLV is not understood by single
   Multicast Control message MUST be interrupted at the NAS, it is silently
        ignored. Depending upon first error, and
   the deployment scenario, remaining commands in the NAS may specify
        "Access Loop Circuit-ID" or Multicast Replication Control message
   discarded.  In such a case a Multicast Status message MUST be sent
   indicating the "Access Aggregation Circuit-ID") as
        defined in section 5.4.1. Following TLVs can appear in this message:

       oType (Access-Loop-Circuit-ID = 0x01) : defined in section 5.4.1

       oType (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in
          section 5.4.1.

       oType (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in section
          5.4.1.

       oType (OAM-Loopback-Test-Parameters = 0x07): Parameters related to
          loopback test. This is an optional TLV. If this TLV is not present command number that resulted in the request message, error along with
   the DSLAM SHOULD use locally determined
          default values for error code.

   When the test parameters.

           Length: 4 bytes

           Value  : two 1 byte numbers described below (listed in order strict sequenced processing of
           most to least  significant). Thus, the 4 bytes consist of 1 byte
           of Count, followed by 1 byte of Timeout, followed by two pad bytes
           of zero.

           o  Count (1 byte) : Number of loopback cells/messages that should
              be generated on directives in a single
   Multicast Control message is not required the local loop as part directives MUST be
   distributed across separate Multicast Replication Control messages.

   Each command directive is equipped with an 8-bit Flags field that
   allows specification of Multicast ASM or SSM modes of the loopback test.
              The NAS SHOULD restrict the "count" to be greater than 0 operation, and
              less than
   an indication of other features or equal conditions attached to 32. The DSLAM SHOULD discard this
   command (e.g.  To enable accounting for the request flow, etc).  Unassigned
   flags are reserved for a loopback test, if future use, and could in the received test parameters contain an
              out future be subject
   of range value for the "count" field. The DSLAM MAY
              optionally send capability negotiation.  When receiving a failure response to the NAS with the code
              "invalid test parameter".

           o  Timeout (1 byte) : Upper bound on the time in seconds that the
              NAS would wait for Multicast
   Replication Control Message containing an unrecognized Flag set (to
   1), a response from recipient MUST interpret it as an error, and generate an
   Multicast Status message indicating the DSLAM. If error.

   The multicast flow subject to the total time
              taken command is specified by means of
   one or two well known Address Family designators ([IANAAEA]), the DSLAM to complete a test with requested
              parameters, exceeds
   IPv4-Address-Family (0x01) and the specified "timeout" value, it can
              choose to omit IPv6-Address-Family (0x02).  When
   the generation of a response to M flag is set the NAS. DSLAM
              SHOULD use a locally determined value for two Address-Family tuples MUST be present in
   the "timeout", if strict order specifying the
              received value of multicast flow source and group
   respectively.  When the "timeout" parameter M flag is 0.

       oType (Opaque-Data = 0x08) : This cleared only one Address-Family is an optional TLV. If present in
   allowed, specifying the request message, multicast flow.

   For future extensibility, each command may also have additional TLVs
   appended following the DSLAM command and multicast flow information
   (referred to as "TLVs" in the message format above).  Unrecognized
   TLVs SHOULD reflect it back be silently discarded.  The figure below is an example of
   a Multicast Replication Control message that would result in a swap
   from multicast SSM flows 192.0.2.1, 233.252.0.2, to 192.0.2.2,
   233.252.0.3 on the Target identified by the
          response unmodified.

           Length : "Access Loop Circuit ID":

       0 1 2 3 4 5 6 7 8 bytes

           Value 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Type (0x88-0C)         |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Vers  |  Sub  |MessageType=90 | 0x02  |        Code           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Partition ID  |            Transaction Identifier = 0001      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |I|      SubMessage Number      |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Type = Target 0x1000   |        Target TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                    Access Loop Circuit ID                     ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Type = Command TLV     |       Command-TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Cmd Code=0x02 |0 0 1          |      Command Length           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0  |  Mcast Source: 192.0.2.1       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0  |  Mcast Flow : Two 32 bit integers inserted 233.252.0.2      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
       |        Type = Command-TLV     |       Command-TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Cmd Code=0x01 |0 0 1          |      Command Length           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Mcast Source: 192.0.2.2      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Mcast Flow: 233.252.0.3      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.4.5.3.  Multicast Status Message

   The Multicast Status Message (Message Type 0x91 - TBC) is sent by the NAS (not
   AN to be
           interpreted by the DSLAM, but just reflected back NAS in the
           response).

        The access node generates a success or failure response when it deems
        the loopback test to be complete. "Port Management" a Multicast Replication Control Message
   and its command directives.  A Multicast Status message (type 32)
        is used. The result field SHOULD be set to success or failure. The
        function type SHOULD be set to 0x09. The transaction ID SHOULD be
        copied from the sequence number contained in MUST use the corresponding
        request. The other parameters not explicitly defined here SHOULD be
        set
   same ANCP Transaction ID as specified that in the request message above. original Multicast
   Replication Control Message.  The code field SHOULD
        be set to a value Success or Failure status is
   reported in the range 0x500 to 0x5ff (to be reserved with
        IANA) to indicate the status Result field of the executed test. The valid values
        defined are (can be extended ANCP header as described in future):

           0x500 : Specified access line does not exist.

           0x501 : Loopback test timed out.

           0x502 : Reserved

           0x503 : DSL line status showtime.

           0x504 : DSL line status idle.

           0x505 : DSL line status silent.

           0x506 : DSL line status training.

           0x507 : DSL line integrity error.

           0x508 : DSLAM resource not available.

           0x509 : Invalid test parameter.

     The Extension value can
   Section 5.4.5.

   A Multicast Status Message indicating Success SHOULD simply consist
   only of the base ANCP header with no body, however the message MAY
   contain one or more TLVs including the TLV that are meant to
     identify the access line on which the test was performed, and details
     from executing the test. The access line identifier SHOULD be identical communicate any relevant
   information to what was contained in the request. an application.  The relevant TLVs are:

       oType (Access-Loop-Circuit-ID = 0x01) : defined in section 5.4.1

       oType (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in
          section 5.4.1.

       oType (Access-Aggregation-Circuit-ID-ASCII = 0x03): payload of a Multicast Status
   Message indicating Failure MUST contain an Status-Info TLV (0xTBD),
   as defined in section
          5.4.1.

       oType (Opaque-Data = 0x08) : Data inserted Section 5.4.5.1.3, as its first TLV and SHOULD be
   followed by the NAS Target TLV and Port-info.  Other TLVs MAY be present.
   A Multicast Status message indicating Failure MUST be sent whenever a
   Multicast Control message cannot be fulfilled or results in the request
          reflected back by the DSLAM.

           Length : 8 bytes

           Value : Two 32 bit integers as received an
   execution error.  The Cmnd Nmbr parameter in the request (opaque to
           the DSLAM).

       oType (OAM-Loopback-Test-Response-String = 0x09)

           Length (upto 128 bytes)

           Value : Suitably formatted ASCII string containing useful details
           about the test that Status-Info TLV
   contained by the NAS will display for Multicast Status Message is to indicate the operator, exactly
           as received from number
   of the DSLAM (no manipulation/interpretation by command in the
           NAS). This is an optional TLV, but it is strongly recommended, Multicast Replication Control Message that
   resulted in case an error.

        0x00 - Success

        0x01 - Malformed message

        0x02 - Command not supported

        0x03 - Flag set but not supported

        0x04 - Unrecognized Target

        0x05 - Unsupported Address Family

        0x06 - Malformed flow address

        0x07 - No resources

        0x08 - Unknown Target

        0x09 - Target down

        0x0a - Configuration error (such as Port not enabled for
        multicast)
        0x0b - Multicast flow does not exist

        0x0c - Unsupported address encoding

        0x0d - Additional info needed to execute command (payload MAY
        contain an indication of ATM based local loop, the DSLAM at the very least
           indicates via this TLV, the total loopback cells generated and the
           total loopback cells successfully received as part expected info)

        0x0e - Multicast flow count exceeded

        0x0f - M Flag set, but no IP Source address provided

        0x10 - Transaction-id out of executing sequence

   An example of a failure message for an invalid address, including the requested loopback test.

     5.5
   Target TLV for a 4 byte "Access Loop Circuit ID", followed by TLV
   padding, is as follows:

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Type (0x88-0C)         |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Vers  |  Sub  |MessageType=91 | 0x4   |        Code           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Partition ID  |            Transaction Identifier = 0001      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |I|      SubMessage Number      |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Status-info-TLV=TBD    |      Status-TLV-Length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Result Code  |  Cmd Number   |    Error Message Length       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Error Message (padded to 4) if Length > 0           |
       +---------------------------------------------------------------+
       |     Target TLV=0x100          |        Target-Length          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Access Loop ID type       |     Access-Loop ID  Length    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            circuit ID                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.5.  ATM-specific considerations

   The topology discovery and line configuration involve the DSL line
   attributes.  For ATM based access networks, the DSL line on the DSLAM
   is identified by the port and PVP/PVC corresponding to the
   subscriber.  The DSLAMs are connected to the NAS via an ATM access
   aggregation network.  Since, the DSLAM (access-node) is not directly
   connected to the NAS, the NAS needs a mechanism to learn the DSL line
   identifier (more generally referred to as "Access Loop Circuit-ID")
   corresponding to a subscriber.  The "Access loop circuit-ID" has no
   local significance on the NAS.  The ANCP messages for topology
   discovery and line configuration carry opaque "Access loop Circuit-
        ID"
   Circuit-ID" which has only local significance on the DSLAMs.

   The access loop circuit identifier can be carried as an ASCII string
   in the ANCP messages.  This allows ANCP to be decoupled from the
   specifics of the underlying access technology being controlled.  On
   the other hand, this requires a NAS mechanism by which such
   identifier can be correlated to the context of an "aggregation
   network" facing IP interface (corresponding to the subscriber) on the
   NAS.  This would typically require local configuration of such IP
   interfaces, or of the underlying ATM interfaces.

     5.6

5.6.  Ethernet-specific considerations

   One possible way of approaching the use of Ethernet technology in the
   access aggregation network is to recreate the equivalent of Virtual
   Paths (VPs) and Virtual Circuits (VCs) by using stacked Virtual LAN
   tags.  As an example, one could use an "outer" VLAN to create a form
   of "virtual path" between a given DSLAM and a given NAS.  And then
   use "inner" VLAN tags to create a form of "virtual circuit" on a per
   DSL line basis.  In this case, VLAN tags conveyed in topology
   discovery and line configuration messages will allow to uniquely
   identify the DSL line in a straightforward manner, assuming the VLAN
   tags are not translated in some way by the aggregation network, and
   are unique across physical ports.

   However, some carriers do not wish to use this "connection oriented"
   approach.  Therefore, an alternative model is to bridge sessions from
   multiple subscribers behind a DSLAM to a single VLAN in the
   aggregation network.  This is the N:1 model.  In this model, or in
   the case where user traffic is sent untagged, the access node needs
   to insert the exact identity of the DSL line in the topology
   discovery and line configuration messages, and then have hve a mechanism
   by which this can be correlated to the context of an "aggregation
   network" facing IP interface (for the subscriber) on the NAS.  This
   can either be based on local configuration on the NAS, or on the fact
   that such DSLAM (access node) typically inserts the "Access Loop
   Circuit ID" in subscriber signaling messages relayed to the NAS (i.e.
   DHCP or PPPoE discovery messages).

   Section Section 5.4.1 defines "Access Loop Circuit ID".

     6

6.  IANA Considerations

   New Tech-Type, capability types, TLVs, sub-TLV types related to
   topology
        discovery and discovery, line configuration and Multicast will need to be
   reserved.

     7

7.  Security Considerations

        The NAS and DSLAMs are implicitly in a trusted domain, so security
        for

   Security of the ANCP protocol is not a strong requirement. However, if needed security can
        be provided using IP security as indicated discussed in [RFC3293].

     8 [ANCP-SEC]

8.  Acknowledgements

   The authors would like to thank everyone that has provided comments
   or inputs to this document.  In particular, the authors acknowledge
   the inputs provided by Peter Arberg, Josef Froehler, Derek Harkness,
   Kim Hyldgaard, Sandy Ng, Robert Peschi, Michel Platnic and the work
   done by Philippe Champagne, Wojciech Dec and Stefaan De Cnodder
   regarding multicast extensions.

9.  References

     8.1

9.1.  Normative References

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

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

   [RFC3292]  Doria, A. and et al, all, "General Switch Management Protocol- V3"
        (GSMP v3), RFC 3292, Protocol
              (GSMP) V3", June 2002.

   [RFC3293]  Worster, T., Doria, A. A., and 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.

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

     8.2

9.2.  Informative References

   [ANCP-FRAMEWORK]
              Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S.
              Wadhwa, "Framework and Requirements for an Access Node
              Control Mechanism in Broadband Multi-Service Networks",
              draft-ietf-ancp-framework-06.txt, , May 2008.

   [ANCP-SEC]
              Moustafa, H., Tschofenig, T., and S. De Cnodder, "Security
              Threats and Security Requirements for the Access Node
              Control Protocol (ANCP)",
              draft-ietf-ancp-security-threats-06.txt work in progress,
              October 2008.

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

   [IANAAEA]  "http://www.iana.org/assignments/address-family-numbers",
              2005.

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

   [TR-059] DSL   Anschutz, T., "DSL Forum TR-059, DSL Evolution -
              Architecture Requirements for the Support of QoS-Enabled
              IP Services, Tom Anschutz (BellSouth
        Telecommunications), 09/2003.

        [TR-058] DSL Forum TR-058, Multi-Service Architecture & Framework
        Requirements, Mark Elias (SBC) and Sven Ooghe (Alcatel), 09/2003. Services", September 2003.

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

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

        [ANCP-FRAMEWORK] Framework for Access Node Control Mechanism in
        Broadband Networks, draft-ietf-ancp-framework-00.txt.

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

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

     Author's

Authors' Addresses

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

   Phone:
   Fax:
   Email: swadhwa@juniper.net
   Jerome Moisand
   Juniper Networks
   10 Technology Park Drive
   Westford, MA  01886
   USA

   Phone:
   Fax:
   Email: jmoisand@juniper.net

   Swami Subramanian
   Juniper Networks
   10 Technology Park Drive
   Westford, MA  01886
   USA

   Phone:
   Fax:
   Email: ssubramanian@juniper.net

   Thomas Haag
   T-systems

   Phone:
   Fax:
   Email: thomas.haag@t-systems.com

   Norber Voigt
   Siemens

   Phone:
   Fax:
   Email: norbert.voigt@siemens.com
   Roberta Maglione
   Telecom Italia
   via Reiss Romoli 274
   Torino
   Italy

   Phone:
   Email: roberta.maglione@telecomitalia.it

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
        ietf-ipr@ietf.org

     Acknowledgment

        Thanks to Peter Arberg, Josef Froehler, Derek Harkness, Kim
        Hyldgaard, Sandy Ng, Robert Peschi, Michel Platnic, Stefaan DE
        Cnodder and Wojciech Dec for their input to this document.
   ietf-ipr@ietf.org.