RFC 6320
Protocol for Access Node Control Mechanism in Broadband Networks
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.
+-------------+ +-----+ +-------+ +----------------+ |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 OAM8.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.
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.
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 Testing8.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
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
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.
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 TLV8.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;
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 |
+--------------+--------------------+-----------+
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:
+------------+------------------------------------------+-----------+ | 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 | +----------------+-----------------------------------+-----------+
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;
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 | | |
+----------+--------------------------------------------+-----------+
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:
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.
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.
[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.
[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.
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