Subject: [ANCP] New text for access line identifiers

From: Tom Taylor <[email-masked]>
Date: Wed, 29 Dec 2010 09:42:37 -0500

I'm slowly chipping away at the base protocol document between family 
engagements. It occurred to me while I was doing so that, since the 
access-line-identifying TLVs are used by all the DSL capabilities, they 
should be documented in a section of their own ahead of the 
documentation of the individual capabilities. Here is the resulting text 
for your inspection.

---------------------------------------

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

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

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

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

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

  Wadhwa, et al.           Expires July 2, 2011                 [Page 27]

Internet-Draft                ANCP Protocol                December 2010

    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 discovery.  The choice of which identifiers
    to use and the values to place into them is made on a line-by-line
    basis, based on AN configuration and deployment considerations.  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 specified in Section 3.9.3 of
    [TR-101].  The syntax for the ASCII form of the NAS-side access line
    identifier will be similar.

    Aside from its use in ANCP signalling, access line identification is
    also used in DHCP 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) 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.

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

    Additional identification down to the user or host level is intended
    to supplement rather than replace either of the other two forms of
    identification.  This additional identification takes the form of an
    administered string which 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.  In addition, the NAS needs to
    build or have configured 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.

4.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].

    As a normative requirement, the AN-side ANCP agent MUST be able to
    create 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,
    and MUST be able to insert the resulting TLVs into the message with
    which they will be associated.  The NAS-side ANCP agent MUST be able
    to extract the relevant information from any of these four TLVs when
    it encounters them in a message, and pass that information to the NAS
    control application.

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

4.1.2.2.  Access-Loop-Remote-Id TLV

    Type:  0x0002

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

    Length:  up to 63 bytes

    Value:  ASCII string

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

    Type:  0x0006

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

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

       When the N:1 VLAN model is used, only one VLAN tag is available.
       In this case the Access-Loop-Circuit-ID TLV MUST also be present
       in the message to identify the access line uniquely.  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 case of an ATM aggregation network, where the DSLAM is directly
       connected to the NAS (without an intermediate ATM switch), the VPI
       and VCI on the DSLAM uplink correspond uniquely to the DSL line on
       the DSLAM.  The Access-Aggregation-Circuit-ID-Binary TLV MAY be
       used to carry the VPI and VCI.  The first value field of the TLV
       MUST carry the VCI, while the second value field MUST carry the
       VPI.

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

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

    Length:  4 or 8 bytes

    Value:  one or two 32-bit binary fields.

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

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

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