tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6320

 
 
 

Protocol for Access Node Control Mechanism in Broadband Networks

Part 4 of 4, p. 65 to 82
Prev RFC Part

 


prevText      Top      Up      ToC       Page 65 
8.  ANCP-Based DSL Remote Line Connectivity Testing

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

8.1.  Control Context (Informative)

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

   The request is passed in a Port Management (Operations,
   Administration, and Maintenance, OAM) message.  If the NAS control
   application has supplied test parameters, they are used; otherwise,
   the AN control application uses default test parameters.  If a loop
   count parameter provided by the NAS is outside the valid range, the
   AN does not execute the test, but returns a result indicating that
   the test has failed due to an invalid parameter.  If the test takes
   longer than the timeout value (default or provided by the NAS), the
   AN control application can return a failure result indicating timeout
   or else can send no response.  The AN control application can provide
   a human-readable string describing the test results, for both
   failures and successes.  If provided, this string is included in the
   response.  Responses always include the opaque data, if any, provided
   by the NAS control application.

   Figure 20 summarizes the interaction.

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

   CPE: Customer Premises Equipment
   EFM: Ethernet First Mile

                Figure 20: Message Flow for ANCP-Based OAM

8.2.  Protocol Requirements

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

8.2.1.  Protocol Requirements on the NAS Side

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

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

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

8.2.2.  Protocol Requirements on the AN Side

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

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

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

8.3.  Port Management (OAM) Message Format

   The Port Management message for DSL access line testing has the same
   format as for DSL access line configuration (see Section 7.3), with
   the following differences:

   o  The Result field in the request SHOULD be set to AckAll (0x2), to
      allow the NAS to receive the information contained in a successful
      test response.

   o  The Function field MUST be set to 9 (Remote Loopback).  (The
      X-Function field continues to be 0.)

   o  The appended TLVs in the extension value field include testing-
      related TLVs rather than subscriber service information.

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

Top      Up      ToC       Page 68 
    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=9   | 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)                ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                   Testing-related TLVs                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

8.4.  Procedures

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

8.4.1.  NAS-Side Procedures

   When requested by the NAS control application and presented with the
   necessary information to do so, the NAS-side agent creates and sends
   a Port Management (OAM) request with the fixed fields set as
   described in the previous section.  The message MUST contain one or

Top      Up      ToC       Page 69 
   more TLVs to identify an access line according the requirements of
   Section 5.1.2.  The NAS MAY include the Opaque-Data TLV and/or the
   OAM-Loopback-Test-Parameters TLV (defined in Section 8.5) to
   configure the loopback test for that line.

8.4.2.  AN-Side Procedures

   The AN-side ANCP agent SHOULD validate each message against the
   specifications given in Section 8.3 and the TLV specifications given
   in Sections 5.1.2 and 8.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.  Result Code value 0x509 as described below MAY apply, as well
   as the other Result Code values documented in Section 3.6.1.4.
   Result Code value 0x509 SHOULD be used if the OAM-Loopback-Test-
   Parameters TLV is present with an invalid value of the Count field.
   The AN-side agent MAY add a Status-Info TLV (Section 4.5) to provide
   further information on the error, particularly if this is recommended
   in Section 3.6.1.4 for the given Result Code value.  If it does so,
   the various length fields and the # of TLVs field within the message
   MUST be adjusted accordingly.

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

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

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

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

   0x503:  DSL access line status showtime

Top      Up      ToC       Page 70 
   0x504:  DSL access line status idle

   0x505:  DSL access line status silent

   0x506:  DSL access line status training

   0x507:  DSL access line integrity error

   0x508:  DSLAM resource not available.  The Result header field MUST
      be set to Failure (0x04).

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

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

8.5.  TLVs for the DSL Line Remote Connectivity Testing Capability

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

8.5.1.  OAM-Loopback-Test-Parameters TLV

   Type:  0x0007

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

   Length:  2 bytes

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

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

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

Top      Up      ToC       Page 71 
   The OAM-Loopback-Test-Parameters TLV is illustrated in Figure 22.

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

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

8.5.2.  Opaque-Data TLV

   Type:  0x0008

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

   Length:  8 bytes

   Value:  Two 32-bit unsigned integers.

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

   Type:  0x0009

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

   Length:  Up to 128 bytes

   Value:  UTF-8 encoded string of text.

9.  IANA Considerations

   This section documents the following IANA actions:

   o  establishment of the following new ANCP registries:

         ANCP Message Types;

         ANCP Result Codes;

