draft-ietf-ancp-protocol-15.txt   draft-ietf-ancp-protocol-16.txt 
Network Working Group S. Wadhwa Network Working Group S. Wadhwa
Internet-Draft Alcatel-Lucent Internet-Draft Alcatel-Lucent
Intended status: Standards Track J. Moisand Intended status: Standards Track J. Moisand
Expires: August 6, 2011 Juniper Networks Expires: October 20, 2011 Juniper Networks
T. Haag T. Haag
Deutsche Telekom Deutsche Telekom
N. Voigt N. Voigt
Nokia Siemens Networks Nokia Siemens Networks
T. Taylor, Ed. T. Taylor, Ed.
Huawei Technologies Huawei Technologies
February 2, 2011 April 18, 2011
Protocol for Access Node Control Mechanism in Broadband Networks Protocol for Access Node Control Mechanism in Broadband Networks
draft-ietf-ancp-protocol-15 draft-ietf-ancp-protocol-16
Abstract Abstract
This document describes the Access Node Control Protocol (ANCP). This document describes the Access Node Control Protocol (ANCP).
ANCP operates between a Network Access Server (NAS) and an Access ANCP operates between a Network Access Server (NAS) and an Access
Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in
a multi-service reference architecture in order to perform QoS- a multi-service reference architecture in order to perform QoS-
related, service-related and subscriber-related operations. Use related, service-related and subscriber-related operations. Use
cases for ANCP are documented in RFC 5851. As well as describing the cases for ANCP are documented in RFC 5851. As well as describing the
base ANCP protocol, this document specifies capabilities for Digital base ANCP protocol, this document specifies capabilities for Digital
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 6, 2011. This Internet-Draft will expire on October 20, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 7 skipping to change at page 3, line 7
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 1.1. Historical Note . . . . . . . . . . . . . . . . . . . . . 7
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 7
2. Broadband Access Aggregation . . . . . . . . . . . . . . . . . 8 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. ATM-based Broadband Aggregation . . . . . . . . . . . . . 8 2. Broadband Access Aggregation . . . . . . . . . . . . . . . . . 9
2.1. ATM-based Broadband Aggregation . . . . . . . . . . . . . 9
2.2. Ethernet-Based Broadband Aggregation . . . . . . . . . . . 10 2.2. Ethernet-Based Broadband Aggregation . . . . . . . . . . . 10
3. Access Node Control Protocol -- General Aspects . . . . . . . 10 3. Access Node Control Protocol -- General Aspects . . . . . . . 11
3.1. Protocol Version . . . . . . . . . . . . . . . . . . . . . 10 3.1. Protocol Version . . . . . . . . . . . . . . . . . . . . . 11
3.2. ANCP Transport . . . . . . . . . . . . . . . . . . . . . . 11 3.2. ANCP Transport . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Encoding of Text Fields . . . . . . . . . . . . . . . . . 12 3.3. Encoding of Text Fields . . . . . . . . . . . . . . . . . 12
3.4. Treatment of Reserved and Unused Fields . . . . . . . . . 12 3.4. Treatment of Reserved and Unused Fields . . . . . . . . . 12
3.5. Use of the GSMPv3 Adjacency Protocol . . . . . . . . . . . 12 3.5. The ANCP Adjacency Protocol . . . . . . . . . . . . . . . 13
3.5.1. ANCP Adjacency Message Format . . . . . . . . . . . . 12 3.5.1. ANCP Adjacency Message Format . . . . . . . . . . . . 13
3.5.2. ANCP Adjacency Procedures . . . . . . . . . . . . . . 15 3.5.2. ANCP Adjacency Procedures . . . . . . . . . . . . . . 19
3.6. ANCP General Message Formats . . . . . . . . . . . . . . . 17 3.6. ANCP General Message Formats . . . . . . . . . . . . . . . 29
3.6.1. The ANCP Message Header . . . . . . . . . . . . . . . 17 3.6.1. The ANCP Message Header . . . . . . . . . . . . . . . 29
3.6.2. The ANCP Message Body . . . . . . . . . . . . . . . . 25 3.6.2. The ANCP Message Body . . . . . . . . . . . . . . . . 36
3.7. General Principles for the Design of ANCP Messages . . . . 26 3.7. General Principles for the Design of ANCP Messages . . . . 37
4. Generally Useful ANCP Messages and TLVs . . . . . . . . . . . 27 4. Generally Useful ANCP Messages and TLVs . . . . . . . . . . . 38
4.1. Provisioning Message . . . . . . . . . . . . . . . . . . . 27 4.1. Provisioning Message . . . . . . . . . . . . . . . . . . . 38
4.2. Generic Response Message . . . . . . . . . . . . . . . . . 28 4.2. Generic Response Message . . . . . . . . . . . . . . . . . 39
4.3. Target TLV . . . . . . . . . . . . . . . . . . . . . . . . 30 4.3. Target TLV . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4. Command TLV . . . . . . . . . . . . . . . . . . . . . . . 30 4.4. Command TLV . . . . . . . . . . . . . . . . . . . . . . . 41
4.5. Status-Info TLV . . . . . . . . . . . . . . . . . . . . . 31 4.5. Status-Info TLV . . . . . . . . . . . . . . . . . . . . . 42
5. Introduction To ANCP Capabilities For Digital Subscriber 5. Introduction To ANCP Capabilities For Digital Subscriber
Lines (DSL) . . . . . . . . . . . . . . . . . . . . . . . . . 32 Lines (DSL) . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.1. DSL Access Line Identification . . . . . . . . . . . . . . 33 5.1. DSL Access Line Identification . . . . . . . . . . . . . . 44
5.1.1. Control Context (Informative) . . . . . . . . . . . . 33 5.1.1. Control Context (Informative) . . . . . . . . . . . . 44
5.1.2. TLVs For DSL Access Line Identification . . . . . . . 34 5.1.2. TLVs For DSL Access Line Identification . . . . . . . 45
6. ANCP Based DSL Topology Discovery . . . . . . . . . . . . . . 37 6. ANCP Based DSL Topology Discovery . . . . . . . . . . . . . . 48
6.1. Control Context (Informative) . . . . . . . . . . . . . . 37 6.1. Control Context (Informative) . . . . . . . . . . . . . . 48
6.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 39 6.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 50
6.2.1. Protocol Requirements On the AN Side . . . . . . . . . 39 6.2.1. Protocol Requirements On the AN Side . . . . . . . . . 50
6.2.2. Protocol Requirements On the NAS Side . . . . . . . . 40 6.2.2. Protocol Requirements On the NAS Side . . . . . . . . 50
6.3. ANCP Port UP and Port DOWN Event Message Descriptions . . 40 6.3. ANCP Port UP and Port DOWN Event Message Descriptions . . 51
6.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 42 6.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 52
6.4.1. Procedures On the AN Side . . . . . . . . . . . . . . 42 6.4.1. Procedures On the AN Side . . . . . . . . . . . . . . 52
6.4.2. Procedures On the NAS Side . . . . . . . . . . . . . . 43 6.4.2. Procedures On the NAS Side . . . . . . . . . . . . . . 53
6.5. TLVs For DSL Line Attributes . . . . . . . . . . . . . . . 43 6.5. TLVs For DSL Line Attributes . . . . . . . . . . . . . . . 53
6.5.1. DSL-Line-Attributes TLV . . . . . . . . . . . . . . . 43 6.5.1. DSL-Line-Attributes TLV . . . . . . . . . . . . . . . 53
6.5.2. DSL-Type TLV . . . . . . . . . . . . . . . . . . . . . 44 6.5.2. DSL-Type TLV . . . . . . . . . . . . . . . . . . . . . 54
6.5.3. Actual-Net-Data-Rate-Upstream TLV . . . . . . . . . . 44 6.5.3. Actual-Net-Data-Rate-Upstream TLV . . . . . . . . . . 54
6.5.4. Actual-Net-Data-Rate-Downstream TLV . . . . . . . . . 44 6.5.4. Actual-Net-Data-Rate-Downstream TLV . . . . . . . . . 54
6.5.5. Minimum-Net-Data-Rate-Upstream TLV . . . . . . . . . . 45 6.5.5. Minimum-Net-Data-Rate-Upstream TLV . . . . . . . . . . 55
6.5.6. Minimum-Net-Data-Rate-Downstream TLV . . . . . . . . . 45 6.5.6. Minimum-Net-Data-Rate-Downstream TLV . . . . . . . . . 55
6.5.7. Attainable-Net-Data-Rate-Upstream TLV . . . . . . . . 45 6.5.7. Attainable-Net-Data-Rate-Upstream TLV . . . . . . . . 55
6.5.8. Attainable-Net-Data-Rate-Downstream TLV . . . . . . . 45 6.5.8. Attainable-Net-Data-Rate-Downstream TLV . . . . . . . 55
6.5.9. Maximum-Net-Data-Rate-Upstream TLV . . . . . . . . . . 46 6.5.9. Maximum-Net-Data-Rate-Upstream TLV . . . . . . . . . . 56
6.5.10. Maximum-Net-Data-Rate-Downstream TLV . . . . . . . . . 46 6.5.10. Maximum-Net-Data-Rate-Downstream TLV . . . . . . . . . 56
6.5.11. Minimum-Net-Low-Power-Data-Rate-Upstream TLV . . . . . 46 6.5.11. Minimum-Net-Low-Power-Data-Rate-Upstream TLV . . . . . 56
6.5.12. Minimum-Net-Low-Power-Data-Rate-Downstream TLV . . . . 46 6.5.12. Minimum-Net-Low-Power-Data-Rate-Downstream TLV . . . . 56
6.5.13. Maximum-Interleaving-Delay-Upstream TLV . . . . . . . 47 6.5.13. Maximum-Interleaving-Delay-Upstream TLV . . . . . . . 57
6.5.14. Actual-Interleaving-Delay-Upstream TLV . . . . . . . . 47 6.5.14. Actual-Interleaving-Delay-Upstream TLV . . . . . . . . 57
6.5.15. Maximum-Interleaving-Delay-Downstream TLV . . . . . . 47 6.5.15. Maximum-Interleaving-Delay-Downstream TLV . . . . . . 57
6.5.16. Actual-Interleaving-Delay-Downstream . . . . . . . . . 47 6.5.16. Actual-Interleaving-Delay-Downstream . . . . . . . . . 57
6.5.17. DSL-Line-State TLV . . . . . . . . . . . . . . . . . . 47 6.5.17. DSL-Line-State TLV . . . . . . . . . . . . . . . . . . 57
6.5.18. Access-Loop-Encapsulation TLV . . . . . . . . . . . . 48 6.5.18. Access-Loop-Encapsulation TLV . . . . . . . . . . . . 58
7. ANCP based DSL Line Configuration . . . . . . . . . . . . . . 49 7. ANCP based DSL Line Configuration . . . . . . . . . . . . . . 59
7.1. Control Context (Informative) . . . . . . . . . . . . . . 49 7.1. Control Context (Informative) . . . . . . . . . . . . . . 59
7.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 50 7.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 60
7.2.1. Protocol Requirements On the NAS Side . . . . . . . . 51 7.2.1. Protocol Requirements On the NAS Side . . . . . . . . 61
7.2.2. Protocol Requirements On the AN Side . . . . . . . . . 51 7.2.2. Protocol Requirements On the AN Side . . . . . . . . . 61
7.3. ANCP Port Management (Line Configuration) Message 7.3. ANCP Port Management (Line Configuration) Message
Format . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Format . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 54 7.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 64
7.4.1. Procedures On the NAS Side . . . . . . . . . . . . . . 54 7.4.1. Procedures On the NAS Side . . . . . . . . . . . . . . 64
7.4.2. Procedures On the AN Side . . . . . . . . . . . . . . 54 7.4.2. Procedures On the AN Side . . . . . . . . . . . . . . 64
7.5. TLVs For DSL Line Configuration . . . . . . . . . . . . . 55 7.5. TLVs For DSL Line Configuration . . . . . . . . . . . . . 65
7.5.1. Service-Profile-Name TLV . . . . . . . . . . . . . . . 55 7.5.1. Service-Profile-Name TLV . . . . . . . . . . . . . . . 65
8. ANCP-Based DSL Remote Line Connectivity Testing . . . . . . . 55 8. ANCP-Based DSL Remote Line Connectivity Testing . . . . . . . 65
8.1. Control Context (Informative) . . . . . . . . . . . . . . 55 8.1. Control Context (Informative) . . . . . . . . . . . . . . 65
8.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 56 8.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 66
8.2.1. Protocol Requirements On the NAS Side . . . . . . . . 56 8.2.1. Protocol Requirements On the NAS Side . . . . . . . . 66
8.2.2. Protocol Requirements On the AN Side . . . . . . . . . 57 8.2.2. Protocol Requirements On the AN Side . . . . . . . . . 66
8.3. Port Management (OAM) Message Format . . . . . . . . . . . 57 8.3. Port Management (OAM) Message Format . . . . . . . . . . . 67
8.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 58 8.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 68
8.4.1. NAS-Side Procedures . . . . . . . . . . . . . . . . . 58 8.4.1. NAS-Side Procedures . . . . . . . . . . . . . . . . . 68
8.4.2. AN-Side Procedures . . . . . . . . . . . . . . . . . . 59 8.4.2. AN-Side Procedures . . . . . . . . . . . . . . . . . . 69
8.5. TLVs For the DSL Line Remote Connectivity Testing 8.5. TLVs For the DSL Line Remote Connectivity Testing
Capability . . . . . . . . . . . . . . . . . . . . . . . . 60 Capability . . . . . . . . . . . . . . . . . . . . . . . . 70
8.5.1. OAM-Loopback-Test-Parameters TLV . . . . . . . . . . . 60 8.5.1. OAM-Loopback-Test-Parameters TLV . . . . . . . . . . . 70
8.5.2. Opaque-Data TLV . . . . . . . . . . . . . . . . . . . 61 8.5.2. Opaque-Data TLV . . . . . . . . . . . . . . . . . . . 71
8.5.3. OAM-Loopback-Test-Response-String TLV . . . . . . . . 61 8.5.3. OAM-Loopback-Test-Response-String TLV . . . . . . . . 71
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71
9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 61 9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 72
9.2. IANA Actions . . . . . . . . . . . . . . . . . . . . . . . 62 9.2. IANA Actions . . . . . . . . . . . . . . . . . . . . . . . 72
10. Security Considerations . . . . . . . . . . . . . . . . . . . 67 9.2.1. ANCP Message Type Registry . . . . . . . . . . . . . . 72
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 69 9.2.2. ANCP Result Code Registry . . . . . . . . . . . . . . 73
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69 9.2.3. ANCP Port Management Function Registry . . . . . . . . 74
12.1. Normative References . . . . . . . . . . . . . . . . . . . 69 9.2.4. ANCP Technology Type Registry . . . . . . . . . . . . 75
12.2. Informative References . . . . . . . . . . . . . . . . . . 69 9.2.5. ANCP Command Code Registry . . . . . . . . . . . . . . 75
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70 9.2.6. ANCP TLV Type Registry . . . . . . . . . . . . . . . . 75
9.2.7. ANCP Capability Type Registry . . . . . . . . . . . . 77
9.2.8. Joint GSMP / ANCP Version Registry . . . . . . . . . . 77
10. Security Considerations . . . . . . . . . . . . . . . . . . . 78
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 79
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 80
12.1. Normative References . . . . . . . . . . . . . . . . . . . 80
12.2. Informative References . . . . . . . . . . . . . . . . . . 80
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 82
1. Introduction 1. Introduction
This draft defines a new protocol, the Access Node Control Protocol This draft defines a new protocol, the Access Node Control Protocol
(ANCP), to realize a control plane between a service-oriented layer 3 (ANCP), to realize a control plane between a service-oriented layer 3
edge device (the Network Access Server, NAS) and a layer 2 Access edge device (the Network Access Server, NAS) and a layer 2 Access
Node (e.g., Digital Subscriber Line Access Module, DSLAM) in order to Node (e.g., Digital Subscriber Line Access Module, DSLAM) in order to
perform QoS-related, service-related and subscriber-related perform operations related to quality of service (QoS), services, and
operations. The requirements for ANCP and the context within which subscriptions. The requirements for ANCP and the context within
it operates are described in [RFC5851]. which it operates are described in [RFC5851].
The protocol specification takes GSMPv3 [RFC3292] as a starting
point, and the implementor is directed to parts of [RFC3292] for the
specification of some aspects of the protocol. However, ANCP
introduces so many extensions and modifications to GSMPv3 that the
two protocols are not interoperable.
ANCP provides its services to control applications operating in the ANCP provides its services to control applications operating in the
AN and NAS respectively. This relationship is shown in Figure 1. AN and NAS respectively. This relationship is shown in Figure 1.
Specification of the control applications is beyond the scope of this Specification of the control applications is beyond the scope of this
document, but informative partial descriptions are provided as document, but informative partial descriptions are provided as
necessary to give a context for the operation of the protocol. necessary to give a context for the operation of the protocol.
Access Node Network Access Server Access Node Network Access Server
+--------------------+ +--------------------+ +--------------------+ +--------------------+
| +----------------+ | | +----------------+ | | +----------------+ | | +----------------+ |
skipping to change at page 5, line 49 skipping to change at page 6, line 43
Figure 1: Architectural Context For the Access Node Control Protocol Figure 1: Architectural Context For the Access Node Control Protocol
At various points in this document, information flows between the At various points in this document, information flows between the
control applications and ANCP are described. The purpose of such control applications and ANCP are described. The purpose of such
descriptions is to clarify the boundary between this specification descriptions is to clarify the boundary between this specification
and, for example, [TR-147]. There is no intention to place limits on and, for example, [TR-147]. There is no intention to place limits on
the degree to which the control application and the protocol the degree to which the control application and the protocol
implementation are integrated. implementation are integrated.
This specification specifies ANCP transport over TCP/IP. TCP This specification specifies ANCP transport over TCP/IP. TCP
encapsulation for ANCP is as defined for GSMPv3 in [RFC3293]. The encapsulation for ANCP is as defined in Section 3.2.
alternative GSMPv3 encapsulation directly over Ethernet and ATM as
defined in [RFC3293] is not considered for ANCP.
The organization of this document is as follows: The organization of this document is as follows:
o The next two sub-sections introduce some terminology that will be o The next two sub-sections introduce some terminology that will be
useful in understanding the rest of the document. useful in understanding the rest of the document.
o Section 2 provides a description of the access networks within o Section 2 provides a description of the access networks within
which ANCP will typically be deployed. which ANCP will typically be deployed.
o Section 3 specifies generally applicable aspects of the ANCP o Section 3 specifies generally applicable aspects of the ANCP
protocol. protocol.
o Section 4 specifies some messages and TLVs intended for use by o Section 4 specifies some messages and TLVs intended for use by
multiple capabilities spanning multiple technologies. multiple capabilities spanning multiple technologies.
o Section 5 and the three following sections describe and specify o Section 5 and the three following sections describe and specify
the ANCP implementation of three capabilities applicable to the the ANCP implementation of three capabilities applicable to the
control of DSL access technology: topology discovery, line control of DSL access technology: topology discovery, line
configuration, and remote line connectivity testing. configuration, and remote line connectivity testing.
o Section 9 is the IANA Considerations section. Some codepoints are o Section 9 is the IANA Considerations section. This section
added to existing GSMPv3 registries set up by [RFC3292], but a defines a number of new ANCP-specific registries, as well as the
number of new ANCP-specific registries are also defined. joint GSMP/ANCP version registry mentioned below.
o Section 10 addresses security considerations relating to ANCP, o Section 10 addresses security considerations relating to ANCP,
beginning with the requirements stated in [RFC5713]. beginning with the requirements stated in [RFC5713].
RFC EDITOR'S NOTE: the following paragraph should be deleted upon 1.1. Historical Note
publication.
At the time of writing of this specification some implementations of Initial implementations of the protocol that became ANCP were based
the ANCP protocol based on pre-standards drafts are already on GSMPv3 [RFC3292]. The ANCP charter required the Working Group to
available. These early-draft implementations use protocol version/ develop its protocol based on these implementations. In the end,
sub-version 3.1. The standard ANCP protocol will use version/ ANCP introduced so many extensions and modifications to GSMPv3 that
sub-version 3.2 Adopting a new sub-version value provides a way to the two protocols are not interoperable. Nevertheless, although this
disambiguate the two protocols and provides support for running a specification has no normative dependencies on [RFC3292], the mark of
pre-standard and a standards compliant ANCP implementation on any ANCP's origins can be seen in the various unused fields within the
given ANCP node. The mechanism used to identify the protocol ANCP message header.
version/sub-version is part of the adjacency negotiation process and
it is described in detail in Section 3.5. NOTE: this mechanism does
not guarantee backwards compatibility of the published ANCP
specification with those early-draft implementations.
1.1. Requirements Language Early in ANCP's development the decision was made to use the same TCP
port and encapsulation as GSMPv3, and by the time ANCP was finished
it was too late to reverse that decision because of existing
implementations. As a result, it is necessary to have a way for an
ANCP peer to quickly distinguish ANCP from GSMP during initial
adjacency negotiations. This has been provided by a joint registry
of GSMP and ANCP version numbers. GSMP has version numbers 1 through
3. ANCP has the initial version number 50.
1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This specification uses requirements language in lower case and 1.3. Terminology
between quotation marks (e.g., "must") to denote requirements on the
interface between ANCP and the control application. Such
requirements are inherently untestable but need to be taken into
account by the implementor.
1.2. Terminology
This section repeats some definitions from [RFC5851], but also adds This section repeats some definitions from [RFC5851], but also adds
definitions for terms used only in this document. definitions for terms used only in this document.
Access Node (AN): [RFC5851] Network device, usually located at a Access Node (AN): [RFC5851] Network device, usually located at a
service provider central office or street cabinet that terminates service provider central office or street cabinet that terminates
access (local) loop connections from subscribers. In case the access (local) loop connections from subscribers. In case the
access loop is a Digital Subscriber Line (DSL), the Access Node access loop is a Digital Subscriber Line (DSL), the Access Node
provides DSL signal termination, and is referred to as a DSL provides DSL signal termination, and is referred to as a DSL
Access Multiplexer (DSLAM). Access Multiplexer (DSLAM).
skipping to change at page 10, line 30 skipping to change at page 11, line 15
form of "virtual circuit" on a per DSL line basis. This is the 1:1 form of "virtual circuit" on a per DSL line basis. This is the 1:1
VLAN allocation model. An alternative model is to bridge sessions VLAN allocation model. An alternative model is to bridge sessions
from multiple subscribers behind a DSLAM into a single VLAN in the from multiple subscribers behind a DSLAM into a single VLAN in the
aggregation network. This is the N:1 VLAN allocation model. Section aggregation network. This is the N:1 VLAN allocation model. Section
1.6 of [TR-101] provides brief definitions of these two models, while 1.6 of [TR-101] provides brief definitions of these two models, while
section 2.5.1 describes them in more detail. section 2.5.1 describes them in more detail.
3. Access Node Control Protocol -- General Aspects 3. Access Node Control Protocol -- General Aspects
This section specifies aspects of the Access Node Control Protocol This section specifies aspects of the Access Node Control Protocol
(ANCP) that are generally applicable. As indicated above, ANCP is (ANCP) that are generally applicable.
derived from GSMPv3 [RFC3292]. Reference to [RFC3292] is made where
this is applicable, but ANCP introduces numerous modifications and
extensions to the basic GSMPv3 protocol. Moreover, ANCP uses only a
subset of the messages, message contents, and procedures defined for
GSMPv3, and defines additional messages, message contents, and
procedures that are specific to ANCP.
3.1. Protocol Version 3.1. Protocol Version
GSMPv3 messages contain an 8-bit protocol version field. As ANCP messages contain an 8-bit protocol version field. For the
described below, ANCP subdivides this into two 4-bit sub-fields, for protocol version specified in this document, the value of that field
version and sub-version. Implementations of this version of the ANCP MUST be set to 50.
specification MUST set the version sub-field to 3 and the sub-version
sub-field to 1. That is, the hexadecimal representation of the value
of the complete protocol version field MUST be 0x31.
RFC EDITOR'S NOTE: please change the value of sub-version in the
above paragraph to 2 (respectively a version field value of 0x32) in
the published specification. For an explanation see the Introduction
above.
3.2. ANCP Transport 3.2. ANCP Transport
This document specifies the use of TCP/IP for transport of ANCP This document specifies the use of TCP / IPSec+IKEv2 / IP for
messages. Other specifications may introduce additional transports transport of ANCP messages. For further discussion of the use of
in the future. IPSec + IKEv2 see Section 10. The present section deals with the TCP
aspects. Other specifications may introduce additional transports in
the future.
In the case of ATM access, a separate PVC (control channel) In the case of ATM access, a separate PVC (control channel)
capable of transporting IP MAY be configured between NAS and the capable of transporting IP MAY be configured between NAS and the
AN for ANCP messages. AN for ANCP messages.
In the case of an Ethernet access/aggregation network, a typical In the case of an Ethernet access/aggregation network, a typical
practice is to send the Access Node Control Protocol messages over practice is to send the Access Node Control Protocol messages over
a dedicated Ethernet virtual LAN (VLAN) using a separate VLAN a dedicated Ethernet virtual LAN (VLAN) using a separate VLAN
identifier (VLAN ID). identifier (VLAN ID).
When transported over TCP, ANCP messages MUST use the encapsulation When transported over TCP, ANCP messages MUST use an encapsulation
specified for GSMPv3 messages carried over TCP in [RFC3293]. This consisting of a four-byte header field prepended to the ANCP message
encapsulation consists of a four-byte header field prepended to the as shown in Figure 3.
ANCP message as shown in Figure 3.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier (0x880C) | Length | | Identifier (0x880C) | Length |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ ANCP Message ~ ~ ANCP Message ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Encapsulation of ANCP Messages Over TCP/IP Figure 3: Encapsulation of ANCP Messages Over TCP/IP
The fields of the encapsulating header are as follows: The fields of the encapsulating header are as follows:
Identifier: This 2-byte field identifies a GSMP or ANCP message. Identifier (16 bits): This identifies a GSMP or ANCP message. It
The type code for GSMP and ANCP messages is 0x880C (i.e., the same MUST be set to 0x880C.
as GSMP's Ethertype).
Length: This 2-byte unsigned integer indicates the total length of Length (16 bits): Total length of the ANCP message in bytes, not
the ANCP message, not including the 4-byte encapsulating header. including the 4-byte encapsulating header.
The Access Node MUST initiate the TCP session to the NAS. This is a The Access Node MUST initiate the TCP session to the NAS, using
deviation from [RFC3293], which requires the controller to initiate destination port 6068.
the TCP connection to the switch.
This is necessary to avoid static address provisioning on the NAS This is necessary to avoid static address provisioning on the NAS
for all the ANs that are being served by the NAS. It is easier to for all the ANs that are being served by the NAS. It is easier to
configure a given AN with the single IP address of the NAS that configure a given AN with the single IP address of the NAS that
serves the AN. serves the AN.
The NAS MUST listen for incoming connections from the Access Nodes. The NAS MUST listen on port 6068 for incoming connections from the
Port 6068 is used for TCP connection. Access Nodes.
In the event of an ANCP transport protocol failure, all pending ANCP In the event of an ANCP transport protocol failure, all pending ANCP
messages destined to the disconnected recipient SHOULD be discarded messages destined to the disconnected recipient SHOULD be discarded
until the transport connection is re-established. until the transport connection is re-established.
3.3. Encoding of Text Fields 3.3. Encoding of Text Fields
In ANCP, all text fields use UTF-8 encoding [RFC3629]. Note that US In ANCP, all text fields use UTF-8 encoding [RFC3629]. Note that US
ASCII characters have the same representation when coded as UTF-8 as ASCII characters have the same representation when coded as UTF-8 as
they do when coded according to [US_ASCII]. they do when coded according to [US_ASCII].
skipping to change at page 12, line 36 skipping to change at page 13, line 14
from GSMPv3 but are not useful in the ANCP context). Others are from GSMPv3 but are not useful in the ANCP context). Others are
reserved in the current specification, but are provided for reserved in the current specification, but are provided for
flexibility in future extensions to ANCP. Both reserved and unused flexibility in future extensions to ANCP. Both reserved and unused
fields MUST be set to zeroes by the sender and MUST be ignored by the fields MUST be set to zeroes by the sender and MUST be ignored by the
receiver. receiver.
Unused bits in a flag field are shown in figures as 'x'. The above Unused bits in a flag field are shown in figures as 'x'. The above
requirement (sender set to zero, receiver ignore) applies to such requirement (sender set to zero, receiver ignore) applies to such
unused bits. unused bits.
3.5. Use of the GSMPv3 Adjacency Protocol 3.5. The ANCP Adjacency Protocol
Section 11 of [RFC3292] defines the GSMPv3 adjacency protocol. ANCP ANCP uses the adjacency protocol to synchronize the NAS and Access
reuses the GSMPv3 adjacency protocol to synchronize the NAS and Nodes and maintain the ANCP session. After the TCP connection is
Access Nodes and maintain the ANCP session. After the TCP connection established, adjacency protocol messages MUST be exchanged as
is established, adjacency protocol messages MUST be exchanged as specified in this section. ANCP messages other than adjacency
specified in Section 11 of [RFC3292], subject to the additional
specifications of this section. ANCP messages other than adjacency
protocol messages MUST NOT be sent until the adjacency protocol has protocol messages MUST NOT be sent until the adjacency protocol has
achieved synchronization. achieved synchronization.
3.5.1. ANCP Adjacency Message Format 3.5.1. ANCP Adjacency Message Format
The GSMPv3 adjacency message format defined in Section 11 of The ANCP adjacency message format is shown in Figure 4 below.
[RFC3292] is modified and extended for ANCP as shown in Figure 4
below. The 8-bit "version" field in the GSMPv3 adjacency protocol
messages is modified to carry the ANCP version (four bits) and sub-
version (four bits). See Section 3.1 for the values to set for
version and sub-version for the present version of this
specification.
The semantics and suggested values for the Code, Sender Name,
Receiver Name, Sender Instance, and Receiver Instance fields are as
defined in Section 11 of [RFC3292]. The Sender Port, and Receiver
Port SHOULD be set to 0 by both ends. The pType field MAY be set to
0 (No Partition) or another value depending on local configuration.
The pFlag SHOULD be set to 1 (New Adjacency).
In addition to the modification of the version field, ANCP adds
several new fields. These are described below the figure.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Sub | Message Type | Timer |M| Code | | Version | Message Type | Timer |M| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Name | | Sender Name |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Receiver Name | | Receiver Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Port | | Sender Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Port | | Receiver Port |
skipping to change at page 13, line 47 skipping to change at page 14, line 33
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | # of Caps | Total Length | | Reserved | # of Caps | Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Capability Fields ~ ~ Capability Fields ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: ANCP Adjacency Message Format Figure 4: ANCP Adjacency Message Format
The fields added by ANCP are as follows: The fields of the ANCP adjacency message are as follows:
Version (8 bits): ANCP version, which is subject to negotiation.
This is the key parameter by means of which ANCP messages can be
distinguished from GSMP messages received over the same port.
Message Type (8 bits): always has value 10 (adjacency protocol).
Timer (8 bits): The Timer field is used to negotiate the timer value
used in the adjacency protocol with the peer. The timer specifies
the nominal time between periodic adjacency protocol messages. It
is a constant for the duration of an ANCP session. The timer
field is specified in units of 100ms, with a default value of 250
(i.e., 25 seconds).
M-flag (one bit): used in the SYN message to prevent the NAS from
synchronizing with another NAS, and the AN from synchronizing with
another AN. In the SYN message, always set to 1 by the NAS, and
to 0 by the AN. In other adjacency message types, always set to 0
by the sender and ignored by the receiver.
Code (7 bits): the adjacency protocol message type. It MUST have
one of the following values:
Code = 1: SYN;
Code = 2: SYNACK;
Code = 3: ACK;
Code = 4: RSTACK.
Sender Name (48 bits): For the SYN, SYNACK, and ACK messages, is the
identifier of the entity sending the message. The Sender Name is
a 48-bit quantity that is unique within the operational context of
the device. A 48-bit IEEE 802 MAC address, if available, may be
used for the Sender Name. If the Ethernet encapsulation is used
the Sender Name MUST be the Source Address from the MAC header.
For the RSTACK message, the Sender Name field is set to the value
of the Receiver Name field from the incoming message that caused
the RSTACK message to be generated.
Receiver Name (48 bits) for the SYN, SYNACK, and ACK messages, is
the name of the entity that the sender of the message believes is
at the far end of the link. If the sender of the message does not
know the name of the entity at the far end of the link, this field
SHOULD be set to zero. For the RSTACK message, the Receiver Name
field is set to the value of the Sender Name field from the
incoming message that caused the RSTACK message to be generated.
Sender Port (32 bits): For the SYN, SYNACK, and ACK messages, is the
local port number of the link across which the message is being
sent. For the RSTACK message, the Sender Port field is set to the
value of the Receiver Port field from the incoming message that
caused the RSTACK message to be generated.
Receiver Port (32 bits): For the SYN, SYNACK, and ACK messages, is
what the sender believes is the local port number for the link,
allocated by the entity at the far end of the link. If the sender
of the message does not know the port number at the far end of the
link, this field SHOULD be set to zero. For the RSTACK message,
the Receiver Port field is set to the value of the Sender Port
field from the incoming message that caused the RSTACK message to
be generated.
PType (4 bits): PType is used to specify if partitions are used and
how the Partition ID is negotiated.
Type of partition being requested:
0 - no partition;
1 - fixed partition request;
2 - fixed partition assigned.
PFlag (4 bits): used to indicate the type of partition request.
1 - new adjacency;
2 - recovered adjacency.
Sender Instance (24 bits): For the SYN, SYNACK, and ACK messages, is
the sender's instance number for the link to the peer. It is used
to detect when the link comes back up after going down or when the
identity of the entity at the other end of the link changes. The
instance number is a 24-bit number that is guaranteed to be unique
within the recent past and to change when the link or node comes
back up after going down. Zero is not a valid instance number.
For the RSTACK message, the Sender Instance field is set to the
value of the Receiver Instance field from the incoming message
that caused the RSTACK message to be generated.
Partition ID (8 bits): field used to associate the message with a
specific partition of the AN.
Receiver Instance (24 bits): For the SYN, SYNACK, and ACK messages,
is what the sender believes is the current instance number for the
link, allocated by the entity at the far end of the link. If the
sender of the message does not know the current instance number at
the far end of the link, this field SHOULD be set to zero. For
the RSTACK message, the Receiver Instance field is set to the
value of the Sender Instance field from the incoming message that
caused the RSTACK message to be generated.
Reserved (8 bits): reserved for use by a future version of this Reserved (8 bits): reserved for use by a future version of this
specification. specification.
# of Caps: indicates the number of capability fields that follow. # of Caps: indicates the number of capability fields that follow.
Total Length: indicates the total number of bytes occupied by the Total Length: indicates the total number of bytes occupied by the
capability fields that follow. capability fields that follow.
Capability Fields: Each capability field indicates one ANCP Capability Fields: Each capability field indicates one ANCP
capability supported by the sender of the adjacency message. capability supported by the sender of the adjacency message.
Negotiation of a common set of capabilities to be supported within Negotiation of a common set of capabilities to be supported within
the ANCP session is described in Section 3.5.2. The detailed the ANCP session is described below. The detailed format of a
format of a capability field is shown in Figure 5 and described capability field is shown in Figure 5 and described below.
below.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capability Type | Capability Length | | Capability Type | Capability Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ ~ ~ ~
~ Capability Data ~ ~ Capability Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 41 skipping to change at page 18, line 33
Access technology: DSL Access technology: DSL
Length (in bytes) : 0 Length (in bytes) : 0
Capability Data : NULL Capability Data : NULL
For the detailed protocol specification of this capability see For the detailed protocol specification of this capability see
Section 8. Section 8.
In addition to the adjacency messages whose format is shown in
Figure 6, ANCP adjacency procedures use the Adjacency Update message
(Figure 6) to inform other NASs controlling the same AN partition
when a particular NAS joins or loses an adjacency with that
partition.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: The Adjacency Update Message
The Adjacency Update message is identical to the general ANCP message
header described in Section 3.6, but the field settings are in part
specific to the Adjacency Update message. The fields in this message
are as follows:
Version (8 bits): the ANCP version negotiated and running in this
adjacency.
Message Type (8 bits): always 85.
Result (4 bits): set to Ignore (0).
Code (12 bits): set to the total number of adjacencies currently
established on this partition, from the point of view of the AN.
Partition ID (8 bits): the partition identifier of the partition for
which this notification is being sent.
Transaction Identifier (24 bits): MUST be set to 0.
I (1 bit), SubMessage number (15 bits): set as described in
Section 3.6.1.7.
Length (16 bits): set as described in Section 3.6.1.8.
3.5.2. ANCP Adjacency Procedures 3.5.2. ANCP Adjacency Procedures
Before beginning adjacency negotiation, the ANCP agent and the 3.5.2.1. Overview
control application "must" agree on the set of capabilities that they
support. This agreement "must" include the transfer of any
application-level information required to build the Capability Data
fields within the Capability structures. Note that none of the
capabilities specified in this document require any such information.
The NAS MUST set the M-flag in the SYN message (signifying it is the The ANCP adjacency protocol operates symmetrically between the NAS
master). Once the adjacency is established, periodic adjacency and the AN. In the absence of errors or race conditions, each peer
messages (type ACK) MUST be exchanged. The default for the ACK sends a SYN message, receives a SYNACK message in acknowledgement,
interval to be advertised in the adjacency messages is 25 seconds for and completes the establishment of the adjacency by sending an ACK
ANCP. The actual value SHOULD be configurable and is a deployment message. Through this exchange, each peer learns the values of the
choice. It is RECOMMENDED that both ends specify the same timer Name, Port, and Instance parameters identifying the other peer, and
value; to achieve this, each end SHOULD compare the timer value in the two peers negotiate the values of the Version and Partition ID
the first adjacency message it receives with its own preferred value parameters and the set of capabilities that the adjacency will
and agree to use the higher of the two values. That is, the node support.
that receives a higher timer value than its own SHOULD reply in its
subsequent adjacency messages (such as SYNACK, ACK) with the higher
timer value.
In the adjacency protocol the version and sub-version fields are used Once the adjacency has been established, its liveness is periodically
for version negotiation. The version negotiation MUST be completed tested. The peers engage in an ACK message exchange at a frequency
before synchronisation is achieved. In a SYN message the version/ determined by the negotiated value of the Timer field.
sub-version fields always contain the highest version understood by
the sender. A receiver receiving a SYN message with a version/
sub-version higher than it understands MUST silently discard that
message. A receiver receiving a SYN message with a version/
sub-version within the range of versions that it understands MUST
reply with a SYNACK with the version/sub-version from the received
SYN in its ANCP version/sub-version fields. This defines the
version/sub-version of the ANCP protocol to be used while the
adjacency remains synchronized. All other ANCP messages within the
session MUST use the agreed version in the version/sub-version
fields.
Both the NAS and the Access Node MUST advertise supported If an inconsistency, loss of contact, or protocol violation is
capabilities in the adjacency messages they send. The same message detected, the detecting peer can force a restart of the
MAY advertise capabilities for any mixture of access technologies. synchronization process by sending an RSTACK message to the other
If a received adjacency message indicates no support for a capability end.
that is supported by the receiving device, it MUST disable the
capability locally and MUST send an updated adjacency message with
the corresponding capability field omitted to match the received
capability set. This process will eventually result in both sides
agreeing on the maximal common set of supported capabilities. The
adjacency MUST NOT come up if that common set is empty.
Subsequent to adjacency startup, if the adjacency times out on either Once an adjacency has been established, if more than one NAS has
end, due to not receiving an adjacency message for a duration of (3 * established an adjacency to the same partition, then the AN sends an
Timer value), where the timer value is negotiated as described above, Adjacency Update message to each such NAS to let it know how many
all the state received from the ANCP peer SHOULD be cleaned up, and established adjacencies the partition currently supports. Similarly,
the TCP connection SHOULD be closed. The NAS MUST continue to listen if an adjacency is lost, the AN sends an Adjacency Update message to
for new connection requests. The AN MUST try to re-establish the TCP each of the remaining adjacent NASs to let them know about the change
connection and both sides MUST attempt to re-establish the adjacency. in status.
After initial synchronization, if at any time a capability mismatch 3.5.2.2. Adjacency Protocol State Machine
is detected, the adjacency MUST be brought down (RSTACK MUST be
The adjacency protocol is described by the following rules and state
tables. It begins with the sending of a SYN by each end as soon as
the transport connection has been established. If at any point the
operations A, B, C, or "Verify Adjacent State" defined below detect a
mismatch, a log SHOULD be generated, identifying the fields concerned
and the expected and received values for each.
The rules and state tables use the following operations:
o The "Record Adjacency State" operation is defined in
Section 3.5.2.3.2.
o The "Verify Adjacency State" operation consists of verifying that
the contents of the incoming SYNACK message match the adjacency
state values previously recorded.
o The procedure "Reset the link" is defined as:
1. Generate a new instance number for the link.
2. Delete the peer verifier (set to zero the values of Sender
Instance, Sender Port, and Sender Name previously stored by
the Record Adjacency State operation).
3. Send a SYN message(Section 3.5.2.3.1).
4. Enter the SYNSENT state.
o The state tables use the following Boolean terms and operators.
A. The Sender Instance in the incoming message matches the value
stored from a previous message by the "Record Adjacency State"
operation.
B. The Sender Instance, Sender Port, Sender Name and Partition ID
fields in the incoming message match the values stored from a
previous message by the "Record Adjacency State" operation.
C. The Receiver Instance, Receiver Port, Receiver Name and
Partition ID fields in the incoming message match the values
of the Sender Instance, Sender Port, Sender Name and Partition
ID currently sent in outgoing SYN, SYNACK, and ACK messages,
except that the NAS always accepts the Partition ID value
presented to it in a SYN or SYNACK message.
"&&" Represents the logical AND operation.
"||" Represents the logical OR operation.
"!" Represents the logical negation (NOT) operation.
o A timer is required for the periodic generation of SYN, SYNACK,
and ACK messages. The value of the timer is negotiated in the
Timer field. The period of the timer is unspecified but a value
of 25 seconds is suggested. Note that since ANCP uses a reliable
transport protocol, the timer is unlikely to expire in any state
other than ESTAB.
There are two independent events: the timer expires, and a packet
arrives. The processing rules for these events are:
Timer Expires: Reset Timer
If state = SYNSENT Send SYN
If state = SYNRCVD Send SYNACK
If state = ESTAB Send ACK
Packet Arrives:
If incoming message is an RSTACK:
If (A && C && !SYNSENT) Reset the link
Else discard the message.
If incoming message is a SYN, SYNACK, or ACK:
Response defined by the following State Tables.
If incoming message is any other ANCP message and state !=
ESTAB:
Discard incoming message.
If state = SYNSENT Send SYN (Note 1)
If state = SYNRCVD Send SYNACK (Note 1)
Note 1: No more than two SYN or SYNACK messages should be sent
within any time period of length defined by the timer.
o State synchronisation across a link is considered to be achieved
when the protocol reaches the ESTAB state. All ANCP messages,
other than adjacency protocol messages, that are received before
synchronisation is achieved will be discarded.
3.5.2.2.1. State Tables
State: SYNSENT
+====================================================================+
| Condition | Action | New State |
+==================+=====================================+===========+
| SYNACK && C | Update Peer Verifier; Send ACK | ESTAB |
+------------------+-------------------------------------+-----------+
| SYNACK && !C | Send RSTACK | SYNSENT |
+------------------+-------------------------------------+-----------+
| SYN | Update Peer Verifier; Send SYNACK | SYNRCVD |
+------------------+-------------------------------------+-----------+
| ACK | Send RSTACK | SYNSENT |
+====================================================================+
State: SYNRCVD
+====================================================================+
| Condition | Action | New State |
+==================+=====================================+===========+
| SYNACK && C | Verify Adjacency State; Send ACK | ESTAB |
+------------------+-------------------------------------+-----------+
| SYNACK && !C | Send RSTACK | SYNRCVD |
+------------------+-------------------------------------+-----------+
| SYN | Record Adjacency State; Send SYNACK | SYNRCVD |
+------------------+-------------------------------------+-----------+
| ACK && B && C | Send ACK | ESTAB |
+------------------+-------------------------------------+-----------+
| ACK && !(B && C) | Send RSTACK | SYNRCVD |
+====================================================================+
State: ESTAB
+====================================================================+
| Condition | Action | New State |
+==================+=====================================+===========+
| SYN || SYNACK | Send ACK (note 2) | ESTAB |
+------------------+-------------------------------------+-----------+
| ACK && B && C | Send ACK (note 3) | ESTAB |
+------------------+-------------------------------------+-----------+
| ACK && !(B && C) | Send RSTACK | ESTAB |
+====================================================================+
Note 2: No more than two ACKs should be sent within any time period
of length defined by the timer. Thus, one ACK MUST be sent every
time the timer expires. In addition, one further ACK may be sent
between timer expirations if the incoming message is a SYN or SYNACK.
This additional ACK allows the adjacency protocol to reach
synchronisation more quickly.
Note 3: No more than one ACK should be sent within any time period of
length defined by the timer.
3.5.2.3. The Adjacency Protocol SYN Message
3.5.2.3.1. Action By the Sender
The SYN message is sent in accordance with the state tables just
described. The sender sets the individual fields as follows:
Version: SHOULD be set to the highest version of ANCP that the
sender supports.
Message Type: MUST be set to 10.
Timer: SHOULD be set to the value configured in the AN or NAS
sending the message.
M Flag MUST be set to 1 by the NAS, and 0 by the AN.
Code: MUST be set to 1 (SYN).
Sender Name set as described in Section 3.5.1.
Receiver Name: SHOULD be set to 0.
Sender Port set as described in Section 3.5.1.
Receiver Port: SHOULD be set to 0.
PType: set according to the following rules:
Settings by the AN:
0 - the AN does not support partitions;
2 - the value of Partition ID contained in this message is
assigned to the current partition.
Settings by the NAS:
0 - the NAS leaves the decision on partitioning to the AN
(RECOMMENDED setting);
1 - the NAS requests that the AN use the value of Partition
ID contained in this message for the current partition. The
NAS MUST be prepared to use whatever value it receives in a
SYN or SYNACK message, even if this differs from the
requested value.
PFlag: set to the mode of adjacency setup (new adjacency vs.
recovered adjacency) requested by the sender. Warning: setting
PFlag=1 runs the risk of state mismatch because ANCP does not
provide the means for the NAS to audit the current state of the
AN.
Sender Instance: set as described in Section 3.5.1.
Partition ID: MUST be set to 0 if PType=0, otherwise set to the
assigned or requested partition identifier value.
Receiver Instance: SHOULD be set to 0.
# of Caps: MUST be set to the number of Capability fields that
follow.
Total Length: MUST be set to the total number of bytes in the
Capability fields that follow.
Capability Fields: one Capability field MUST be present for each
ANCP capability for which the sender wishes to advertise support.
3.5.2.3.2. Action By the Receiver
Upon receiving a validly-formed SYN message, the receiver first
checks the value of the Version field. If this value is not within
the range of ANCP versions that the receiver supports, the message
MUST be silently ignored. Similarly, the message is silently ignored
if the M-flag is 0 and the receiver is an AN, or if the M-flag is 1
and the receiver is a NAS. If these checks are passed and the
receiver is in ESTAB state, it returns an ACK (as indicated by the
ESTAB state table in Section 3.5.2.2.1). The contents of the ACK
MUST reflect the adjacency state as previously recorded by the
receiver.
Otherwise, the receiver MUST record the adjacency state as follows:
Version: the supported Version value received in the SYN message.
This value MUST be used for all subsequent ANCP messages sent
during the life of the adjacency.
Timer: the larger of the Timer value received in the SYN message and
the value with which the receiver is configured.
Sender Name: the value of the Sender Name field in the SYN message
just received.
Receiver Name: the value used by the receiver in the Sender Name
field of SYN, SYNACK, and ACK messages it sends in this adjacency.
Sender Port: the value of the Sender Port field in the SYN message
just received.
Receiver Port: the value used by the receiver in the Sender Port
field of SYN, SYNACK, and ACK messages it sends in this adjacency.
Sender Instance: the value of the Sender Instance field in the SYN
message just received.
PFlag: the lesser of the value determined by local policy and the
value received in the SYN message. That is, preference is given
to "0 - New adjacency" if there is a conflict.
Partition ID: if the SYN receiver is the AN, this is set to 0 if the
AN does not support partitions, or to the non-zero value of the
partition identifier it chooses to assign otherwise. If the SYN
receiver is the NAS, this is set to the value of the Partition ID
field copied from the SYN.
Receiver Instance: the value used by the receiver in the Sender
Instance field of SYN, SYNACK, and ACK messages it sends in this
adjacency.
Capabilities: the set of ANCP capabilities that were offered in the
SYN and are supported by the receiver.
3.5.2.4. The Adjacency Protocol SYNACK Message
3.5.2.4.1. Action By the Sender
The SYNACK is sent in response to a successfully received SYN
message, as indicated by the state tables. The Version, Timer,
PFlag, and Partition ID fields MUST be populated with the values
recorded as part of adjacency state. The # of Caps, Total Length,
and Capability fields MUST also be populated in accordance with the
Capabilities recorded as part of adjacency state. The remaining
fields of the SYNACK message MUST be populated as follows:
Message Type: MUST be 10.
M-flag: MUST be set to 0.
Code: MUST be 2 (SYNACK).
PType: MUST be 0 if the Partition ID value is 0, or 2 if the
Partition ID value is non-zero.
Sender Name: MUST be set to the Receiver Name value recorded as part
of adjacency state.
Receiver Name: MUST be set to the Sender Name value recorded as part
of adjacency state.
Sender Port: MUST be set to the Receiver Port value recorded as part
of adjacency state.
Receiver Port: MUST be set to the Sender Port value recorded as part
of adjacency state.
Sender Instance: MUST be set to the Receiver Instance value recorded
as part of adjacency state.
Receiver Instance: MUST be set to the Sender Instance value recorded
as part of adjacency state.
If the set of capabilities recorded in the adjacency state is empty,
then after sending the SYNACK the sender MUST raise an alarm to
management, halt the adjacency procedure, and tear down the TCP
session if it is not being used by anothewr adjacency. The sender
MAY also terminate the IPSec security association if no other
adjacency is using it.
3.5.2.4.2. Action By the Receiver
As indicated by the state tables, the receiver of a SYNACK first
checks that the Receiver Name, Receiver Port, and Receiver Instance
values match the Sender Name, Sender Port, and Sender Instance values
it sent in SYN message that is being acknowledged. The AN also
checks that the PType and Partition ID match. If any of these checks
fail, the receiver sends an RSTACK as described in Section 3.5.2.6.1.
The receiver next checks whether the set of capabilities provided in
the SYNACK is empty. If so, the receiver MUST raise an alarm to
management and halt the adjacency procedure.
Assuming that the SYNACK passes these checks, two cases arise. The
first possibility is that the receiver has already recorded adjacency
state. This will occur if the SYNACK is received while the receiver
is in SYNRCVD state. In this case, the Version, Timer, Sender Name,
Sender Port, Sender Instance, PFlag, and capability-related fields in
the SYNACK MUST match those recorded as part of adjacency state. If
a mismatch is detected, the receiver sends an RSTACK. This is the
"Verify Adjacency State" procedure shown in the SYNRCVD state table.
If, on the other hand, the SYNACK is received while the receiver is
in SYNSENT state, the receiver MUST record session state as described
in Section 3.5.2.3.2.
In either case, if the receiver is the NAS, it MUST accept the
Partition ID value provided in the SYNACK, updating its recorded
adjacency state if necessary.
3.5.2.5. The Adjacency Protocol ACK Message
3.5.2.5.1. Actions By the Sender
As indicated by the state tables, the ACK message is sent in a number
of different circumstances. The main-line usages are as a response
to SYNACK, leading directly to the ESTAB state, and as a periodic
test of liveness once the ESTAB state has been reached.
The sender MUST populate the ACK from recorded adjacency state,
exactly as described in Section 3.5.2.4.1. The only difference is
that Code MUST be set to 3 (ACK).
3.5.2.5.2. Actions By the Receiver
The required actions by the receiver are specified by the state
tables. In addition to the checks B and C, the receiver SHOULD
verify that the remaining contents of the ACK match the recorded
adjacency state at the receiver. If that check fails the receiver
MUST send an RSTACK as described in Section 3.5.2.6.1.
Once the adjacency has been established, either peer can initiate the
ACK exchange that tests for liveness. To meet the restrictions on
ACK frequency laid down in the notes to the state tables, it is
desirable that only one such exchange occur during any one interval.
Hence if a peer receives an ACK when in ESTAB state, it MUST reply to
that ACK as directed by the state tables, but SHOULD NOT initiate
another ACK exchange in the same interval. To meet this objective,
the receiver MUST reset its timer when it receives an ACK while in
ESTAB state.
It is, of course, possible that two exchanges happen because of
race conditions.
3.5.2.6. The Adjacency Protocol RSTACK Message
3.5.2.6.1. Action By the Sender
The RSTACK is sent in response to various error conditions as
indicated by the state tables. In general it leads to a restart of
adjacency negotiations (although this takes a few steps when the
original sender of the RSTACK is in ESTAB state).
As indicated in Section 3.5.1, the Sender Name, Port, and Instance
fields in the RSTACK MUST be copied from the Receiver, Name, Port,
and Instance fields in the message that caused the RSTACK to be sent.
Similarly, the Receiver identifier fields in the RSTACK MUST be
copied from the corresponding Sender identifier fields in the message
that triggered the RSTACK.
If the sender has recorded adjacency state, the Version, Timer,
PType, PFlag, Partition ID, and capability-related fields SHOULD be
set based on the recorded adjacency state. Otherwise they SHOULD be
the same as the sender would send in a SYN message. The Message Type
MUST be 10, the M-flag MUST be 0, and Code MUST be 4 (RSTACK).
3.5.2.6.2. Action By the Receiver
The receiver of an RSTACK MAY attempt to diagnose the problem which
caused the RSTACK to be generated by comparing its own adjacency
state with the contents of the RSTACK. However, the primary purpose
of the RSTACK is to trigger action as prescribed by Section 3.5.2.2.
3.5.2.7. Loss of Contact or Synchronization
Subsequent to adjacency establishment, if the adjacency times out on
either end, due to not receiving an adjacency message for a duration
of (3 * Timer value), all the state received from the ANCP peer
SHOULD be cleaned up, and the TCP connection SHOULD be closed if it
is not being used by another adjacency. If it is closed, the NAS
MUST continue to listen for new connection requests. The AN MUST try
to re-establish the TCP connection and both sides MUST attempt to re-
establish the adjacency once that connection has been reestablished.
After initial synchronization, if at any time a mismatch in adjacency
state is detected, the adjacency MUST be brought down (RSTACK MUST be
generated by the device detecting the mismatch), and synchronization generated by the device detecting the mismatch), and synchronization
MUST be re-attempted. MUST be re-attempted.
The ANCP agent "must" notify the control application whenever an
adjacency is either synchronized or lost. When an adjacency is
synchronized, the notification "must" include the set of capabilities
negotiated with the peer along with any application-level information
conveyed in Capability Data fields.
3.6. ANCP General Message Formats 3.6. ANCP General Message Formats
This section describes the general format of ANCP messages other than This section describes the general format of ANCP messages other than
the adjacency messages. the adjacency messages. See Figure 7
The GSMPv3 general message format, used by all GSMP messages other
than adjacency protocol messages, is defined in Section 3.1.1 of
GSMPv3 [RFC3292]. ANCP modifies this base GSMPv3 message format as
shown in Figure 6.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | Message Type | Result| Code | | Version | Message Type | Result| Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier | | Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length | |I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Message Payload ~ ~ Message Payload ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: ANCP General Message Format Figure 7: ANCP General Message Format
3.6.1. The ANCP Message Header 3.6.1. The ANCP Message Header
The immediately visible differences from GSMPv3 are the subdivision A complete explanation of the ANCP general message header fields
of the Version field into version and sub-version, and the follows.
reallocation of space between Result and Code to enlarge the range
for Code. The 8-bit version field in the base GSMPv3 message header
is split into two 4 bit fields for carrying the version and a sub-
version of the ANCP protocol. The Result field in the message header
has been modified to be 4 bits long, and the Code field to be 12 bits
long.
A complete explanation of the header fields follows.
3.6.1.1. Version and Sub-Version Fields 3.6.1.1. Version Field (8 bits)
Together these fields reproduce the version of the ANCP protocol that This field carries the version of the ANCP protocol that was agreed
was agreed for the session during adjacency negotiation. See for the session during adjacency negotiation.
Section 3.1 for the values to set for version and sub-version for the
present version of this specification.
3.6.1.2. Message Type Field 3.6.1.2. Message Type Field (8 bits)
This field indicates the ANCP message type. Message type values are This field indicates the ANCP message type. Message type values are
registered in a common GSMPv3/ANCP IANA registry. registered in an IANA registry.
3.6.1.3. Result Field 3.6.1.3. Result Field (4 bits)
The Result field is derived from GSMPv3 [RFC3292]. Ignore (0x0) is a In request messages, the Result field indicates the circumstances
new value added by ANCP. The remaining Result values listed below under which a response is required. ANCP specifies what Result value
are a subset of those defined for GSMPv3. GSMPv3 expected the sender each request message type should have. In responses the Result field
of a request to choose between NAck (0x1) and AckAll (0x2) according indicates either Success (0x3) or Failure (0x4) as the case may be.
to its needs. ANCP specifies what Result value each request should
have. Responses indicate either Success (0x3) or Failure (0x4) as
the case may be.
Ignore: Res = 0x0 - Treat this field as a "no operation" and follow Ignore: Res = 0x0 - Treat this field as a "no operation" and follow
the response procedures specified for the received message type. the response procedures specified for the received message type.
Nack: Res = 0x1 - Result value indicating that a response is Nack: Res = 0x1 - Result value indicating that a response is
expected to the request only in cases of failure caused during the expected to the request only in cases of failure caused during the
processing of the message contents or of the contained processing of the message contents or of the contained
directive(s). directive(s).
AckAll: Res = 0x2 - Result value indicating that a response to the AckAll: Res = 0x2 - Result value indicating that a response to the
message is requested in all cases. message is requested in all cases.
Success: Res = 0x3 - Result value indicating that this is a response Success: Res = 0x3 - Result value indicating that this is a response
and that the request was executed successfully. The Code field and that the request was executed successfully. The Result Code
for a successful result is typically 0, but MAY take on other field for a successful result is typically 0, but MAY take on
values as specified for particular message types. other values as specified for particular message types.
Failure: Res = 0x4 - Result value indicating that this is a response Failure: Res = 0x4 - Result value indicating that this is a response
and that the request was not executed successfully. The receiver and that the request was not executed successfully. The receiver
of the response SHOULD take further action as indicated by the of the response SHOULD take further action as indicated by the
Code value and any diagnostic data contained in a Status-Info TLV Result Code value and any diagnostic data contained in a Status-
included in the response. Info TLV included in the response.
3.6.1.4. Code Field 3.6.1.4. Result Code Field (12 bits)
This field gives further information concerning the result in a This field gives further information concerning the result in a
response message. It is mostly used to pass an error code in a response message. It is mostly used to pass an error code in a
failure response but can also be used to give further information in failure response but can also be used to give further information in
a success response message or an event message. In a request a success response message or an event message. In a request
message, the Code field is not used and MUST be set to zero. message, the Result Code field is not used and MUST be set to 0x0 (No
error).
A number of code values are specified below. Specification of A number of Result Code values are specified below. Specification of
additional Code values in extensions or updates to this document MUST additional Result Code values in extensions or updates to this
include the following information: document MUST include the following information:
o Code value; o Result Code value;
o One-line description; o One-line description;
o Where condition detected: (control application or ANCP agent); o Where condition detected: (control application or ANCP agent);
o Further description (if any); o Further description (if any);
o Required additional information in the response message; o Required additional information in the response message;
o Target (control application or ANCP agent at the peer that sent o Target (control application or ANCP agent at the peer that sent
the original request); the original request);
o Action RECOMMENDED for the receiving ANCP agent o Action RECOMMENDED for the receiving ANCP agent
In addition to any suggested action in the text which follows, the In addition to any suggested action in the text which follows, a
Code value SHOULD be logged in a MIB. Where an action includes count of the number of times a given non-zero Result Code value was
received SHOULD be provided for management. Where an action includes
resending of a request, a given request SHOULD NOT be re-sent more resending of a request, a given request SHOULD NOT be re-sent more
than once. than once.
ANCP agents MAY use any of the Code values specified in the IANA This document specifies the following Result Code values.
registry "Global Switch Management Protocol version 3 (GSMPv3)
Failure Response Message Name Space" if they appear applicable. In
particular, the values 2, 6, 7, and 19 appear to be reusable and are
therefore documented below along with a few new ANCP-specific values.
Values 30 and 31 are also reusable, but are more appropriately
documented in a multicast extension document.
Code value: 2 Result Code value: 2
* One-line description: Invalid request message * One-line description: Invalid request message
* Where condition detected: ANCP agent * Where condition detected: ANCP agent
* Further description: The request was a properly formed message * Further description: The request was a properly formed message
which violates the protocol through its timing or direction of which violates the protocol through its timing or direction of
transmission. The most likely reason for this outcome in the transmission. The most likely reason for this outcome in the
field will be a race condition. field will be a race condition.
skipping to change at page 20, line 20 skipping to change at page 32, line 5
Response message. Response message.
* Target: ANCP agent at the peer that sent the original request * Target: ANCP agent at the peer that sent the original request
* Action RECOMMENDED for the receiving ANCP agent: The original * Action RECOMMENDED for the receiving ANCP agent: The original
request MAY be re-sent once only after a short delay. Inform request MAY be re-sent once only after a short delay. Inform
the control application with appropriate identification of the the control application with appropriate identification of the
failed transaction if the second attempt fails or no second failed transaction if the second attempt fails or no second
attempt is made. attempt is made.
Code value: 6 Result Code value: 6
* One-line description: One or more of the specified ports are * One-line description: One or more of the specified ports are
down down
* Where condition detected: control application * Where condition detected: control application
* Further description (if any): This Code value indicates a state * Further description (if any): This Result Code value indicates
mismatch between the NAS and AN control applications, possibly a state mismatch between the NAS and AN control applications,
due to a race condition. possibly due to a race condition.
* Required additional information in the response message: if the * Required additional information in the response message: if the
request identified multiple access lines or the response is a request identified multiple access lines or the response is a
Generic Response message, then the response MUST contain a Generic Response message, then the response MUST contain a
Status-Info TLV encapsulating TLV(s) containing the line Status-Info TLV encapsulating TLV(s) containing the line
identifier(s) of the access lines that are not operational. identifier(s) of the access lines that are not operational.
* Target: control application at the peer that sent the original * Target: control application at the peer that sent the original
request request
* Action RECOMMENDED for the receiving ANCP agent: indicate the * Action RECOMMENDED for the receiving ANCP agent: indicate the
error and forward the line identifier(s) to the control error and forward the line identifier(s) to the control
application. application.
Code value: 7 Result Code value: 19
* One-line description: Invalid Partition ID
* Where condition detected: ANCP agent
* Further description: This indicates that the request used a
Partition ID value different from what was determined for this
partition during adjacency negotiation, implying a state
mismatch between the ANCP agents.
* Required additional information in the response message: none,
if the response message is of the same type as the request. As
specified in Section 4.2 if the response message is a Generic
Response message.
* Target: ANCP agent at the peer that sent the original request
* Action RECOMMENDED for the receiving ANCP agent: If multiple
instances of this error occur, the requestor SHOULD cause the
adjacency for the partition to be reset and renegotiated by
sending an adjacency message with pType = 0 and Code = RSTACK
as described in Section 11.3 of [RFC3292].
NOTE: This specification provides no way for the NAS to do a
complete audit of the current state stored on the AN. Hence
renegotiation of the adjacency with pFlag = 2 (connection state
retained at the AN) MAY be attempted, but entails some risk of
state mismatch.
Code value: 19
* One-line description: Out of resources * One-line description: Out of resources
* Where condition detected: ANCP protocol layer or control * Where condition detected: ANCP protocol layer or control
application application
* Further description: (e.g., memory exhausted, etc.). This Code * Further description: (e.g., memory exhausted, etc.). This
value MUST be reported only by the AN, and indicates a Result Code value MUST be reported only by the AN, and
condition that is probably unrelated to specific access lines indicates a condition that is probably unrelated to specific
(although it may be related to the specific request). access lines (although it may be related to the specific
request).
* Required additional information in the response message: none, * Required additional information in the response message: none,
if the response message is of the same type as the request. As if the response message is of the same type as the request. As
specified in Section 4.2 if the response message is a Generic specified in Section 4.2 if the response message is a Generic
Response message. Response message.
* Target: ANCP agent at the peer that sent the original request * Target: ANCP agent at the peer that sent the original request
* Action RECOMMENDED for the receiving ANCP agent: If the NAS * Action RECOMMENDED for the receiving ANCP agent: If the NAS
receives this Code value from multiple requests for the same AN receives this Result Code value from multiple requests for the
in a short interval, it SHOULD reduce the rate at which it same AN in a short interval, it SHOULD reduce the rate at which
sends requests in proportion to the rate at which requests are it sends requests in proportion to the rate at which requests
failing with Code = 19. It MAY retry individual requests. If are failing with Result Code = 19. It MAY retry individual
only a specific request is failing with Code = 19, the ANCP requests. If only a specific request is failing with Result
agent in the NAS MAY request the control application to Code = 19, the ANCP agent in the NAS MAY request the control
decompose the request into simpler components if this is application to decompose the request into simpler components if
possible. this is possible.
Code value: 81 Result Code value: 81
* One-line description: Request message type not implemented * One-line description: Request message type not implemented
* Where condition detected: ANCP agent * Where condition detected: ANCP agent
* Further description: This could indicate a mismatch in protocol * Further description: This could indicate a mismatch in protocol
version or capability state. It is also possible that support version or capability state. It is also possible that support
of a specific message is optional within some ANCP capability. of a specific message is optional within some ANCP capability.
* Required additional information in the response message: none, * Required additional information in the response message: none,
if the response message is of the same type as the request. As if the response message is of the same type as the request. As
specified in Section 4.2 if the response message is a Generic specified in Section 4.2 if the response message is a Generic
Response message. Response message.
* Target: ANCP agent at the peer that sent the original request * Target: ANCP agent at the peer that sent the original request
* Action RECOMMENDED for the receiving ANCP agent: If the * Action RECOMMENDED for the receiving ANCP agent: If the
receiver of this Code value expects that support of the message receiver of this Result Code value expects that support of the
type concerned is mandatory according to the capabilities message type concerned is mandatory according to the
negotiated for the session, it SHOULD cause the adjacency for capabilities negotiated for the session, it MAY re-send the
the partition to be reset and renegotiated by sending an message in case the message was corrupted in transit the first
adjacency message with pType = 0 and Code = RSTACK as described time. If that fails, and use of the message type cannot be
in Section 11.3 of [RFC3292]. avoided, the ANCP agent MAY reset the adjacency by sending an
RSTACK adjacency message (Section 3.5.2.6.1) where PType is set
to 0 and Sender and Receiver Name, Port, and Instance are taken
from recorded adjacency state. If a reset does not eliminate
the problem, the receiving ANCP agent SHOULD raise an alarm to
management and then cease to operate.
Code value: 83 Result Code value: 83
* One-line description: Malformed message * One-line description: Malformed message
* Where condition detected: ANCP agent * Where condition detected: ANCP agent
* Further description: This could be the result of corruption in * Further description: This could be the result of corruption in
transit, or an error in implementation at one end or the other. transit, or an error in implementation at one end or the other.
* Required additional information in the response message: none, * Required additional information in the response message: none,
if the response message is of the same type as the request. As if the response message is of the same type as the request. As
specified in Section 4.2 if the response message is a Generic specified in Section 4.2 if the response message is a Generic
Response message. Response message.
* Target: ANCP agent at the peer that sent the original request * Target: ANCP agent at the peer that sent the original request
* Action RECOMMENDED for the receiving ANCP agent: The request * Action RECOMMENDED for the receiving ANCP agent: The request
SHOULD be re-sent once to eliminate the possibility of in- SHOULD be re-sent once to eliminate the possibility of in-
transit corruption. transit corruption.
Code value: 84 Result Code value: 84
* One-line description: Mandatory TLV missing * One-line description: Mandatory TLV missing
* Where condition detected: ANCP agent * Where condition detected: ANCP agent
* Further description: none. * Further description: none.
* Required additional information in the response message: the * Required additional information in the response message: the
response message MUST contain a Status-Info message that response message MUST contain a Status-Info message that
encapsulates an instance of each missing mandatory TLV, where encapsulates an instance of each missing mandatory TLV, where
skipping to change at page 23, line 27 skipping to change at page 34, line 34
only the four-byte TLV header is present). only the four-byte TLV header is present).
* Target: ANCP agent at the peer that sent the original request * Target: ANCP agent at the peer that sent the original request
* Action RECOMMENDED for the receiving ANCP agent: resend the * Action RECOMMENDED for the receiving ANCP agent: resend the
message with the missing TLV(s), if possible. Otherwise, message with the missing TLV(s), if possible. Otherwise,
report the error to the control application with an indication report the error to the control application with an indication
of the missing information required to construct the missing of the missing information required to construct the missing
TLV(s). TLV(s).
Code value: 85 Result Code value: 85
* One-line description: Invalid TLV contents * One-line description: Invalid TLV contents
* Where condition detected: ANCP agent * Where condition detected: ANCP agent
* Further description: the contents of one or more TLVs in the * Further description: the contents of one or more TLVs in the
request do not match the specifications provided for the those request do not match the specifications provided for the those
TLVs. TLVs.
* Required additional information in the response message: the * Required additional information in the response message: the
response MUST contain a Status-Info TLV encapsulating the response MUST contain a Status-Info TLV encapsulating the
erroneous TLVs copied from the original request. erroneous TLVs copied from the original request.
* Target: ANCP agent at the peer that sent the original request * Target: ANCP agent at the peer that sent the original request
* Action RECOMMENDED for the receiving ANCP agent: correct the * Action RECOMMENDED for the receiving ANCP agent: correct the
error and resend the request, if possible. Otherwise, report error and resend the request, if possible. Otherwise, report
the error to the control application with an indication of the the error to the control application with an indication of the
erroneous information associated with the invalid TLV(s). erroneous information associated with the invalid TLV(s).
Code value: 1280 Result Code value: 1280
* One-line description: One or more of the specified ports do not * One-line description: One or more of the specified ports do not
exist exist
* Where condition detected: control application * Where condition detected: control application
* Further description (if any): this may indicate a configuration * Further description (if any): this may indicate a configuration
mismatch between the AN and the NAS or AAA. mismatch between the AN and the NAS or AAA.
* Required additional information in the response message: if the * Required additional information in the response message: if the
skipping to change at page 24, line 23 skipping to change at page 35, line 30
Status-Info TLV encapsulating TLV(s) containing the rejected Status-Info TLV encapsulating TLV(s) containing the rejected
line identifier(s). line identifier(s).
* Target: control application at the peer that sent the original * Target: control application at the peer that sent the original
request request
* Action RECOMMENDED for the receiving ANCP agent: indicate the * Action RECOMMENDED for the receiving ANCP agent: indicate the
error and forward the line identifiers to the control error and forward the line identifiers to the control
application. application.
ANCP extensions defining new code values SHOULD use the range 256 3.6.1.5. Partition ID (8 bits)
(0x100) through 511 (0x1FF) for this purpose. The range of values
from 256 to 4095 is reserved for allocation by IETF consensus.
3.6.1.5. Partition ID
The Partition ID field is a 8 bit number which signifies a partition
on the AN. The AN and NAS MAY agree on the partition ID using one of
the following possible options:
o The partition ID MAY be configured on the AN and learned by the
NAS in the adjacency message; or
o The partition ID MAY be statically configured on the NAS as part The Partition ID field MUST contain the value that was negotiated for
of configuring the neighbor information. Partition ID during the adjacency procedure as described above.
3.6.1.6. Transaction ID 3.6.1.6. Transaction ID (24 bits)
The Transaction ID is a 24-bit field set by the sender of a request The Transaction ID is set by the sender of a request message to
message to associate a response message with the original request associate a response message with the original request message.
message. Unless otherwise specified for a given message type, the Unless otherwise specified for a given message type, the Transaction
Transaction ID in request messages MUST be set to a value in the ID in request messages MUST be set to a value in the range (1, 2^24 -
range (1, 2^24 - 1). When used in this manner, the Transaction ID 1). When used in this manner, the Transaction ID sequencing MUST be
sequencing MUST be maintained independently for each message type maintained independently for each message type within each ANCP
within each ANCP adjacency. Furthermore, it SHOULD be incremented adjacency. Furthermore, it SHOULD be incremented by 1 for each new
linearly for each new message of the given type, cycling back to 1 message of the given type, cycling back to 1 after running the full
after running the full range. For event messages, the Transaction ID range. For event messages, the Transaction ID SHOULD be set to zero.
SHOULD be set to zero.
Unless otherwise specified, the default behaviour for all ANCP Unless otherwise specified, the default behaviour for all ANCP
responses is that the value of the Transaction ID MUST be copied from responses is that the value of the Transaction ID MUST be copied from
the corresponding request message. the corresponding request message.
3.6.1.7. I flag and SubMessage Number 3.6.1.7. I flag and SubMessage Number (1 + 15 bits)
In GSMPv3 these provide a mechanism for message fragmentation. In GSMPv3 these provide a mechanism for message fragmentation.
Because ANCP uses TCP transport, this mechanism is unnecessary. An Because ANCP uses TCP transport, this mechanism is unnecessary. An
ANCP agent SHOULD set the I Flag and subMessage Number fields to 1 to ANCP agent MUST set the I Flag and subMessage Number fields to 1 to
signify "no fragmentation". signify "no fragmentation".
3.6.1.8. Length 3.6.1.8. Length (16 bits)
This field MUST be set to the length of the ANCP message in bytes, This field MUST be set to the length of the ANCP message in bytes,
including its header fields and message body but excluding the four- including its header fields and message body but excluding the four-
byte encapsulating header defined in Section 3.2. byte encapsulating header defined in Section 3.2.
3.6.2. The ANCP Message Body 3.6.2. The ANCP Message Body
The detailed contents of the message payload portion of a given ANCP The detailed contents of the message payload portion of a given ANCP
message can vary with the capability in the context of which it is message can vary with the capability in the context of which it is
being used. However, the general format consists of zero or more being used. However, the general format consists of zero or more
fixed fields, followed by a variable amount of data in the form of fixed fields, followed by a variable amount of data in the form of
Type-Length-Value (TLV) data structures. Type-Length-Value (TLV) data structures.
The general format of a TLV is shown in Figure 7: The general format of a TLV is shown in Figure 8:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (IANA registered) | Length | | Type (IANA registered) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Value ~ ~ Value ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: General TLV Format Figure 8: General TLV Format
The fields of a TLV are defined as follows: The fields of a TLV are defined as follows:
Type: The TLV Type is a 16-bit unsigned value identifying the TLV Type (16 bits): The TLV Type is an unsigned value identifying the
type and nature of its contents. An IANA registry has been TLV type and nature of its contents. An IANA registry has been
established for ANCP TLV Type codes. established for ANCP TLV Type codes.
Length: The number of bytes of data in the Value field of the TLV, Length (16 bits): The number of bytes of data in the Value field of
excluding any padding required to bring this TLV to a 4-byte word the TLV, excluding any padding required to bring this TLV to a
boundary (see "Value" below). If a TLV contains other TLVs, any 4-byte word boundary (see "Value" below). If a TLV contains other
padding in the contained TLVs MUST be included in the value of TLVs, any padding in the contained TLVs MUST be included in the
Length. Depending on the specification of the TLV, the value of value of Length. Depending on the specification of the TLV, the
Length can be zero, a constant for all instances of the TLV, or a value of Length can be zero, a constant for all instances of the
varying quantity. TLV, or a varying quantity.
Value: The actual data carried by the TLV, if any. The value field Value (variable): The actual data carried by the TLV, if any. The
in each TLV MUST be padded with zeroes as required to align with a value field in each TLV MUST be padded with zeroes as required to
4-byte word boundary. The Value field of a TLV MAY include fixed align with a 4-byte word boundary. The Value field of a TLV MAY
fields and/or other TLVs. include fixed fields and/or other TLVs.
Unless otherwise specified, TLVs MAY be added to a message in any Unless otherwise specified, TLVs MAY be added to a message in any
order. If the recipient of a message does not understand a order. If the recipient of a message does not understand a
particular TLV, it MUST silently ignore it. particular TLV, it MUST silently ignore it.
A number of TLVs are specified in the remainder of this document. A number of TLVs are specified in the remainder of this document.
3.7. General Principles for the Design of ANCP Messages 3.7. General Principles for the Design of ANCP Messages
The GSMPv3 protocol [RFC3292] allows for two messaging constructs to ANCP allows for two messaging constructs to support request/response
support request/response interaction: interaction:
a. The same message type is used for both the request message and a. The same message type is used for both the request message and
the response message. The Result and Code field settings are the response message. The Result and Result Code field settings
used to differentiate between request and response messages. are used to differentiate between request and response messages.
b. The request and response messages use two different message b. The request and response messages use two different message
types. types.
The first approach is illustrated by the protocol specifications in The first approach is illustrated by the protocol specifications in
Section 8.4, the second by specifications in Section 6.4. The Section 8.4, the second by specifications in Section 6.4. The
purpose of this section is to provide more details about the second purpose of this section is to provide more details about the second
approach in order to allow the use of this messaging construct for approach in order to allow the use of this messaging construct for
the development of additional ANCP extensions. the development of additional ANCP extensions.
skipping to change at page 27, line 23 skipping to change at page 38, line 19
This section defines two messages and a number of TLVs that could be This section defines two messages and a number of TLVs that could be
useful in multiple capabilities. In some cases the content is under- useful in multiple capabilities. In some cases the content is under-
specified, with the intention that particular capabilities spell out specified, with the intention that particular capabilities spell out
the remaining details. the remaining details.
4.1. Provisioning Message 4.1. Provisioning Message
The Provisioning message is sent by the NAS to the AN to provision The Provisioning message is sent by the NAS to the AN to provision
information of global scope (i.e., not associated with specific information of global scope (i.e., not associated with specific
access lines) on the AN. The Provisioning message has the format access lines) on the AN. The Provisioning message has the format
shown in Figure 8. Support of the Provisioning message is OPTIONAL shown in Figure 9. Support of the Provisioning message is OPTIONAL
unless the ANCP agent claims support for a capability that requires unless the ANCP agent claims support for a capability that requires
its use. its use.
0 1 2 3 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 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) | | TCP/IP Encapsulating Header (Section 3.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header | | ANCP General Message Header |
+ (Section 3.6.1) + + (Section 3.6.1) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ TLVs ~ ~ TLVs ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Format of the Provisioning Message Figure 9: Format of the Provisioning Message
The message header field settings given below are REQUIRED in the The message header field settings given below are REQUIRED in the
Provisioning message. The remaining message header fields MUST be Provisioning message. The remaining message header fields MUST be
set as specified in Section 3.6.1. Which TLVs to carry in the 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 Provisioning message is specified as part of the specification of the
capabilities that use that message. The Provisioning message MAY be capabilities that use that message. The Provisioning message MAY be
used to carry data relating to more than one capability at once, used to carry data relating to more than one capability at once,
assuming that the capabilities concerned can co-exist and have all assuming that the capabilities concerned can co-exist and have all
been negotiated during adjacency establishment. been negotiated during adjacency establishment.
Message Type: MUST be set to 93. Message Type: MUST be set to 93.
Result: MUST be set to 0x0 (Ignore). Result: MUST be set to 0x0 (Ignore).
Code: MUST be set to zero. Result Code: MUST be set to zero.
Transaction ID: MUST be populated with a non-zero value chosen in Transaction ID: MUST be populated with a non-zero value chosen in
the manner described in Section 3.6.1.6. the manner described in Section 3.6.1.6.
If the AN can process the message successfully and accept all the If the AN can process the message successfully and accept all the
provisioning directives contained in it, the AN MUST NOT send any provisioning directives contained in it, the AN MUST NOT send any
response. response.
Unless otherwise specified for a particular capability, if the AN Unless otherwise specified for a particular capability, if the AN
fails to process the message successfully it MUST send a Generic fails to process the message successfully it MUST send a Generic
skipping to change at page 28, line 48 skipping to change at page 39, line 48
capabilities they support. capabilities they support.
The AN or NAS MAY send a Generic Response message indicating a The AN or NAS MAY send a Generic Response message indicating a
failure condition independently of a specific request before closing failure condition independently of a specific request before closing
the adjacency as a consequence of that failure condition. In this the adjacency as a consequence of that failure condition. In this
case, the sender MUST set the Transaction ID field in the header and 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 the Message Type field within the Status-Info TLV to zeroes. The
receiver MAY record the information contained in the Status-Info TLV receiver MAY record the information contained in the Status-Info TLV
for management use. for management use.
The format of the Generic Response message is shown in Figure 9 The format of the Generic Response message is shown in Figure 10
0 1 2 3 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 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) | | TCP/IP Encapsulating Header (Section 3.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header | | ANCP General Message Header |
+ (Section 3.6.1) + + (Section 3.6.1) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access line identifying TLV(s) | | Access line identifying TLV(s) |
skipping to change at page 29, line 25 skipping to change at page 40, line 25
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status-Info TLV | | Status-Info TLV |
~ (Section 4.5) ~ ~ (Section 4.5) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NOTE: TLVs MAY be in a different order from what is shown in this NOTE: TLVs MAY be in a different order from what is shown in this
figure. figure.
Figure 9: Structure of the Generic Response Message Figure 10: Structure of the Generic Response Message
This document specifies the following header fields. The remaining This document specifies the following header fields. The remaining
fields in the ANCP general message header MUST be set as specified in fields in the ANCP general message header MUST be set as specified in
Section 3.6.1. Section 3.6.1.
Message Type: MUST be set to 91. Message Type: MUST be set to 91.
Result: MUST be set to 0x3 (Success) or 0x4 (Failure). Result: MUST be set to 0x3 (Success) or 0x4 (Failure).
Code: MUST be set to zero for success or an appropriate non-zero Result Code: MUST be set to zero for success or an appropriate non-
value for failure. zero value for failure.
Transaction ID: MUST be copied from the message to which this Transaction ID: MUST be copied from the message to which this
message is a response. message is a response.
If the original request applied to a specific access line or set of 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 lines, the TLVs identifying the line(s) and possibly the user MUST be
copied into the Generic Response message at the top level. copied into the Generic Response message at the top level.
The Status-Info TLV MAY be present in a success response, to provide 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 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 present in a failure response. See Section 4.5 for a detailed
description of the Status-Info TLV. The actual contents will depend description of the Status-Info TLV. The actual contents will depend
on the request message type this message is responding to and the on the request message type this message is responding to and the
value of the Code field. value of the Result Code field.
To prevent an infinite loop of error responses, if the Generic To prevent an infinite loop of error responses, if the Generic
Response message is itself in error, the receiver MUST NOT generate Response message is itself in error, the receiver MUST NOT generate
an error response in return. an error response in return.
4.3. Target TLV 4.3. Target TLV
Type: 0x1000 to 0x1020 depending on the specific content. Only Type: 0x1000 to 0x1020 depending on the specific content. Only
0x1000 has been assigned in this specification (see below). 0x1000 has been assigned in this specification (see below).
Support of any specific variant of the Target TLV is OPTIONAL Support of any specific variant of the Target TLV is OPTIONAL
skipping to change at page 30, line 27 skipping to change at page 41, line 27
Description: The Target TLV (0x1000 - 0x1020) is intended to be a Description: The Target TLV (0x1000 - 0x1020) is intended to be a
general means to represent different types of objects. general means to represent different types of objects.
Length: Variable, depending on the specific object type. Length: Variable, depending on the specific object type.
Value: Target information as defined for each object type. The Value: Target information as defined for each object type. The
Value field MAY consist of sub-TLVs. Value field MAY consist of sub-TLVs.
TLV Type 0x1000 is assigned to a variant of the Target TLV TLV Type 0x1000 is assigned to a variant of the Target TLV
representing a single access line and encapsulating one or more sub- representing a single access line and encapsulating one or more sub-
TLVs identifying the target. Figure 10 is an example illustrating TLVs identifying the target. Figure 11 is an example illustrating
the TLV format for a single port identified by an Access-Loop- the TLV format for a single port identified by an Access-Loop-
Circuit-ID TLV (0x0001) (Section 5.1.2.1). Circuit-ID TLV (0x0001) (Section 5.1.2.1).
0 1 2 3 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 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 | | TLV Type = 0x1000 |Length = Circuit-ID Length + 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length | | Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Access Loop Circuit ID ~ ~ Access Loop Circuit ID ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Example of Target TLV For Single Access Line Figure 11: Example of Target TLV For Single Access Line
4.4. Command TLV 4.4. Command TLV
Type: 0x0011 Type: 0x0011
Description: The Command TLV (0x0011) is intended to be a general Description: The Command TLV (0x0011) is intended to be a general
means of encapsulating one or more command directives in a TLV means of encapsulating one or more command directives in a TLV
oriented message. The semantics of the command can be specified oriented message. The semantics of the command can be specified
for each message type using it. I.e., the specification of each for each message type using it. I.e., the specification of each
message type that can carry the Command TLV is expected to define message type that can carry the Command TLV is expected to define
skipping to change at page 31, line 30 skipping to change at page 42, line 30
the registry. the registry.
4.5. Status-Info TLV 4.5. Status-Info TLV
Name: Status-Info Name: Status-Info
Type: 0x0106 Type: 0x0106
Description: The Status-Info-TLV is intended to be a general Description: The Status-Info-TLV is intended to be a general
container for warning or error diagnostics relating to commands container for warning or error diagnostics relating to commands
and/or requests. It is a supplement to the Code field in the ANCP and/or requests. It is a supplement to the Result Code field in
general header. The specifications for individual message types the ANCP general header. The specifications for individual
MAY indicate the use of this TLV as part of responses, message types MAY indicate the use of this TLV as part of
particularly for failures. As mentioned above, the Generic responses, particularly for failures. As mentioned above, the
Response message will usually include an instance of the Status- Generic Response message will usually include an instance of the
Info TLV. Support of the Status-Info TLV, both as sender and as Status-Info TLV. Support of the Status-Info TLV, both as sender
receiver, is REQUIRED for all ANCP agents, regardless of what and as receiver, is REQUIRED for all ANCP agents, regardless of
capabilities they support. what capabilities they support.
Length: Variable, depending on the specific contents. Length: Variable, depending on the specific contents.
Value: The following fixed fields. In addition, sub-TLVs MAY be Value: The following fixed fields. In addition, sub-TLVs MAY be
appended to provide further diagnostic information. appended to provide further diagnostic information.
Reserved (one byte): see Section 3.4 for handling of reserved Reserved (8 bits): see Section 3.4 for handling of reserved
fields. fields.
Msg Type: Message Type of the request for which this TLV is Msg Type (8 bits): Message Type of the request for which this TLV
providing diagnostics. is providing diagnostics.
Error Message Length: Number of bytes in the error message, Result Message Length (16 bits): Number of bytes in the error
excluding padding. This MAY be zero if no error message is message, excluding padding, but including the language tag and
provided. delimiter. This MAY be zero if no error message is provided.
Error Message: Human-readable string providing information about Result Message: Human-readable string providing information about
the warning or error condition. Padded with zeroes as the warning or error condition. The initial characters of the
necessary to extend to a four-byte word boundary. 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 four-byte word boundary.
Section 3.6.1.4 provides recommendations for what TLVs to add in Section 3.6.1.4 provides recommendations for what TLVs to add in
the Status-Info TLV for particular values of the message header the Status-Info TLV for particular values of the message header
Code field. Result Code field.
Figure 11 illustrates the Status-Info TLV. Figure 12 illustrates the Status-Info TLV.
0 1 2 3 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 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 | | TLV Type = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Msg Type | Error Message Length | | Reserved | Msg Type | Error Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message (padded to 4 byte boundary) | | Error Message (padded to 4 byte boundary) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional sub-TLVs... | | optional sub-TLVs... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: The Status-Info TLV Figure 12: The Status-Info TLV
5. Introduction To ANCP Capabilities For Digital Subscriber Lines (DSL) 5. Introduction To ANCP Capabilities For Digital Subscriber Lines (DSL)
DSL is a widely deployed access technology for Broadband Access for DSL is a widely deployed access technology for Broadband Access for
Next Generation Networks. Specifications such as [TR-059], [TR-058], Next Generation Networks. Specifications such as [TR-059], [TR-058],
and [TR-092] describe possible architectures for these access and [TR-092] describe possible architectures for these access
networks. The scope of these specifications includes the delivery of networks. The scope of these specifications includes the delivery of
voice, video, and data services. voice, video, and data services.
The next three sections of this document specify basic ANCP The next three sections of this document specify basic ANCP
skipping to change at page 33, line 34 skipping to change at page 44, line 34
o identification down to the user or host level as a supplement to o identification down to the user or host level as a supplement to
access line identification in one of the other two forms. access line identification in one of the other two forms.
All of these identifiers originate with the AN control application, All of these identifiers originate with the AN control application,
during the process of DSL topology discovery. The control during the process of DSL topology discovery. The control
application chooses which identifiers to use and the values to place application chooses which identifiers to use and the values to place
into them on a line-by-line basis, based on AN configuration and into them on a line-by-line basis, based on AN configuration and
deployment considerations. deployment considerations.
Aside from its use in ANCP signalling, access line identification is Aside from its use in ANCP signalling, access line identification is
also used in DHCP transactions involving hosts served by DSL. Either also used in DHCP ([RFC2131], [RFC3315]) transactions involving hosts
the AN or the NAS can serve as a DHCP relay node. [TR-101] requires served by DSL. Either the AN or the NAS can serve as a DHCP relay
the AN or NAS in this role to add access line identification in node. [TR-101] requires the AN or NAS in this role to add access
Option 82 (Information) to each DHCP request it forwards to the DHCP line identification in Option 82 (Information) ([RFC3046], with its
server. It is desirable for efficiency that the identification used IPv6 equivalent in [RFC4649]) to each DHCP request it forwards to the
in this signalling should be the same as the identification used in DHCP server. It is desirable for efficiency that the identification
ANCP messages. 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 ANCP itself, the identifiers are opaque.
From the point of view of the AN control application, the syntax for 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 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 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. ASCII form of the NAS-side access line identifier will be similar.
Access line identification by logical appearance on the user side of Access line identification by logical appearance on the user side of
the Access Node will always identify a DSL loop uniquely. the Access Node will always identify a DSL loop uniquely.
Identification by the logical appearance on the NAS side of the Identification by the logical appearance on the NAS side of the
skipping to change at page 34, line 44 skipping to change at page 45, line 45
appearance on the user side of the Access Node. Two alternatives, appearance on the user side of the Access Node. Two alternatives,
the Access-Aggregation-Circuit-ID-ASCII TLV and the Access- the Access-Aggregation-Circuit-ID-ASCII TLV and the Access-
Aggregation-Circuit-ID-Binary TLV, identify an access line by its Aggregation-Circuit-ID-Binary TLV, identify an access line by its
logical appearance on the NAS side of the Access Node. It is 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 unlikely that a given AN uses both of these TLVs, either for the same
line or for different lines, since they carry equivalent information. line or for different lines, since they carry equivalent information.
Finally, the Access-Loop-Remote-Id TLV contains an operator- Finally, the Access-Loop-Remote-Id TLV contains an operator-
configured string that uniquely identifies the user on the associated 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]. access line, as described in Sections 3.9.1 and 3.9.2 of [TR-101].
As normative requirements on ANCP agents conforming to this section: ANCP agents conforming to this section MUST satisfy the following
requirements:
o ANCP agents MUST be able to build and send the Access-Loop- 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 Circuit-ID TLV, the Access-Loop-Remote-Id TLV, and either the
Access-Aggregation-Circuit-ID-ASCII TLV or the Access-Aggregation- Access-Aggregation-Circuit-ID-ASCII TLV or the Access-Aggregation-
Circuit-ID-Binary TLV (implementation choice), when passed the Circuit-ID-Binary TLV (implementation choice), when passed the
associated information from the AN control application. associated information from the AN control application.
o ANCP agents MUST be able to receive all four TLV types, extract o ANCP agents MUST be able to receive all four TLV types, extract
the relevant information, and pass it to the control application. the relevant information, and pass it to the control application.
skipping to change at page 36, line 35 skipping to change at page 47, line 37
field of the TLV MUST carry the VCI, while the second value field field of the TLV MUST carry the VCI, while the second value field
MUST carry the VPI. MUST carry the VPI.
Each identifier MUST be placed in the low-order bits of its Each identifier MUST be placed in the low-order bits of its
respective 32-bit field, with the higher-order bits set to zero. 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 ordering of the bits of the identifer MUST be the same as when
the identifier is transmitted on the wire to identify an Ethernet the identifier is transmitted on the wire to identify an Ethernet
frame or ATM cell. frame or ATM cell.
The Access-Aggregation-Circuit-ID-Binary is illustrated in The Access-Aggregation-Circuit-ID-Binary is illustrated in
Figure 12. Figure 13.
Length: 4 or 8 bytes Length: 4 or 8 bytes
Value: one or two 32-bit binary fields. Value: one or two 32-bit binary fields.
0 1 2 3 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 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 | | TLV Type = 0x0006 | Length = 4 or 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Single VLAN Identifier, inner VLAN identifier, or VCI | | Single VLAN Identifier, inner VLAN identifier, or VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer VLAN identifier or VPI | | Outer VLAN identifier or VPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: The Access-Aggregation-Circuit-ID-Binary TLV
Figure 13: The Access-Aggregation-Circuit-ID-Binary TLV
5.1.2.4. Access-Aggregation-Circuit-ID-ASCII TLV 5.1.2.4. Access-Aggregation-Circuit-ID-ASCII TLV
Type: 0x0003 Type: 0x0003
Description: This TLV transmits the ASCII equivalent of the Access- Description: This TLV transmits the ASCII equivalent of the Access-
Aggregation-Circuit-ID-Binary TLV. As mentioned in the previous Aggregation-Circuit-ID-Binary TLV. As mentioned in the previous
section, the AN control application will use a format similar to 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 that specified in Section 3.9.3 of [TR-101] for the format of the
"circuit-id". "circuit-id".
skipping to change at page 38, line 37 skipping to change at page 49, line 46
transfers it to the NAS. ANCP on the NAS side passes an indication 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 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 has been received along with the information contained in the
message. message.
The NAS control application updates its view of the DSL loop state, The NAS control application updates its view of the DSL loop state,
performs any required accounting operations, and uses any included performs any required accounting operations, and uses any included
line attributes to adjust the operation of its queueing/scheduling line attributes to adjust the operation of its queueing/scheduling
mechanisms as they apply to data passing to and from that DSL loop. mechanisms as they apply to data passing to and from that DSL loop.
Figure 13 summarizes the interaction. Figure 14 summarizes the interaction.
1. Home Access NAS 1. Home Access NAS
Gateway Node Gateway Node
-----------> --------------------------> -----------> -------------------------->
DSL Port Up (Event message) DSL Port Up (Event message)
Signal (default line parameters) Signal (default line parameters)
2. Home Access NAS 2. Home Access NAS
Gateway Node Gateway Node
skipping to change at page 39, line 26 skipping to change at page 50, line 26
DSL Port Up (Event message) DSL Port Up (Event message)
Resynch (updated line parameters) Resynch (updated line parameters)
3. Home Access NAS 3. Home Access NAS
Gateway Node Gateway Node
-----------> --------------------------> -----------> -------------------------->
Loss of Port Down (Event message) Loss of Port Down (Event message)
DSL Signal (selected line parameters) DSL Signal (selected line parameters)
Figure 13: ANCP Message Flow For DSL Topology Discovery Figure 14: ANCP Message Flow For DSL Topology Discovery
6.2. Protocol Requirements 6.2. Protocol Requirements
The DSL topology discovery capability is assigned capability type The DSL topology discovery capability is assigned capability type
0x0001. No capability data is associated with this capability. 0x0001. No capability data is associated with this capability.
6.2.1. Protocol Requirements On the AN Side 6.2.1. Protocol Requirements On the AN Side
The AN-side ANCP agent MUST be able to create DSL-specific Port Up The AN-side ANCP agent MUST be able to create DSL-specific Port Up
and Port Down messages according to the format specified in and Port Down messages according to the format specified in
Section 6.3. Section 6.3.
The AN-side ANCP agent MUST conform to the normative requirements of The AN-side ANCP agent MUST conform to the normative requirements of
Section 5.1.2. Section 5.1.2.
The AN-side ANCP agent "must" be able to accept any information
passed to it by the AN control application that can validly be
included in any of the line attribute TLVs specified in Section 6.5,
MUST package that information as TLVs, and MUST include these TLVs,
encapsulated in the DSL-Line-Attributes TLV, within the Port Up or
Port Down message.
The AN-side ANCP agent MUST follow the AN-side procedures associated The AN-side ANCP agent MUST follow the AN-side procedures associated
with DSL-specific Port Up and Port Down messages as they are with DSL-specific Port Up and Port Down messages as they are
specified in Section 6.4. specified in Section 6.4.
6.2.2. Protocol Requirements On the NAS Side 6.2.2. Protocol Requirements On the NAS Side
The NAS-side ANCP agent MUST be able to receive and validate DSL- The NAS-side ANCP agent MUST be able to receive and validate DSL-
specific Port Up and Port Down messages according to the format specific Port Up and Port Down messages according to the format
specified in Section 6.3. specified in Section 6.3.
The NAS-side ANCP agent MUST conform to the normative requirements of The NAS-side ANCP agent MUST conform to the normative requirements of
Section 5.1.2. Section 5.1.2.
The NAS-side ANCP agent MUST follow the NAS-side procedures The NAS-side ANCP agent MUST follow the NAS-side procedures
associated with DSL-specific Port Up and Port Down messages as they associated with DSL-specific Port Up and Port Down messages as they
are specified in Section 6.4. are specified in Section 6.4.
The NAS-side ANCP agent MUST be able to extract the information
contained in any of the TLVs specified in Section 6.5 and "must" be
able to make that information available to the NAS control
application.
6.3. ANCP Port UP and Port DOWN Event Message Descriptions 6.3. ANCP Port UP and Port DOWN Event Message Descriptions
The ANCP Port UP and Port DOWN Event messages are derived from the The format of the ANCP Port UP and Port DOWN Event messages is shown
GSMPv3 Event message shown in Section 9 of [RFC3292]. The modified in Figure 15.
format used for DSL topology discovery is shown in Figure 14.
0 1 2 3 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 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) | | TCP/IP Encapsulating Header (Section 3.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header | | ANCP General Message Header |
+ (Section 3.6.1) + + (Section 3.6.1) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 41, line 40 skipping to change at page 51, line 50
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSL-Line-Attributes TLV | | DSL-Line-Attributes TLV |
~ (MANDATORY in Port Up, OPTIONAL in Port Down) ~ ~ (MANDATORY in Port Up, OPTIONAL in Port Down) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NOTE: TLVs MAY be in a different order from what is shown in this NOTE: TLVs MAY be in a different order from what is shown in this
figure. figure.
Figure 14: Format Of the ANCP Port Up and Port Down Event Messages Figure 15: Format Of the ANCP Port Up and Port Down Event Messages
For DSL Topology Discovery For DSL Topology Discovery
See Section 3.6.1 for a description of the ANCP general message 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 header. The Message Type field MUST be set to 80 for Port Up, 81 for
Port Down. The 12 bit Code field MUST be set to 0. The 4 bit Result Port Down. The 12 bit Result Code field MUST be set to 0. The 4 bit
field MUST be set to 0 (signifying Ignore). The 24-bit Transaction Result field MUST be set to 0 (signifying Ignore). The 24-bit
Identifier field MUST be set to 0. Other fields in the general Transaction Identifier field MUST be set to 0. Other fields in the
header MUST be set as described in Section 3.6. general header MUST be set as described in Section 3.6.
The Port, Port Session Number, and Event Sequence Number fields are The Port, Port Session Number, and Event Sequence Number fields (32
not used by the DSL Topology Discovery capability. The Label field bits each) are not used by the DSL Topology Discovery capability.
(including the Stacked Label Indicator and the unused flags at the The 64-bit Label field is also unused, and MUST be treated as an
start of the Label field), is also unused, and MUST be treated as an
unused fixed 8-byte field. The handling of unused/reserved fields is unused fixed 8-byte field. The handling of unused/reserved fields is
described in Section 3.4. described in Section 3.4.
The remaining message fields belong to the "extension block" added to The remaining message fields belong to the "extension block", and are
the original GSMPv3 message by ANCP, and are described as follows: described as follows:
Extension Flags: The flag bits denoted by 'x' are currently Extension Flags: The flag bits denoted by 'x' are currently
unspecified and reserved. unspecified and reserved.
Message Type: Message Type has the same value as in the general Message Type: Message Type has the same value as in the general
header (i.e., 80 or 81). header (i.e., 80 or 81).
Tech Type: MUST be set to 0x05 (DSL). Tech Type: MUST be set to 0x05 (DSL).
# of TLVs: the number of TLVs that follow, not counting TLVs # of TLVs: the number of TLVs that follow, not counting TLVs
skipping to change at page 42, line 33 skipping to change at page 52, line 43
extension block in bytes, including any padding within individual extension block in bytes, including any padding within individual
TLVs. TLVs.
TLVs: one or more TLVs to identify a DSL line and zero or more TLVs TLVs: one or more TLVs to identify a DSL line and zero or more TLVs
to define its characteristics. to define its characteristics.
6.4. Procedures 6.4. Procedures
6.4.1. Procedures On the AN Side 6.4.1. Procedures On the AN Side
The AN-side ANCP agent MUST create and transmit a DSL-specific Port The AN-side ANCP agent creates and transmits a DSL-specific Port Up
Up or Port Down message when requested by the AN control application or Port Down message when requested by the AN control application and
and presented with the information needed to build a valid message, presented with the information needed to build a valid message. It
except if transmission is inhibited by a rate-dampening mechanism. is RECOMMENDED that the Access Node use a dampening mechanism per DSL
It is RECOMMENDED that the Access Node use a dampening mechanism per loop to control the rate at which state changes are communicated to
DSL loop to control the rate at which state changes are communicated the NAS.
to the NAS.
At the top level, the extension block within a DSL-specific Port Up 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 or Port Down message MUST include TLVs from Section 5.1.2 to identify
the DSL loop. the DSL loop.
TLVs presenting DSL line attributes (i.e., the TLVs specified in TLVs presenting DSL line attributes (i.e., the TLVs specified in
Section 6.5) MUST be encapsulated within the DSL-Line-Attributes TLV. 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 When the DSL-Line-Attributes TLV is present in a message, it MUST
contain at least one such TLV and will generally contain more than contain at least one such TLV and will generally contain more than
one. In the Port Up message, the DSL-Line-Attributes TLV MUST be 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 present. In the Port Down message, the DSL-Line-Attributes TLV MAY
be present. be present.
If the AN-side ANCP agent is unable to satisfy a request from the AN
control application because it detects an error in the request or
because it receives a Generic Response message indicating an error in
a Port Up or Port Down message that it has sent and is unable to
recover from that error at the protocol level, it "must" inform the
application, including any available diagnostic information.
6.4.2. Procedures On the NAS Side 6.4.2. Procedures On the NAS Side
The NAS-side ANCP agent MUST be prepared to receive Port Up and Port The NAS-side ANCP agent MUST be prepared to receive Port Up and Port
Down messages for a given DSL loop or logical port at any time after Down messages for a given DSL loop or logical port at any time after
negotiation of an adjacency has been completed. It is possible for negotiation of an adjacency has been completed. It is possible for
two Port Up messages in succession to be received for the same DSL two Port Up messages in succession to be received for the same DSL
loop without an intervening Port Down message, and vice versa. loop without an intervening Port Down message, and vice versa.
The NAS-side ANCP agent SHOULD validate each message against the The NAS-side ANCP agent SHOULD validate each message against the
specifications given in Section 6.3 and the TLV specifications given specifications given in Section 6.3 and the TLV specifications given
in Section 5.1.2 and Section 6.5. If it finds an error it MAY in Section 5.1.2 and Section 6.5. If it finds an error it MAY
generate a Generic Response message containing an appropriate Result generate a Generic Response message containing an appropriate Result
Code value. If it does so, the message MUST contain copies of all of 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 the identifier TLVs from Section 5.1.2 that were present in the Port
Up or Port Down message. The message SHOULD also contain a Status- Up or Port Down message. The message SHOULD also contain a Status-
Info TLV which in turn contains other information appropriate to the Info TLV which in turn contains other information appropriate to the
message header Code value as described in Section 3.6.1.4. message header Result Code value as described in Section 3.6.1.4.
If the received message passes validation, the NAS-side ANCP agent If the received message passes validation, the NAS-side ANCP agent
"must" extract the information from the TLVs contained in the message extracts the information from the TLVs contained in the message and
and present that information along with an indication of reported presents that information along with an indication of reported event
event type to the NAS control application. If validation of type to the NAS control application. If validation of individual
individual TLVs fails but the message as a whole can be processed, TLVs fails but the message as a whole can be processed, the NAS-side
the NAS-side ANCP agent "may" pass the valid message contents to the ANCP agent "may" pass the valid message contents to the NAS control
NAS control application. application.
6.5. TLVs For DSL Line Attributes 6.5. TLVs For DSL Line Attributes
As specified above, the DSL-Line-Attributes TLV is inserted into the 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 Port Up or Port Down message at the top level. The remaining TLVs
defined below are encapsulated within the DSL-Line-Attributes TLV. defined below are encapsulated within the DSL-Line-Attributes TLV.
6.5.1. DSL-Line-Attributes TLV 6.5.1. DSL-Line-Attributes TLV
Type: 0x0004 Type: 0x0004
skipping to change at page 49, line 25 skipping to change at page 59, line 25
IPoA NuLL = 4 IPoA NuLL = 4
Ethernet over AAL5 LLC with FCS = 5 Ethernet over AAL5 LLC with FCS = 5
Ethernet over AAL5 LLC without FCS = 6 Ethernet over AAL5 LLC without FCS = 6
Ethernet over AAL5 NULL with FCS = 7 Ethernet over AAL5 NULL with FCS = 7
Ethernet over AAL5 NULL without FCS = 8 Ethernet over AAL5 NULL without FCS = 8
The Access-Loop-Encapsulation TLV is illustrated in Figure 15. The Access-Loop-Encapsulation TLV is illustrated in Figure 16.
0 1 2 3 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 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 | | TLV Type = 0x0090 | Length = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data link | Encaps 1 | Encaps 2 | Padding (=0) | | Data link | Encaps 1 | Encaps 2 | Padding (=0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: The Access-Loop-Encapsulation TLV Figure 16: The Access-Loop-Encapsulation TLV
7. ANCP based DSL Line Configuration 7. ANCP based DSL Line Configuration
The use case for ANCP-based DSL Line Configuration is described in The use case for ANCP-based DSL Line Configuration is described in
Section 3.2 of [RFC5851]. Section 3.2 of [RFC5851].
7.1. Control Context (Informative) 7.1. Control Context (Informative)
Triggered by topology information reporting a new DSL line or Triggered by topology information reporting a new DSL line or
triggered by a subsequent user session establishment (PPP or DHCP), triggered by a subsequent user session establishment (via PPP or
RADIUS/AAA sends service parameters to the NAS control application DHCP), RADIUS/AAA sends service parameters to the NAS control
for configuration on the access line. The NAS control application application for configuration on the access line. The NAS control
passes the request on to the NAS-side agent, which sends the application passes the request on to the NAS-side agent, which sends
information to the AN by means of a Port Management (line the information to the AN by means of a Port Management (line
configuration) message. The AN-side agent passes this information up configuration) message. The AN-side agent passes this information up
to the AN control application, which applies it to the line. to the AN control application, which applies it to the line.
Figure 16 summarizes the interaction. Figure 17 summarizes the interaction.
Home Access NAS RADIUS/AAA Home Access NAS RADIUS/AAA
Gateway Node Policy Server Gateway Node Policy Server
-----------> ---------------> -----------> --------------->
DSL Port Up message) DSL Port Up message)
Signal (line parameters) Signal (line parameters)
--------------------------------> --------------> --------------------------------> -------------->
PPP/DHCP Session Authentication & PPP/DHCP Session Authentication &
authorization authorization
<---------------- <----------------
Port Management message Port Management message
(line configuration) (line configuration)
Figure 16: Message Flow - ANCP Mapping For Initial Line Configuration Figure 17: Message Flow - ANCP Mapping For Initial Line Configuration
The NAS could update the line configuration as a result of a The NAS could update the line configuration as a result of a
subscriber service change (e.g. triggered by the policy server). subscriber service change (e.g. triggered by the policy server).
Figure 17 summarizes the interaction. Figure 18 summarizes the interaction.
User Home Access NAS User Home Access NAS
Gateway Node Gateway Node
--------------------------> -------------------------->
PPP/DHCP Session PPP/DHCP Session
-------------------------------------------------------> Web portal, -------------------------------------------------------> Web portal,
Service on demand OSS, etc. Service on demand OSS, etc.
| |
<-------------- RADIUS/AAA <-------------- RADIUS/AAA
Change of Policy Server Change of Policy Server
authorization authorization
<------------ <------------
Port Management Port Management
message message
(new profile) (new profile)
Figure 17: Message flow - ANCP Mapping For Updated Line Configuration Figure 18: Message flow - ANCP Mapping For Updated Line Configuration
7.2. Protocol Requirements 7.2. Protocol Requirements
The DSL line configuration capability is assigned capability type The DSL line configuration capability is assigned capability type
0x0002. No capability data is associated with this capability. 0x0002. No capability data is associated with this capability.
7.2.1. Protocol Requirements On the NAS Side 7.2.1. Protocol Requirements On the NAS Side
The NAS-side ANCP agent MUST be able to create DSL-specific Port The NAS-side ANCP agent MUST be able to create DSL-specific Port
Management (line configuration) messages according to the format Management (line configuration) messages according to the format
specified in Section 7.3. specified in Section 7.3.
The NAS-side ANCP agent MUST conform to the normative requirements of The NAS-side ANCP agent MUST conform to the normative requirements of
Section 5.1.2. Section 5.1.2.
The NAS-side ANCP agent "must" be able to accept any information
passed to it by the NAS control application that may validly be
included in any of the TLVs specified in Section 7.5.
In the current version of this specification only one such TLV is
defined.
The NAS-side ANCP agent MUST package that information as TLVs, and
MUST include these TLVs within the Port Management (line
configuration) message.
The NAS-side ANCP agent MUST follow the NAS-side procedures The NAS-side ANCP agent MUST follow the NAS-side procedures
associated with DSL-specific Port Management (line configuration) associated with DSL-specific Port Management (line configuration)
messages as they are specified in Section 7.4. messages as they are specified in Section 7.4.
7.2.2. Protocol Requirements On the AN Side 7.2.2. Protocol Requirements On the AN Side
The AN-side ANCP agent MUST conform to the normative requirements of The AN-side ANCP agent MUST conform to the normative requirements of
Section 5.1.2. Section 5.1.2.
The AN-side ANCP agent MUST be able to receive and validate DSL- The AN-side ANCP agent MUST be able to receive and validate DSL-
specific Port Management (line configuration) messages according to specific Port Management (line configuration) messages according to
the format specified in Section 7.3. the format specified in Section 7.3.
The AN-side ANCP agent MUST follow the AN-side procedures associated The AN-side ANCP agent MUST follow the AN-side procedures associated
with DSL-specific Port Management (line configuration) messages as with DSL-specific Port Management (line configuration) messages as
specified in Section 7.4. specified in Section 7.4.
The NAS-side ANCP agent MUST be able to extract the information
contained in any of the TLVs listed in Section 7.2.1 and "must" make
that information available to the NAS control application.
7.3. ANCP Port Management (Line Configuration) Message Format 7.3. ANCP Port Management (Line Configuration) Message Format
The ANCP Port Management message for DSL line configuration has the The ANCP Port Management message for DSL line configuration has the
format shown in Figure 18. format shown in Figure 19.
0 1 2 3 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 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) | | TCP/IP Encapsulating Header (Section 3.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header | | ANCP General Message Header |
+ (Section 3.6.1) + + (Section 3.6.1) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 52, line 40 skipping to change at page 62, line 40
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Line configuration TLV(s) ~ ~ Line configuration TLV(s) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NOTE: TLVs MAY be in a different order from what is shown in this NOTE: TLVs MAY be in a different order from what is shown in this
figure. figure.
Figure 18: Port Management Message For DSL Line Configuration Figure 19: Port Management Message For DSL Line Configuration
See Section 3.6 for a description of the ANCP general message header. 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 Code field MUST The Message Type field MUST be set to 32. The 12 bit Result Code
be set to 0. The 4 bit Result field MUST be set to either 1 (NAck) field MUST be set to 0x0. The 4 bit Result field MUST be set to
or 2 (AckAll), as determined by policy on the NAS. The 24-bit either 1 (NAck) or 2 (AckAll), as determined by policy on the NAS.
Transaction Identifier field MUST be set to a positive value. Other The 24-bit Transaction Identifier field MUST be set to a positive
fields in the general header MUST be set as described in Section 3.6. value. Other fields in the general header MUST be set as described
in Section 3.6.
As with the Port Up and Port Down messages described above, the Port
Management message format defined in [RFC3292] has been modified to
contain additional data in an "extension block" at the end of the
message. Also, the original two byte Function field has been
modified to contain one byte for the Function field indicating a
specific action to be taken by the recipient of the message, and one
byte for X-Function field, which further qualifies the action
specified in the Function field. Any Function specific data MUST be
carried in TLVs in the extension block.
The Port, Port Session Number, and Event Sequence Number fields are The Port, Port Session Number, and Event Sequence Number fields are
not used by the DSL Line Configuration capability. The handling of not used by the DSL Line Configuration capability. The handling of
unused/reserved fields is described in Section 3.4. unused/reserved fields is described in Section 3.4.
The remaining message fields are described as follows: The remaining message fields are described as follows:
R Flag: not used by ANCP. R Flag: not used by ANCP.
Additional Port Management flags: the flag bits marked 'x' following Additional Port Management flags: the flag bits marked 'x' following
skipping to change at page 54, line 49 skipping to change at page 64, line 37
The AN-side ANCP agent MUST be prepared to receive Port Management The AN-side ANCP agent MUST be prepared to receive Port Management
(line configuration) messages for a given DSL loop or logical port at (line configuration) messages for a given DSL loop or logical port at
any time after negotiation of an adjacency has been completed. any time after negotiation of an adjacency has been completed.
The AN-side ANCP agent SHOULD validate each message against the The AN-side ANCP agent SHOULD validate each message against the
specifications given in Section 7.3 and the TLV specifications given specifications given in Section 7.3 and the TLV specifications given
in Section 5.1.2 and Section 7.5. If it finds an error it MUST in Section 5.1.2 and Section 7.5. If it finds an error it MUST
return a Port Management response message which copies the Port return a Port Management response message which copies the Port
Management request as it was received, but has the Result header Management request as it was received, but has the Result header
field set to 0x04 (Failure) and the Code field set to the appropriate field set to 0x04 (Failure) and the Result Code field set to the
value. The AN-side agent MAY add a Status-Info TLV (Section 4.5) to appropriate value. The AN-side agent MAY add a Status-Info TLV
provide further information on the error, particularly if this is (Section 4.5) to provide further information on the error,
recommended in Section 3.6.1.4 for the given Code value. If it does particularly if this is recommended in Section 3.6.1.4 for the given
so, the various length fields and the # of TLVs field within the Result Code value. If it does so, the various length fields and the
message MUST be adjusted accordingly. # of TLVs field within the message MUST be adjusted accordingly.
If the received message passes validation, the AN-side ANCP agent If the received message passes validation, the AN-side ANCP agent
"must" extract the information from the TLVs contained in the message "must" extract the information from the TLVs contained in the message
and present that information to the AN control application. In and present that information to the AN control application. In
addition, if the Result header field was set to 0x2 (AckAll) in the addition, if the Result header field was set to 0x2 (AckAll) in the
original request, the AN-side agent "must" indicate to the AN control original request, the AN-side agent "must" indicate to the AN control
application that a response is required. When the AN control application that a response is required. When the AN control
application indicates that it has processed the request successfully, application indicates that it has processed the request successfully,
the AN-side agent MUST return a Port Management response message the AN-side agent MUST return a Port Management response message
which duplicates the request except that the Result header field is which duplicates the request except that the Result header field is
set to 0x3 (Success). (The Code field, as in the original request, set to 0x3 (Success). (The Result Code field, as in the original
has value 0.) request, has value 0.)
7.5. TLVs For DSL Line Configuration 7.5. TLVs For DSL Line Configuration
Currently only the following TLV is specified for DSL line Currently only the following TLV is specified for DSL line
configuration. More TLVs may be defined in a future version of this configuration. More TLVs may be defined in a future version of this
specification or in ANCP extensions for individual service attributes specification or in ANCP extensions for individual service attributes
of a DSL line (e.g. rates, interleaving delay, multicast channel of a DSL line (e.g. rates, interleaving delay, multicast channel
entitlement access-list). entitlement access-list).
7.5.1. Service-Profile-Name TLV 7.5.1. Service-Profile-Name TLV
skipping to change at page 55, line 46 skipping to change at page 65, line 35
Value: ASCII string containing the profile name (which the NAS Value: ASCII string containing the profile name (which the NAS
learns from a policy server after a subscriber is authorized). learns from a policy server after a subscriber is authorized).
8. ANCP-Based DSL Remote Line Connectivity Testing 8. ANCP-Based DSL Remote Line Connectivity Testing
The use case and requirements for ANCP-Based DSL remote line The use case and requirements for ANCP-Based DSL remote line
connectivity testing are specified in Section 3.3 of [RFC5851] connectivity testing are specified in Section 3.3 of [RFC5851]
8.1. Control Context (Informative) 8.1. Control Context (Informative)
The NAS control application initiatea a request for remote The NAS control application initiates a request for remote
connectivity testing for a given access loop. The NAS control connectivity testing for a given access loop. The NAS control
application can provide loop count and timeout test parameters and application can provide loop count and timeout test parameters and
opaque data for its own use with the request. The loop count opaque data for its own use with the request. The loop count
parameter indicates the number of test messages or cells to be used. parameter indicates the number of test messages or cells to be used.
The timeout parameter indicates the longest that the NAS control The timeout parameter indicates the longest that the NAS control
application will wait for a result. application will wait for a result.
The request is passed in a Port Management (OAM) message. If the NAS The request is passed in a Port Management (OAM) message. If the NAS
control application has supplied test parameters, they are used, control application has supplied test parameters, they are used,
otherwise the AN control application uses default test parameters. otherwise the AN control application uses default test parameters.
If a loop count parameter provided by the NAS is outside the valid 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 range, the AN does not execute the test, but returns a result
indicating that the test has failed due to an invalid parameter. If 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 test takes longer than the timeout value (default or provided by
skipping to change at page 56, line 18 skipping to change at page 66, line 6
The request is passed in a Port Management (OAM) message. If the NAS The request is passed in a Port Management (OAM) message. If the NAS
control application has supplied test parameters, they are used, control application has supplied test parameters, they are used,
otherwise the AN control application uses default test parameters. otherwise the AN control application uses default test parameters.
If a loop count parameter provided by the NAS is outside the valid 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 range, the AN does not execute the test, but returns a result
indicating that the test has failed due to an invalid parameter. If 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 test takes longer than the timeout value (default or provided by
the NAS) the AN control application can return a failure result the NAS) the AN control application can return a failure result
indicating timeout or else can send no response. The AN control indicating timeout or else can send no response. The AN control
application can provide a human-readable string describing the test application can provide a human-readable string describing the test
results,for both failures and successes. If provided, this string is results, for both failures and successes. If provided, this string
included in the response. Responses always include the opaque data, is included in the response. Responses always include the opaque
if any, provided by the NAS control application. data, if any, provided by the NAS control application.
Figure 19 summarizes the interaction. Figure 20 summarizes the interaction.
+-------------+ +-----+ +-------+ +----------------+ +-------------+ +-----+ +-------+ +----------------+
|Radius/AAA |----|NAS |-------| DSLAM |-----------| CPE | |Radius/AAA |----|NAS |-------| DSLAM |-----------| CPE |
|Policy Server| +-----+ +-------+ | (DSL Modem + | |Policy Server| +-----+ +-------+ | (DSL Modem + |
+-------------+ |Routing Gateway)| +-------------+ |Routing Gateway)|
+----------------+ +----------------+
Port Management Message Port Management Message
(Remote Loopback ATM loopback (Remote Loopback ATM loopback
Trigger Request) OR EFM Loopback Trigger Request) OR EFM Loopback
1. ----------------> 2. ---------> 1. ----------------> 2. --------->
<--------+ <--------+
3. <--------------- 3. <---------------
Port Management Message Port Management Message
(Remote Loopback Test Response) (Remote Loopback Test Response)
Figure 19: Message Flow For ANCP based OAM Figure 20: Message Flow For ANCP based OAM
8.2. Protocol Requirements 8.2. Protocol Requirements
The DSL remote line connectivity testing capability is assigned The DSL remote line connectivity testing capability is assigned
capability type 0x0004. No capability data is associated with this capability type 0x0004. No capability data is associated with this
capability. capability.
8.2.1. Protocol Requirements On the NAS Side 8.2.1. Protocol Requirements On the NAS Side
The NAS-side ANCP agent MUST be able to create DSL-specific Port The NAS-side ANCP agent MUST be able to create DSL-specific Port
Management (OAM) messages according to the format specified in Management (OAM) messages according to the format specified in
Section 8.3. Section 8.3.
The NAS-side ANCP agent MUST conform to the normative requirements of The NAS-side ANCP agent MUST conform to the normative requirements of
Section 5.1.2. Section 5.1.2.
The NAS-side ANCP agent "must" be able to accept any information
passed to it by the NAS control application that may validly be
included in any of the TLVs specified in Section 8.5.
The NAS-side ANCP agent MUST package that information as TLVs, and
MUST include these TLVs within the Port Management (OAM) message.
The NAS-side ANCP agent MUST follow the NAS-side procedures The NAS-side ANCP agent MUST follow the NAS-side procedures
associated with DSL-specific Port Management (OAM) messages as they associated with DSL-specific Port Management (OAM) messages as they
are specified in Section 8.4. are specified in Section 8.4.
8.2.2. Protocol Requirements On the AN Side 8.2.2. Protocol Requirements On the AN Side
The AN-side ANCP agent MUST conform to the normative requirements of The AN-side ANCP agent MUST conform to the normative requirements of
Section 5.1.2. Section 5.1.2.
The AN-side ANCP agent MUST be able to receive and validate DSL- The AN-side ANCP agent MUST be able to receive and validate DSL-
specific Port Management (OAM) messages according to the format specific Port Management (OAM) messages according to the format
specified in Section 8.3. specified in Section 8.3.
The AN-side ANCP agent MUST follow the AN-side procedures associated The AN-side ANCP agent MUST follow the AN-side procedures associated
with DSL-specific Port Management (OAM) messages as specified in with DSL-specific Port Management (OAM) messages as specified in
Section 8.4. Section 8.4.
The NAS-side ANCP agent MUST be able to extract the information
contained in any of the TLVs listed in Section 8.2.1 and "must" make
that information available to the NAS control application.
8.3. Port Management (OAM) Message Format 8.3. Port Management (OAM) Message Format
The Port Management message for DSL line testing has the same format The Port Management message for DSL line testing has the same format
as for DSL line configuration (see Section 7.3), with the following as for DSL line configuration (see Section 7.3), with the following
differences: differences:
o The Result field in the request SHOULD be set to AckAll (0x1), to o The Result field in the request SHOULD be set to AckAll (0x1), to
allow the NAS to receive the information contained in a successful allow the NAS to receive the information contained in a successful
test response. test response.
o The Function field MUST be set to 9 (Remote Loopback). (The o The Function field MUST be set to 9 (Remote Loopback). (The
X-Function field continues to be 0.) X-Function field continues to be 0.)
o The appended TLVs in the extension value field include testing- o The appended TLVs in the extension value field include testing-
related TLVs rather than subcriber service information. related TLVs rather than subcriber service information.
The Port Management (OAM) message is illustrated in Figure 20. The Port Management (OAM) message is illustrated in Figure 21.
0 1 2 3 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 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) | | TCP/IP Encapsulating Header (Section 3.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header | | ANCP General Message Header |
+ (Section 3.6.1) + + (Section 3.6.1) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 58, line 40 skipping to change at page 68, line 40
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Testing-related TLVs ~ ~ Testing-related TLVs ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NOTE: TLVs MAY be in a different order from what is shown in this NOTE: TLVs MAY be in a different order from what is shown in this
figure. figure.
Figure 20: Port Management Message For DSL Line Remote Connectivity Figure 21: Port Management Message For DSL Line Remote Connectivity
Testing Testing
8.4. Procedures 8.4. Procedures
From the point of view of ANCP, it is permissible to attempt line From the point of view of ANCP, it is permissible to attempt line
connectivity testing regardless of the state of the line. However, connectivity testing regardless of the state of the line. However,
testing could fail in some states due to technology limitations. testing could fail in some states due to technology limitations.
8.4.1. NAS-Side Procedures 8.4.1. NAS-Side Procedures
When requested by the NAS control application and presented with the When requested by the NAS control application and presented with the
necessary information to do so, the NAS-side agent MUST create and necessary information to do so, the NAS-side agent creates and sends
send a Port Management (OAM) request with the fixed fields set as a Port Management (OAM) request with the fixed fields set as
described in the previous section. The message MUST contain one or described in the previous section. The message MUST contain one or
more TLVs to identify an access line according the requirements of 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 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 OAM-Loopback-Test-Parameters TLV (defined in Section 8.5) to
configure the loopback test for that line. configure the loopback test for that line.
8.4.2. AN-Side Procedures 8.4.2. AN-Side Procedures
The AN-side ANCP agent SHOULD validate each message against the The AN-side ANCP agent SHOULD validate each message against the
specifications given in Section 8.3 and the TLV specifications given specifications given in Section 8.3 and the TLV specifications given
in Section 5.1.2 and Section 8.5. If it finds an error it MUST in Section 5.1.2 and Section 8.5. If it finds an error it MUST
return a Port Management response message which copies the Port return a Port Management response message which copies the Port
Management request as it was received, but has the Result header Management request as it was received, but has the Result header
field set to 0x04 (Failure) and the Code field set to the appropriate field set to 0x04 (Failure) and the Result Code field set to the
value. Code value 1289 as described below MAY apply, as well as the appropriate value. Result Code value 0x509 as described below MAY
other Code values documented in Section 3.6.1.4. Code value 1289 apply, as well as the other Result Code values documented in
SHOULD be used if the OAM-Loopback-Test-Parameters TLV is present Section 3.6.1.4. Result Code value 0x509 SHOULD be used if the OAM-
with an invalid value of the Count field. The AN-side agent MAY add Loopback-Test-Parameters TLV is present with an invalid value of the
a Status-Info TLV (Section 4.5) to provide further information on the Count field. The AN-side agent MAY add a Status-Info TLV
error, particularly if this is recommended in Section 3.6.1.4 for the (Section 4.5) to provide further information on the error,
given Code value. If it does so, the various length fields and the # particularly if this is recommended in Section 3.6.1.4 for the given
of TLVs field within the message MUST be adjusted accordingly. 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 If the received message passes validation, the AN-side ANCP agent
"must" extract the information from the TLVs contained in the message extracts the information from the TLVs contained in the message and
and present that information to the AN control application. It MUST presents that information to the AN control application. It MUST NOT
NOT generate an immediate response to the request, but MUST instead generate an immediate response to the request, but MUST instead wait
wait for the AN control application to indicate that the response for the AN control application to indicate that the response should
should be sent. be sent.
When requested by the AN control application and presented with the When requested by the AN control application and presented with the
necessary information to do so, the AN-side agent MUST create and necessary information to do so, the AN-side agent creates and sends a
send a Port Management (OAM) response to the original request. The Port Management (OAM) response to the original request. The Result
Result field MUST be set to Success (0x3) or Failure (0x4), and the 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 Code field SHOULD be set to one of the following values, as indicated
by the AN control application. by the AN control application.
1280 (0x500): Specified access line does not exist. See the 0x500: Specified access line does not exist. See the documentation
documentation of Code 3/1280 in Section 3.6.1.4 for more of Result Code 0x500 in Section 3.6.1.4 for more information. The
information. The Result header field MUST be set to Failure Result header field MUST be set to Failure (0x4).
(0x4).
1281 (0x501): Loopback test timed out. The Result header field MUST 0x501: Loopback test timed out. The Result header field MUST be set
be set to Failure (0x4). to Failure (0x4).
1283 (0x503): DSL line status showtime 0x503: DSL line status showtime
1284 (0x504): DSL line status idle 0x504: DSL line status idle
1285 (0x505): DSL line status silent 0x505: DSL line status silent
1286 (0x506): DSL line status training 0x506: DSL line status training
1287 (0x507): DSL line integrity error 0x507: DSL line integrity error
1288 (0x508): DSLAM resource not available. The Result header field 0x508: DSLAM resource not available. The Result header field MUST
MUST be set to Failure (0x04). be set to Failure (0x04).
1289 (0x509): Invalid test parameter. The Result header field MUST 0x509: Invalid test parameter. The Result header field MUST be set
be set to Failure (0x4). to Failure (0x4).
All other fields of the request including the TLVs MUST be copied All other fields of the request including the TLVs MUST be copied
into the response unchanged, except that in a successful response the into the response unchanged, except that in a successful response the
OAM-Loopback-Test-Parameters TLV MUST NOT appear. If the AN control OAM-Loopback-Test-Parameters TLV MUST NOT appear. If the AN control
application has provided the necessary information, the AN-side agent application has provided the necessary information, the AN-side agent
MUST also include an instance of the OAM-Loopback-Test-Response- MUST also include an instance of the OAM-Loopback-Test-Response-
String TLV in the response. String TLV in the response.
8.5. TLVs For the DSL Line Remote Connectivity Testing Capability 8.5. TLVs For the DSL Line Remote Connectivity Testing Capability
skipping to change at page 60, line 52 skipping to change at page 70, line 52
Value: two unsigned 1 byte fields described below (listed in order Value: two unsigned 1 byte fields described below (listed in order
of most to least significant). of most to least significant).
Byte 1: Count. Number of loopback cells/messages that should Byte 1: Count. Number of loopback cells/messages that should
be generated on the local loop as part of the loopback test. 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 The Count value SHOULD be greater than 0 and less than or equal
to 32. to 32.
Byte 2: Timeout. Upper bound on the time in seconds that the 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 NAS will wait for a response from the DSLAM. The value 0 MAY
be used, but has a special meaning. 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 21 The OAM-Loopback-Test-Parameters TLV is illustrated in Figure 22
0 1 2 3 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 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 | | TLV Type = 0x0007 | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count | Timeout | Padding (=0) | | Count | Timeout | Padding (=0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: The OAM-Loopback-Test-Parameters TLV Figure 22: The OAM-Loopback-Test-Parameters TLV
8.5.2. Opaque-Data TLV 8.5.2. Opaque-Data TLV
Type: 0x0008 Type: 0x0008
Description: An 8 byte opaque field used by the NAS control Description: An 8 byte opaque field used by the NAS control
application for its own purposes (e.g., response correlation.) application for its own purposes (e.g., response correlation.)
The procedures in Section 8.4.2 ensure that if it is present in The procedures in Section 8.4.2 ensure that if it is present in
the request it is copied unchanged to the response. the request it is copied unchanged to the response.
skipping to change at page 61, line 45 skipping to change at page 71, line 46
about the test that the NAS will display for the operator, exactly about the test that the NAS will display for the operator, exactly
as received from the DSLAM (no manipulation or interpretation by as received from the DSLAM (no manipulation or interpretation by
the NAS). the NAS).
Length: up to 128 bytes Length: up to 128 bytes
Value: UTF-8 encoded string of text. Value: UTF-8 encoded string of text.
9. IANA Considerations 9. IANA Considerations
RFC EDITOR'S NOTE: please replace "RFCXXXX" with the number of this IANA NOTE: please replace "RFCXXXX" with the number of this
specification. specification.
9.1. Summary 9.1. Summary
This section requests the following IANA actions: This section requests the following IANA actions:
o addition of message types to the GSMPv3 Message Type Name Space o establishment of the following new ANCP registries:
registry;
o addition of a result type to the GSMPv3 Result Type Name Space
registry;
o extension of limits and addition of failure codes to the GSMPv3 ANCP Message Types;
Failure Response Message Name Space registry;
o establishment of the following new ANCP registries: ANCP Result Codes;
ANCP Function Codes; ANCP Port Management Functions;
ANCP Technology Types; ANCP Technology Types;
ANCP Command Codes; ANCP Command Codes;
ANCP TLV Types; ANCP TLV Types;
ANCP Capabilities. 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 at http://www.iana.org/assignments/port-numbers.
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 should provide
sufficient information.
9.2. IANA Actions 9.2. IANA Actions
IANA is requested to add a new message category to the GSMPv3 Message 9.2.1. ANCP Message Type Registry
Type Name Space registry: "Access Network Control Protocol (ANCP)
Messages". IANA is requested to add the following entries under that
category:
+------------------+----------------+--------+-----------+ IANA is requested to create a new registry, Access Network Control
| Message Name | Message Number | Status | Reference | Protocol (ANCP) Message Types. Additions to that registry are
+------------------+----------------+--------+-----------+ permitted by Standards Action, as defined by [RFC5226]. The values
| Generic Response | 91 | | RFCXXXX | for Message Type MAY range from 0 to 255, but new Message Types
| Provisioning | 93 | | RFCXXXX | 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:
IANA is requested to implement the following modification to the +--------------+--------------------+-----------+
General Switch Management Protocol version 3 (GSMPv3) Result Type | Message Type | Message Name | Reference |
Name Space registry: +--------------+--------------------+-----------+
| 10 | Adjacency Protocol | RFCXXXX |
| 32 | Port Management | RFCXXXX |
| 80 | Port Up | RFCXXXX |
| 81 | Port Down | RFCXXXX |
| 85 | Adjacency Update | RFCXXXX |
| 91 | Generic Response | RFCXXXX |
| 93 | Provisioning | RFCXXXX |
+--------------+--------------------+-----------+
+--------------+-----------------------+-----------+ 9.2.2. ANCP Result Code Registry
| Result Value | Result Type Name | Reference |
+--------------+-----------------------+-----------+
| 0 | Ignore (was Reserved) | RFCXXXX |
+--------------+-----------------------+-----------+
IANA is requested to implement the following modifications to the IANA is requested to create a new registry, Access Network Control
GSMPv3 Failure Response Message Name Space: Protocol (ANCP) Result Codes. The documentation of new Result Codes
MUST include the following information:
o Add the following note to the registry: o Result Code value TBD (as assigned by IANA);
This registry is shared with the Access Node Control Protocol o One-line description;
(ANCP) [RFCXXXX]. GSMPv3 [RFC3292] allows values up to a
maximum of 255. ANCP extends this maximum to 4095. Hence
values above 255 are applicable to ANCP only.
o Extend the table of registration procedures as indicated. o Where condition detected: (control application or ANCP agent);
o Add entries to the failure response message name table as o Further description (if any);
indicated.
o Replace the ranges of unassigned codes at the end of the failure o Required additional information in the response message;
response message name table as indicated.
+----------+------------------------+---------------+ o Target (control application or ANCP agent at the peer that sent
| Range | Registration Procedure | Notes | the original request);
+----------+------------------------+---------------+
| 256-4095 | IETF Consensus | ANCP use only |
+----------+------------------------+---------------+
+-------+----------------------------------------------+-----------+ o Action RECOMMENDED for the receiving ANCP agent
| Value | Failure Response Message Name | Reference |
+-------+----------------------------------------------+-----------+
| 81 | Request message type not implemented (0x51) | RFCXXXX |
| 83 | Malformed message (0x53) | RFCXXXX |
| 84 | Mandatory TLV missing (0x54) | RFCXXXX |
| 85 | Invalid value in TLV (0x55) | RFCXXXX |
| 1280 | Specified access line does not exist (0x500) | RFCXXXX |
| 1281 | Loopback test timed out (0x501) | RFCXXXX |
| 1282 | Reserved (0x502) | RFCXXXX |
| 1283 | DSL line status showtime (0x503) | RFCXXXX |
| 1284 | DSL line status idle (0x504) | RFCXXXX |
| 1285 | DSL line status silent (0x505) | RFCXXXX |
| 1286 | DSL line status training (0x506) | RFCXXXX |
| 1287 | DSL line integrity error (0x507) | RFCXXXX |
| 1288 | DSLAM resource not available (0x508) | RFCXXXX |
| 1289 | Invalid test parameter (0x509) | RFCXXXX |
+-------+----------------------------------------------+-----------+
+-----------+-------------------------------+-----------+
| Value | Failure Response Message Name | Reference |
+-----------+-------------------------------+-----------+
| 8-9 | Unassigned | |
| 47-59 | Unassigned | |
| 86-127 | Unassigned | |
| 160-255 | Unassigned | |
| 256-1279 | Unassigned (ANCP use only) | |
| 1290-4095 | Unassigned (ANCP use only) | |
+-----------+-------------------------------+-----------+
IANA is requested to create a new ANCP Port Management Function Name The values for Result Code are expressed in hexadecimal, and MAY
registry, with the following initial entries. Additions to this range from 0x0 to 0xFFFFFF. The range 0x0 to 0xFFF is reserved for
registry will be by IETF Consensus. Values may range from 0 to 255. allocation 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 SHALL be
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 | RFCXXXX |
| 0x2 | Invalid request message | RFCXXXX |
| 0x6 | One or more of the specified ports are | RFCXXXX |
| | down | |
| 0x13 | Out of resources | RFCXXXX |
| 0x51 | Request message type not implemented | RFCXXXX |
| 0x53 | Malformed message | RFCXXXX |
| 0x54 | Mandatory TLV missing | RFCXXXX |
| 0x55 | Invalid TLV contents | RFCXXXX |
| 0x500 | One or more of the specified ports do | RFCXXXX |
| | not exist | |
| 0x501 | Loopback test timed out (0x501) | RFCXXXX |
| 0x502 | Reserved (0x502) | RFCXXXX |
| 0x503 | DSL line status showtime (0x503) | RFCXXXX |
| 0x504 | DSL line status idle (0x504) | RFCXXXX |
| 0x505 | DSL line status silent (0x505) | RFCXXXX |
| 0x506 | DSL line status training (0x506) | RFCXXXX |
| 0x507 | DSL line integrity error (0x507) | RFCXXXX |
| 0x508 | DSLAM resource not available (0x508) | RFCXXXX |
| 0x509 | Invalid test parameter (0x509) | RFCXXXX |
+------------+------------------------------------------+-----------+
9.2.3. ANCP Port Management Function Registry
IANA is requested to create a new Access Network Control Protocol
(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- NOTE: future extensions of ANCP may need to establish sub-
registries of permitted X-Function values for specific values of registries of permitted X-Function values for specific values of
Function. Function.
+----------------+-----------------------------------+-----------+ +----------------+-----------------------------------+-----------+
| Function Value | Function Name | Reference | | Function Value | Function Name | Reference |
+----------------+-----------------------------------+-----------+ +----------------+-----------------------------------+-----------+
| 0 | Reserved | RFCXXXX | | 0 | Reserved | RFCXXXX |
| 1-7 | Unassigned | |
| 8 | Configure Connection Service Data | RFCXXXX | | 8 | Configure Connection Service Data | RFCXXXX |
| 9 | Remote Loopback | RFCXXXX | | 9 | Remote Loopback | RFCXXXX |
| 10-255 | Unassigned | |
+----------------+-----------------------------------+-----------+ +----------------+-----------------------------------+-----------+
IANA is requested to create a new ANCP Version registry, with 9.2.4. ANCP Technology Type Registry
additions by IETF consensus. The initial entries are as follows:
+---------+-------------+--------------+-----------+ IANA is requested to create a new Access Network Control Protocol
| Version | Sub-Version | Name | Reference | (ANCP) Technology Type registry, with additions by Expert Review, as
+---------+-------------+--------------+-----------+ defined by [RFC5226]. The Technology Type MUST designate a distinct
| 3 | 1 | Pre-standard | | access transport technology. Values may range from 0 to 255. IANA
| 3 | 2 | ANCPv1 | RFCXXXX | SHOULD assign new values sequentially beginning at 2, taking into
+---------+-------------+--------------+-----------+ account of the values already assigned below. The initial entries
are as follows:
IANA is requested to create a new ANCP Technology Type registry, with +-----------------+--------------------------+-----------+
additions by IETF Consensus. Values may range from 0 to 255. The | Tech Type Value | Tech Type Name | Reference |
initial entries are as follows: +-----------------+--------------------------+-----------+
| 0 | Not technology dependent | RFCXXXX |
| 1 | PON | RFCXXXX |
| 5 | DSL | RFCXXXX |
| 255 | Reserved | RFCXXXX |
+-----------------+--------------------------+-----------+
+-----------------+----------------+-----------+ 9.2.5. ANCP Command Code Registry
| Tech Type Value | Tech Type Name | Reference |
+-----------------+----------------+-----------+
| 0 | Any technology | RFCXXXX |
| 1 | PON | RFCXXXX |
| 2-4 | Unassigned | |
| 5 | DSL | RFCXXXX |
| 6-254 | Unassigned | |
| 255 | Reserved | RFCXXXX |
+-----------------+----------------+-----------+
IANA is requested to create a new ANCP Command Code registry, with IANA is requested to create a new Access Network Control Protocol
additions by IETF Consensus. The initial entry is as follows: (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 | | Command Code Value | Command Code Directive Name | Reference |
+--------------------+-----------------------------+-----------+ +--------------------+-----------------------------+-----------+
| 0 | Reserved | RFCXXXX | | 0 | Reserved | RFCXXXX |
+--------------------+-----------------------------+-----------+ +--------------------+-----------------------------+-----------+
IANA is requested to create a new ANCP TLV Type registry, with 9.2.6. ANCP TLV Type Registry
additions by IETF Consensus. Values may range from 0x0000 to 0xFFFF.
New assignments should be in the range of values from 0x0100 upwards. IANA is requested to create a new Access Network Control Protocol
(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 and
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: The initial entries are as follows:
+--------------+----------------------------------------+-----------+ +----------+--------------------------------------------+-----------+
| Type Code | TLV Name | Reference | | Type | TLV Name | Reference |
+--------------+----------------------------------------+-----------+ | Code | | |
| 0x0000 | Reserved | RFCXXXX | +----------+--------------------------------------------+-----------+
| 0x0001 | Access-Loop-Circuit-ID | RFCXXXX | | 0x0000 | Reserved | RFCXXXX |
| 0x0002 | Access-Loop-Remote-Id | RFCXXXX | | 0x0001 | Access-Loop-Circuit-ID | RFCXXXX |
| 0x0003 | Access-Aggregation-Circuit-ID-ASCII | RFCXXXX | | 0x0002 | Access-Loop-Remote-Id | RFCXXXX |
| 0x0004 | DSL-Line-Attributes | RFCXXXX | | 0x0003 | Access-Aggregation-Circuit-ID-ASCII | RFCXXXX |
| 0x0005 | Service-Profile-Name | RFCXXXX | | 0x0004 | DSL-Line-Attributes | RFCXXXX |
| 0x0006 | Access-Aggregation-Circuit-ID-Binary | RFCXXXX | | 0x0005 | Service-Profile-Name | RFCXXXX |
| 0x0007 | OAM-Loopback-Test-Parameters | RFCXXXX | | 0x0006 | Access-Aggregation-Circuit-ID-Binary | RFCXXXX |
| 0x0008 | Opaque-Data | RFCXXXX | | 0x0007 | OAM-Loopback-Test-Parameters | RFCXXXX |
| 0x0009 | OAM-Loopback-Test-Response-String | RFCXXXX | | 0x0008 | Opaque-Data | RFCXXXX |
| 0x000a-0x001 | Unassigned | | | 0x0009 | OAM-Loopback-Test-Response-String | RFCXXXX |
| 0 | | | | 0x0011 | Command | RFCXXXX |
| 0x0011 | Command | RFCXXXX | | 0x0081 | Actual-Net-Data-Upstream | RFCXXXX |
| 0x0012-0x008 | Unassigned | | | 0x0082 | Actual-Net-Data-Rate-Downstream | RFCXXXX |
| 0 | | | | 0x0083 | Minimum-Net-Data-Rate-Upstream | RFCXXXX |
| 0x0081 | Actual-Net-Data-Upstream | RFCXXXX | | 0x0084 | Minimum-Net-Data-Rate-Downstream | RFCXXXX |
| 0x0082 | Actual-Net-Data-Rate-Downstream | RFCXXXX | | 0x0085 | Attainable-Net-Data-Rate-Upstream | RFCXXXX |
| 0x0083 | Minimum-Net-Data-Rate-Upstream | RFCXXXX | | 0x0086 | Attainable-Net-Data-Rate-Downstream | RFCXXXX |
| 0x0084 | Minimum-Net-Data-Rate-Downstream | RFCXXXX | | 0x0087 | Maximum-Net-Data-Rate-Upstream | RFCXXXX |
| 0x0085 | Attainable-Net-Data-Rate-Upstream | RFCXXXX | | 0x0088 | Maximum-Net-Data-Rate-Downstream | RFCXXXX |
| 0x0086 | Attainable-Net-Data-Rate-Downstream | RFCXXXX | | 0x0089 | Minimum-Net-Low-Power-Data-Rate-Upstream | RFCXXXX |
| 0x0087 | Maximum-Net-Data-Rate-Upstream | RFCXXXX | | 0x008A | Minimum-Net-Low-Power-Data-Rate-Downstream | RFCXXXX |
| 0x0088 | Maximum-Net-Data-Rate-Downstream | RFCXXXX | | 0x008B | Maximum-Interleaving-Delay-Upstream | RFCXXXX |
| 0x0089 | Minimum-Net-Low-Power-Data-Rate-Upstre | RFCXXXX | | 0x008C | Actual-Interleaving-Delay-Upstream | RFCXXXX |
| | am | | | 0x008D | Maximum-Interleaving-Delay-Downstream | RFCXXXX |
| 0x008A | Minimum-Net-Low-Power-Data-Rate-Downst | RFCXXXX | | 0x008E | Actual-Interleaving-Delay-Downstream | RFCXXXX |
| | ream | | | 0x008F | DSL-Line-State | RFCXXXX |
| 0x008B | Maximum-Interleaving-Delay-Upstream | RFCXXXX | | 0x0090 | Access-Loop-Encapsulation | RFCXXXX |
| 0x008C | Actual-Interleaving-Delay-Upstream | RFCXXXX | | 0x0091 | DSL-Type | RFCXXXX |
| 0x008D | Maximum-Interleaving-Delay-Downstream | RFCXXXX | | 0x0106 | Status-Info | RFCXXXX |
| 0x008E | Actual-Interleaving-Delay-Downstream | RFCXXXX | | 0x1000 | Target (single access line variant) | RFCXXXX |
| 0x008F | DSL-Line-State | RFCXXXX | | 0x1001 - | Reserved for Target variants | RFCXXXX |
| 0x0090 | Access-Loop-Encapsulation | RFCXXXX | | 0x1020 | | |
| 0x0091 | DSL-Type | RFCXXXX | +----------+--------------------------------------------+-----------+
| 0x092-0x0105 | Unassigned | |
| 0x0106 | Status-Info | RFCXXXX |
| 0x0107-0x0FF | Unassigned | |
| F | | |
| 0x1000 | Target (single access line variant) | RFCXXXX |
| 0x1001 - | Reserved for Target variants | RFCXXXX |
| 0x1020 | | |
| 0x1021-0xFFF | Unassigned | |
| F | | |
+--------------+----------------------------------------+-----------+
IANA is requested to create a new ANCP Capability registry, with
additions by IETF Consensus. Values may range from 0 to 255. The
specification for a given capability MUST indicate whether it applies
to a specific access technology or applies to all access
technologies. The specification MUST further indicate whether the
capability is associated with any capability data. The initial
entries in the ANCP capability registry are as follows:
+-------+-------------------+------------+--------------+-----------+ 9.2.7. ANCP Capability Type Registry
| Value | Capability Type | Technology | Capability | Reference |
| | Name | | Data | | IANA is requested to create a new Access Network Control Protocol
+-------+-------------------+------------+--------------+-----------+ (ANCP) Capability Type registry, with additions by Standards Action
| 0 | Reserved | | | RFCXXXX | as defined by [RFC5226]. Values may range from 0 to 255. IANA
| 1 | DSL Topology | DSL | None | RFCXXXX | SHOULD assign values sequentially beginning at 5. The specification
| | Discovery | | | | for a given capability MUST indicate the Technology Type value with
| 2 | DSL Line | DSL | None | RFCXXXX | which it is associated. The specification MUST further indicate
| | Configuration | | | | whether the capability is associated with any capability data.
| 3 | Reserved | | | RFCXXXX | Normally a capability is expected to be defined in the same document
| 4 | DSL Line Testing | DSL | None | RFCXXXX | that specifies the implementation of that capability in protocol
| 5-255 | Unassigned | | | | terms. The initial entries in the ANCP capability registry are as
+-------+-------------------+------------+--------------+-----------+ follows:
+-------+-----------------+--------------+--------------+-----------+
| Value | Capability Type | Technology | Capability | Reference |
| | Name | Type | Data | |
+-------+-----------------+--------------+--------------+-----------+
| 0 | Reserved | | | RFCXXXX |
| 1 | DSL Topology | 5 | No | RFCXXXX |
| | Discovery | | | |
| 2 | DSL Line | 5 | No | RFCXXXX |
| | Configuration | | | |
| 3 | Reserved | | | RFCXXXX |
| 4 | DSL Line | 5 | None | RFCXXXX |
| | Testing | | | |
+-------+-----------------+--------------+--------------+-----------+
9.2.8. Joint GSMP / ANCP Version Registry
IANA is requested to create 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 | RFC1987 |
| 2 | GSMP Version 2 | RFC2297 |
| 3 | GSMP Version 3 | RFC3292 |
| 50 | ANCP Version 1 | RFCXXXX |
+---------+----------------+-----------+
10. Security Considerations 10. Security Considerations
Security of the ANCP protocol is discussed in [RFC5713]. A number of Security of the ANCP protocol is discussed in [RFC5713]. A number of
security requirements on ANCP are stated in Section 8 of that security requirements on ANCP are stated in Section 8 of that
document. Those applicable to ANCP itself are listed here: document. Those applicable to ANCP itself are copied to the present
document:
o The protocol solution MUST offer authentication of the AN to the o The protocol solution MUST offer authentication of the AN to the
NAS. NAS.
o The protocol solution MUST offer authentication of the NAS to the o The protocol solution MUST offer authentication of the NAS to the
AN. AN.
o The protocol solution MUST allow authorization to take place at o The protocol solution MUST allow authorization to take place at
the NAS and the AN. the NAS and the AN.
skipping to change at page 68, line 19 skipping to change at page 79, line 5
interactions. interactions.
Most of these requirements relate to secure transport of ANCP. Most of these requirements relate to secure transport of ANCP.
Robustness against denial-of-service attacks partly depends on Robustness against denial-of-service attacks partly depends on
transport and partly on protocol design. Ensuring a low number of transport and partly on protocol design. Ensuring a low number of
AN/NAS protocol interactions in default mode is purely a matter of AN/NAS protocol interactions in default mode is purely a matter of
protocol design. protocol design.
For secure transport, either the combination of IPsec with IKEv2 For secure transport, either the combination of IPsec with IKEv2
(references below) or the use of TLS [RFC5246] will meet the (references below) or the use of TLS [RFC5246] will meet the
requirements listed above. The deciding point is a detail of requirements listed above. However, the use of TLS has been
protocol design that was unavailable when [RFC5713] was written. The rejected. The deciding point is a detail of protocol design that was
ANCP adjacency is a major point of vulnerability for denial-of- unavailable when [RFC5713] was written. The ANCP adjacency is a
service attacks. If the adjacency can be shut down, either the AN major point of vulnerability for denial-of-service attacks. If the
clears its state pending reestablishment of the adjacency, or the adjacency can be shut down, either the AN clears its state pending
possibility of mismatches between the AN's and NAS's view of state on reestablishment of the adjacency, or the possibility of mismatches
the AN is opened up. Two ways to cause an adjacency to be taken down between the AN's and NAS's view of state on the AN is opened up. Two
are to modify messages so that the ANCP agents conclude that they are ways to cause an adjacency to be taken down are to modify messages so
no longer synchronized, or to attack the underlying TCP session. TLS that the ANCP agents conclude that they are no longer synchronized,
will protect message contents, but not the TCP connection. One has or to attack the underlying TCP session. TLS will protect message
to use either IPsec or the TCP authentication option [RFC5925] for contents, but not the TCP connection. One has to use either IPsec or
that. Hence the conclusion that ANCP MUST run over IPsec with IKEv2 the TCP authentication option [RFC5925] for that. Hence the
for authentication and key management. conclusion that ANCP MUST run over IPsec with IKEv2 for
authentication and key management.
In greater detail: the ANCP stack MUST include IPsec [RFC4301] In greater detail: the ANCP stack MUST include IPsec [RFC4301]
running in transport mode, since the AN and NAS are the endpoints of running in transport mode, since the AN and NAS are the endpoints of
the path. The Encapsulating Security Payload (ESP) [RFC4303] MUST be the path. The Encapsulating Security Payload (ESP) [RFC4303] MUST be
used, in order to satisfy the requirement for data confidentiality. used, in order to satisfy the requirement for data confidentiality.
ESP MUST be configured for the combination of confidentiality, ESP MUST be configured for the combination of confidentiality,
integrity, anti-replay capability. The traffic flow confidentiality integrity, anti-replay capability. The traffic flow confidentiality
service of ESP is unnecessary and, in fact, unworkable in the case of service of ESP is unnecessary and, in fact, unworkable in the case of
ANCP. ANCP.
skipping to change at page 69, line 14 skipping to change at page 79, line 46
11. Acknowledgements 11. Acknowledgements
The authors would like to thank everyone who provided comments or The authors would like to thank everyone who provided comments or
inputs to this document. Swami Subramanian was an early member of inputs to this document. Swami Subramanian was an early member of
the authors' team. The ANCP Working Group is grateful to Roberta the authors' team. The ANCP Working Group is grateful to Roberta
Maglione, who served as design team member and primary editor of this Maglione, who served as design team member and primary editor of this
document for two years before stepping down. The authors acknowledge document for two years before stepping down. The authors acknowledge
the inputs provided by Wojciech Dec, Peter Arberg, Josef Froehler, the inputs provided by Wojciech Dec, Peter Arberg, Josef Froehler,
Derek Harkness, Kim Hyldgaard, Sandy Ng, Robert Peschi, and Michel Derek Harkness, Kim Hyldgaard, Sandy Ng, Robert Peschi, and Michel
Platnic. Platnic, and the further comments provided by Mykyta Yevstifeyev,
Brian Carter, Ben Campbell, Alexey Melnikov, Adrian Farrel, Robert
Sparks, Peter St. Andre, Sean Turner, and Dan Romascanu.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3292] Doria, A., Hellstrand, F., Sundell, K., and T. Worster, [RFC3292] Doria, A., Hellstrand, F., Sundell, K., and T. Worster,
"General Switch Management Protocol (GSMP) V3", RFC 3292, "General Switch Management Protocol (GSMP) V3", RFC 3292,
skipping to change at page 69, line 41 skipping to change at page 80, line 30
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. 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, [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", "Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010. RFC 5996, September 2010.
12.2. Informative References 12.2. Informative References
[G.988.1] "ITU-T recommendation G.998.1, ATM-based multi-pair [G.988.1] "ITU-T recommendation G.998.1, ATM-based multi-pair
bonding", 2005. bonding", 2005.
[G.988.2] "ITU-T recommendation G.998.2, Ethernet-based multi-pair [G.988.2] "ITU-T recommendation G.998.2, Ethernet-based multi-pair
bonding,", 2005. bonding,", 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 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security [RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security
Threats and Security Requirements for the Access Node Threats and Security Requirements for the Access Node
Control Protocol (ANCP)", RFC 5713, January 2010. Control Protocol (ANCP)", RFC 5713, January 2010.
[RFC5851] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. [RFC5851] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S.
Wadhwa, "Framework and Requirements for an Access Node Wadhwa, "Framework and Requirements for an Access Node
Control Mechanism in Broadband Multi-Service Networks", Control Mechanism in Broadband Multi-Service Networks",
 End of changes. 190 change blocks. 
789 lines changed or deleted 1263 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/