tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6320

 
 
 

Protocol for Access Node Control Mechanism in Broadband Networks

Part 3 of 4, p. 38 to 65
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 38 
4.  Generally Useful ANCP Messages and TLVs

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

4.1.  Provisioning Message

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

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

               Figure 9: Format of the Provisioning Message

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

   Message Type:  MUST be set to 93.

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

   Result Code:  MUST be set to zero.

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

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

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

4.2.  Generic Response Message

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

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

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

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

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

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

           Figure 10: Structure of the Generic Response Message

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

   Message Type:  MUST be set to 91.

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

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

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

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

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

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

4.3.  Target TLV

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

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

   Length:  Variable, depending on the specific object type.

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

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

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

          Figure 11: Example of Target TLV for Single Access Line

4.4.   Command TLV

   Type:  0x0011

   Description:  The Command TLV (0x0011) is intended to be a general
      means of encapsulating one or more command directives in a TLV-
      oriented message.  The semantics of the command can be specified
      for each message type using it.  That is, the specification of

Top      Up      ToC       Page 42 
      each message type that can carry the Command TLV is expected to
      define the meaning of the content of the payload, although re-use
      of specifications is, of course, permissible when appropriate.
      Support of any specific variant of the Command TLV is OPTIONAL
      unless the ANCP agent claims support for a capability that
      requires its use.

   Length:  Variable, depending on the specific contents.

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

4.5.  Status-Info TLV

   Name:  Status-Info

   Type:  0x0106

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

   Length:  Variable, depending on the specific contents.

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

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

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

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

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

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

   Figure 12 illustrates the Status-Info TLV.

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

                      Figure 12: The Status-Info TLV

5.  Introduction to ANCP Capabilities for Digital Subscriber Lines
    (DSLs)

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

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

Top      Up      ToC       Page 44 
5.1.  DSL Access Line Identification

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

5.1.1.  Control Context (Informative)

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

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

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

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

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

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

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

   Access line identification by logical appearance on the user side of
   the Access Node will always identify a DSL access line uniquely.
   Identification by the logical appearance on the NAS side of the
   Access Node is unique only if there is a one-to-one mapping between

Top      Up      ToC       Page 45 
   the appearances on the two sides and no identity-modifying
   aggregation between the AN and the NAS.  In other cases, and in
   particular in the case of Ethernet aggregation using the N:1 VLAN
   model, the user-side access line identification is necessary, but the
   NAS-side identification is potentially useful information allowing
   the NAS to build up a picture of the aggregation network topology.

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

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

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

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

5.1.2.  TLVs for DSL Access Line Identification

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

Top      Up      ToC       Page 46 
   ANCP agents conforming to this section MUST satisfy the following
   requirements:

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

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

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

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

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

5.1.2.1.  Access-Loop-Circuit-ID TLV

   Type:  0x0001

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

   Length:  Up to 63 bytes

   Value:  ASCII string

5.1.2.2.  Access-Loop-Remote-ID TLV

   Type:  0x0002

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

Top      Up      ToC       Page 47 
   Length:  Up to 63 bytes

   Value:  ASCII string

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

   Type:  0x0006

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

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

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

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

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

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

   Length:  4 or 8 bytes

   Value:  One or two 32-bit binary fields.

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

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

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

   Type:  0x0003

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

      As an extension to the present document, the Access Node could
      convey to the NAS the characteristics (e.g., bandwidth) of the
      uplink on the Access Node.  This TLV or the binary equivalent
      defined above then serves the purpose of uniquely identifying the
      uplink whose characteristics are being defined.  The present
      document does not specify the TLVs needed to convey the uplink
      characteristics.

   Length:  Up to 63 bytes

   Value:  ASCII string

6.  ANCP-Based DSL Topology Discovery

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

6.1.  Control Context (Informative)

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

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