Top      Up      ToC       Page 72 
         ANCP Port Management Functions;

         ANCP Technology Types;

         ANCP Command Codes;

         ANCP TLV Types;

         ANCP Capabilities.

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

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

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

10.  IANA Actions

10.1.  ANCP Message Type Registry

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

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

Top      Up      ToC       Page 73 
10.2.  ANCP Result Code Registry

   IANA has created a new registry, ANCP Result Codes.  The
   documentation of new Result Codes MUST include the following
   information:

   o  Result Code value (as assigned by IANA);

   o  One-line description;

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

   o  Further description (if any);

   o  Required additional information in the response message;

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

   o  Action RECOMMENDED for the receiving ANCP agent.

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

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

10.3.  ANCP Port Management Function Registry

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

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

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

Top      Up      ToC       Page 75 
10.4.  ANCP Technology Type Registry

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

      +-----------------+-------------------------------+-----------+
      | Tech Type Value | Tech Type Name                | Reference |
      +-----------------+-------------------------------+-----------+
      | 0               | Not technology dependent      | RFC 6320  |
      | 1               | Passive Optical Network (PON) | RFC 6320  |
      | 5               | Digital Subscriber Line (DSL) | RFC 6320  |
      | 255             | Reserved                      | RFC 6320  |
      +-----------------+-------------------------------+-----------+

10.5.  ANCP Command Code Registry

   IANA has created a new ANCP Command Code registry, with additions by
   Standards Action, as defined by [RFC5226].  Values may range from 0
   to 255.  IANA SHOULD assign new values sequentially beginning with 1.
   The initial entry is as follows:

     +--------------------+-----------------------------+-----------+
     | Command Code Value | Command Code Directive Name | Reference |
     +--------------------+-----------------------------+-----------+
     | 0                  | Reserved                    | RFC 6320  |
     +--------------------+-----------------------------+-----------+

10.6.  ANCP TLV Type Registry

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

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

   o  a brief description of the intended use;

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

   o  identification of any mandatory encapsulated TLVs;

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

   The initial entries are as follows:

   +----------+--------------------------------------------+-----------+
   | Type Code| TLV Name                                   | Reference |
   +----------+--------------------------------------------+-----------+
   | 0x0000   | Reserved                                   | RFC 6320  |
   | 0x0001   | Access-Loop-Circuit-ID                     | RFC 6320  |
   | 0x0002   | Access-Loop-Remote-ID                      | RFC 6320  |
   | 0x0003   | Access-Aggregation-Circuit-ID-ASCII        | RFC 6320  |
   | 0x0004   | DSL-Line-Attributes                        | RFC 6320  |
   | 0x0005   | Service-Profile-Name                       | RFC 6320  |
   | 0x0006   | Access-Aggregation-Circuit-ID-Binary       | RFC 6320  |
   | 0x0007   | OAM-Loopback-Test-Parameters               | RFC 6320  |
   | 0x0008   | Opaque-Data                                | RFC 6320  |
   | 0x0009   | OAM-Loopback-Test-Response-String          | RFC 6320  |
   | 0x0011   | Command                                    | RFC 6320  |
   | 0x0081   | Actual-Net-Data-Rate-Upstream              | RFC 6320  |
   | 0x0082   | Actual-Net-Data-Rate-Downstream            | RFC 6320  |
   | 0x0083   | Minimum-Net-Data-Rate-Upstream             | RFC 6320  |
   | 0x0084   | Minimum-Net-Data-Rate-Downstream           | RFC 6320  |
   | 0x0085   | Attainable-Net-Data-Rate-Upstream          | RFC 6320  |
   | 0x0086   | Attainable-Net-Data-Rate-Downstream        | RFC 6320  |
   | 0x0087   | Maximum-Net-Data-Rate-Upstream             | RFC 6320  |
   | 0x0088   | Maximum-Net-Data-Rate-Downstream           | RFC 6320  |
   | 0x0089   | Minimum-Net-Low-Power-Data-Rate-Upstream   | RFC 6320  |
   | 0x008A   | Minimum-Net-Low-Power-Data-Rate-Downstream | RFC 6320  |
   | 0x008B   | Maximum-Interleaving-Delay-Upstream        | RFC 6320  |
   | 0x008C   | Actual-Interleaving-Delay-Upstream         | RFC 6320  |
   | 0x008D   | Maximum-Interleaving-Delay-Downstream      | RFC 6320  |
   | 0x008E   | Actual-Interleaving-Delay-Downstream       | RFC 6320  |
   | 0x008F   | DSL-Line-State                             | RFC 6320  |
   | 0x0090   | Access-Loop-Encapsulation                  | RFC 6320  |
   | 0x0091   | DSL-Type                                   | RFC 6320  |
   | 0x0106   | Status-Info                                | RFC 6320  |
   | 0x1000   | Target (single access line variant)        | RFC 6320  |
   | 0x1001 - | Reserved for Target variants               | RFC 6320  |
   | 0x1020   |                                            |           |
   +----------+--------------------------------------------+-----------+

