Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6320

Protocol for Access Node Control Mechanism in Broadband Networks

Pages: 82
Proposed Standard
Updated by:  7256
Part 3 of 4 – Pages 38 to 65
First   Prev   Next

Top   ToC   RFC6320 - Page 38   prevText

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   ToC   RFC6320 - 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   ToC   RFC6320 - 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   ToC   RFC6320 - 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   ToC   RFC6320 - 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   ToC   RFC6320 - 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   ToC   RFC6320 - 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   ToC   RFC6320 - 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   ToC   RFC6320 - 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   ToC   RFC6320 - 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   ToC   RFC6320 - 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   ToC   RFC6320 - 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   ToC   RFC6320 - 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   ToC   RFC6320 - 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   ToC   RFC6320 - 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   ToC   RFC6320 - 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   ToC   RFC6320 - 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   ToC   RFC6320 - 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   ToC   RFC6320 - 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   ToC   RFC6320 - 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   ToC   RFC6320 - 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   ToC   RFC6320 - 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   ToC   RFC6320 - 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   ToC   RFC6320 - 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   ToC   RFC6320 - 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   ToC   RFC6320 - 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   ToC   RFC6320 - 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   ToC   RFC6320 - 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 Section