Top      Up      ToC       Page 49 
   o  subsequent to that, whenever a DSL access line resynchronizes; and

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

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

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

   o  whenever a DSL access line that is equipped in an AN but
      administratively disabled is signaled as "IDLE"; and

   o  subsequent to that, whenever a DSL access line loses
      synchronization.

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

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

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

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

   Figure 14 summarizes the interaction.

Top      Up      ToC       Page 50 
   1.   Home            Access                          NAS
       Gateway           Node

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

   2.   Home            Access                          NAS
       Gateway           Node

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

   3.   Home            Access                          NAS
       Gateway           Node

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

          Figure 14: ANCP Message Flow for DSL Topology Discovery

6.2.  Protocol Requirements

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

6.2.1.  Protocol Requirements on the AN Side

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

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

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

6.2.2.  Protocol Requirements on the NAS Side

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

Top      Up      ToC       Page 51 
   The NAS-side ANCP agent MUST conform to the normative requirements of
   Section 5.1.2.

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

6.3.  ANCP Port Up and Port Down Event Message Descriptions

   The format of the ANCP Port Up and Port Down Event messages is shown
   in Figure 15.

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

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

    Figure 15: Format of the ANCP Port Up and Port Down Event Messages
                        for DSL Topology Discovery

   See Section 3.6.1 for a description of the ANCP general message
   header.  The Message Type field MUST be set to 80 for Port Up, 81 for
   Port Down.  The 4-bit Result field MUST be set to zero (signifying
   Ignore).  The 12-bit Result Code field and the 24-bit Transaction

Top      Up      ToC       Page 52 
   Identifier field MUST also be set to zeroes.  Other fields in the
   general header MUST be set a as described in Section 3.6.

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

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

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

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

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

   Reserved (8 bits):  set as described in Section 3.4.

   # of TLVs (16 bits):  The number of TLVs that follow, not counting
      TLVs encapsulated within other TLVs.

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

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

6.4.  Procedures

6.4.1.  Procedures on the AN Side

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

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

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

Top      Up      ToC       Page 53 
   than one.  In the Port Up message, the DSL-Line-Attributes TLV MUST
   be present.  In the Port Down message, the DSL-Line-Attributes TLV
   MAY be present.

6.4.2.  Procedures on the NAS Side

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

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

6.5.  TLVs for DSL Line Attributes

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

6.5.1.  DSL-Line-Attributes TLV

   Type:  0x0004

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

   Length:  Variable (up to 1023 bytes)

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

Top      Up      ToC       Page 54 
6.5.2.  DSL-Type TLV

   Type:  0x0091

   Description:  Indicates the type of transmission system in use.

   Length:  4 bytes

   Value:  32-bit unsigned integer

         ADSL1 = 1

         ADSL2 = 2

         ADSL2+ = 3

         VDSL1 = 4

         VDSL2 = 5

         SDSL = 6

         OTHER = 0

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

   Type:  0x0081

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

   Length:  4 bytes

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

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

   Type:  0x0082

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

   Length:  4 bytes

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

Top      Up      ToC       Page 55 
6.5.5.  Minimum-Net-Data-Rate-Upstream TLV

   Type:  0x0083

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

   Length:  4 bytes

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

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

   Type:  0x0084

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

   Length:  4 bytes

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

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

   Type:  0x0085

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

   Length:  4 bytes

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

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

   Type:  0x0086

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

   Length:  4 bytes

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

Top      Up      ToC       Page 56 
6.5.9.  Maximum-Net-Data-Rate-Upstream TLV

   Type:  0x0087

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

   Length:  4 bytes

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

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

   Type:  0x0088

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

   Length:  4 bytes

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

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

   Type:  0x0089

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

   Length:  4 bytes

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

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

   Type:  0x008A

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

   Length:  4 bytes

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

Top      Up      ToC       Page 57 
6.5.13.  Maximum-Interleaving-Delay-Upstream TLV

   Type:  0x008B

   Description:  Maximum one-way interleaving delay.

   Length:  4 bytes

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