Top      Up      ToC       Page 77 
10.7.  ANCP Capability Type Registry

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

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

10.8.  Joint GSMP / ANCP Version Registry

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

                 +---------+----------------+-----------+
                 | Version | Description    | Reference |
                 +---------+----------------+-----------+
                 | 1       | GSMP Version 1 | RFC 1987  |
                 | 2       | GSMP Version 2 | RFC 2297  |
                 | 3       | GSMP Version 3 | RFC 3292  |
                 | 50      | ANCP Version 1 | RFC 6320  |
                 +---------+----------------+-----------+

11.  Security Considerations

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

Top      Up      ToC       Page 78 
   o  The protocol solution MUST offer authentication of the AN to the
      NAS.

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

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

   o  The protocol solution MUST offer replay protection.

   o  The protocol solution MUST provide data-origin authentication.

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

   o  The protocol solution SHOULD offer confidentiality protection.

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

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

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

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

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

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

12.  Contributors

   Swami Subramanian was an early member of the authors' team.  The ANCP
   Working Group is grateful to Roberta Maglione, who served as design
   team member and primary editor of this document for two years before
   stepping down.

13.  Acknowledgements

   The authors would like to thank everyone who provided comments or
   inputs to this document.  The authors acknowledge the inputs provided
   by Wojciech Dec, Peter Arberg, Josef Froehler, Derek Harkness, Kim
   Hyldgaard, Sandy Ng, Robert Peschi, and Michel Platnic, and the
   further comments provided by Mykyta Yevstifeyev, Brian Carter, Ben
   Campbell, Alexey Melnikov, Adrian Farrel, Robert Sparks, Peter St.
   Andre, Sean Turner, Dan Romascanu, Brian Carter, and Michael Scott.

14.  References

14.1.  Normative References

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

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

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

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

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

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

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

14.2.  Informative References

   [G.993.2]      "ITU-T Recommendation G.993.2, Very high speed digital
                  subscriber line transceivers 2 (VDSL2)", 2006.

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

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

   [IEEE802.1Q]   IEEE, "IEEE 802.1Q-2005, IEEE Standard for Local and
                  Metropolitan Area Networks - Virtual Bridged Local
                  Area Networks - Revision", 2005.

   [IEEE802.1ad]  IEEE, "IEEE 802.1ad-2005, Amendment to IEEE 802.1Q-
                  2005. IEEE Standard for Local and Metropolitan Area
                  Networks - Virtual Bridged Local Area Networks -
                  Revision - Amendment 4: Provider Bridges", 2005.

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

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

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

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

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

   [RFC5246]      Dierks, T. and E. Rescorla, "The Transport Layer
                  Security (TLS) Protocol Version 1.2", RFC 5246,
                  August 2008.

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

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

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

   [TR-058]       Broadband Forum, "TR-058, Multi-Service Architecture &
                  Framework Requirements", September 2003.

   [TR-059]       Broadband Forum, "TR-059, DSL Evolution - Architecture
                  Requirements for the Support of QoS-Enabled IP
                  Services", September 2003.

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

   [TR-101]       Broadband Forum, "TR-101, Architecture & Transport:
                  Migration to Ethernet Based DSL Aggregation", 2005.

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

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

Top      Up      ToC       Page 82 
Authors' Addresses

   Sanjay Wadhwa
   Alcatel-Lucent
   701 E Middlefield Rd
   Mountain View, CA  94043-4079
   USA

   EMail: sanjay.wadhwa@alcatel-lucent.com


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

   EMail: jmoisand@juniper.net


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

   EMail: haagt@telekom.de


   Norbert Voigt
   Nokia Siemens Networks
   Siemensallee 1
   Greifswald  17489
   Germany

   EMail: norbert.voigt@nsn.com


   Tom Taylor (editor)
   Huawei Technologies
   1852 Lorraine Ave
   Ottawa
   Canada

   EMail: tom111.taylor@bell.net