6.5.14.  Actual-Interleaving-Delay-Upstream TLV

   Type:  0x008C

   Description:  Value corresponding to the interleaver setting.

   Length:  4 bytes

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

6.5.15.  Maximum-Interleaving-Delay-Downstream TLV

   Type:  0x008D

   Description:  Maximum one-way interleaving delay.

   Length:  4 bytes

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

6.5.16.  Actual-Interleaving-Delay-Downstream

   Type:  0x008E

   Description:  Value corresponding to the interleaver setting.

   Length:  4 bytes

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

Top      Up      ToC       Page 58 
6.5.17.  DSL-Line-State TLV

   Type:  0x008F

   Description:  The state of the DSL access line.

   Length:  4 bytes

   Value:  32-bit unsigned integer

         SHOWTIME = 1

         IDLE = 2

         SILENT = 3

6.5.18.  Access-Loop-Encapsulation TLV

   Type:  0x0090

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

   Length:  3 bytes

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

         Byte 1: Data Link

            ATM AAL5 = 0

            ETHERNET = 1

         Byte 2: Encapsulation 1

            NA = 0

            Untagged Ethernet = 1

            Single-tagged Ethernet = 2

            Double-tagged Ethernet = 3

Top      Up      ToC       Page 59 
         Byte 3: Encapsulation 2

            NA = 0

            PPPoA LLC = 1

            PPPoA Null = 2

            IPoA LLC = 3

            IPoA Null = 4

            Ethernet over AAL5 LLC with FCS = 5

            Ethernet over AAL5 LLC without FCS = 6

            Ethernet over AAL5 NULL with FCS = 7

            Ethernet over AAL5 NULL without FCS = 8

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

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

               Figure 16: The Access-Loop-Encapsulation TLV

7.  ANCP-Based DSL Line Configuration

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

7.1.  Control Context (Informative)

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

Top      Up      ToC       Page 60 
     Home            Access               NAS             RADIUS/AAA
    Gateway           Node                             Policy Server

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

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

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

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

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

   User     Home            Access         NAS
           Gateway           Node

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

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

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

   OSS: Operations Support System

   Figure 18: Message Flow - ANCP Mapping for Updated Line Configuration

Top      Up      ToC       Page 61 
7.2.  Protocol Requirements

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

7.2.1.  Protocol Requirements on the NAS Side

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

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

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

7.2.2.  Protocol Requirements on the AN Side

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

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

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

Top      Up      ToC       Page 62 
7.3.  ANCP Port Management (Line Configuration) Message Format

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

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

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

       Figure 19: Port Management Message for DSL Line Configuration

   See Section 3.6 for a description of the ANCP general message header.
   The Message Type field MUST be set to 32.  The 12-bit Result Code
   field MUST be set to 0x0.  The 4-bit Result field MUST be set to
   either 0x1 (Nack) or 0x2 (AckAll), as determined by policy on the
   NAS.  The 24-bit Transaction Identifier field MUST be set to a
   positive value.  Other fields in the general header MUST be set as
   described in Section 3.6.

Top      Up      ToC       Page 63 
   The handling of the various unused/reserved fields is described in
   Section 3.4.

   The remaining message fields are described as follows:

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

   X-Function (8 bits):  Qualifies the action set by Function.  For DSL
      access line configuration, this field MUST be set to 0.

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

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

   Reserved (16 bits):  Reserved for future use.

   # of TLVs (16 bits):  The number of TLVs that follow, not counting
      TLVs encapsulated within other TLVs.

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

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

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

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

Top      Up      ToC       Page 64 
7.4.  Procedures

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

7.4.1.  Procedures on the NAS Side

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

7.4.2.  Procedures on the AN Side

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

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

7.5.  TLVs for DSL Line Configuration

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

Top      Up      ToC       Page 65 
7.5.1.  Service-Profile-Name TLV

   Type:  0x0005

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

   Length:  Up to 64 bytes

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



(page 65 continued on part 4)

Next RFC Part