draft-ietf-ancp-protocol-17.txt   rfc6320.txt 
Network Working Group S. Wadhwa Internet Engineering Task Force (IETF) S. Wadhwa
Internet-Draft Alcatel-Lucent Request for Comments: 6320 Alcatel-Lucent
Intended status: Standards Track J. Moisand Category: Standards Track J. Moisand
Expires: October 28, 2011 Juniper Networks ISSN: 2070-1721 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
April 26, 2011 October 2011
Protocol for Access Node Control Mechanism in Broadband Networks Protocol for Access Node Control Mechanism in Broadband Networks
draft-ietf-ancp-protocol-17
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 operations
related, service-related and subscriber-related operations. Use related to Quality of Service, service, and subscribers. Use cases
cases for ANCP are documented in RFC 5851. As well as describing the for ANCP are documented in RFC 5851. As well as describing the base
base ANCP protocol, this document specifies capabilities for Digital ANCP protocol, this document specifies capabilities for Digital
Subscriber Line (DSL) topology discovery, line configuration, and Subscriber Line (DSL) topology discovery, line configuration, and
remote line connectivity testing. The design of ANCP allows for remote line connectivity testing. The design of ANCP allows for
protocol extensions in other documents if they are needed to support protocol extensions in other documents if they are needed to support
other use cases and other access technologies. other use cases and other access technologies.
ANCP is based on GSMPv3 (RFC 3292), but with many modifications and ANCP is based on the General Switch Management Protocol version 3
(GSMPv3) described in RFC 3292, but with many modifications and
extensions, to the point that the two protocols are not extensions, to the point that the two protocols are not
interoperable. For this reason, ANCP was assigned a separate version interoperable. For this reason, ANCP was assigned a separate version
number to distinguish it. number to distinguish it.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on October 28, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6320.
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 2, line 34
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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction ....................................................5
1.1. Historical Note . . . . . . . . . . . . . . . . . . . . . 7 1.1. Historical Note ............................................6
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 7 1.2. Requirements Language ......................................6
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 1.3. Terminology ................................................6
2. Broadband Access Aggregation . . . . . . . . . . . . . . . . . 9 2. Broadband Access Aggregation ....................................8
2.1. ATM-based Broadband Aggregation . . . . . . . . . . . . . 9 2.1. ATM-Based Broadband Aggregation ............................8
2.2. Ethernet-Based Broadband Aggregation . . . . . . . . . . . 10 2.2. Ethernet-Based Broadband Aggregation .......................9
3. Access Node Control Protocol -- General Aspects . . . . . . . 11 3. Access Node Control Protocol -- General Aspects ................10
3.1. Protocol Version . . . . . . . . . . . . . . . . . . . . . 11 3.1. Protocol Version ..........................................10
3.2. ANCP Transport . . . . . . . . . . . . . . . . . . . . . . 11 3.2. ANCP Transport ............................................10
3.3. Encoding of Text Fields . . . . . . . . . . . . . . . . . 12 3.3. Encoding of Text Fields ...................................11
3.4. Treatment of Reserved and Unused Fields . . . . . . . . . 12 3.4. Treatment of Reserved and Unused Fields ...................12
3.5. The ANCP Adjacency Protocol . . . . . . . . . . . . . . . 13 3.5. The ANCP Adjacency Protocol ...............................12
3.5.1. ANCP Adjacency Message Format . . . . . . . . . . . . 13 3.5.1. ANCP Adjacency Message Format ......................12
3.5.2. ANCP Adjacency Procedures . . . . . . . . . . . . . . 19 3.5.2. ANCP Adjacency Procedures ..........................18
3.6. ANCP General Message Formats . . . . . . . . . . . . . . . 29 3.6. ANCP General Message Formats ..............................29
3.6.1. The ANCP Message Header . . . . . . . . . . . . . . . 30 3.6.1. The ANCP Message Header ............................29
3.6.2. The ANCP Message Body . . . . . . . . . . . . . . . . 36 3.6.2. The ANCP Message Body ..............................36
3.7. General Principles for the Design of ANCP Messages . . . . 37 3.7. General Principles for the Design of ANCP Messages ........37
4. Generally Useful ANCP Messages and TLVs . . . . . . . . . . . 38
4.1. Provisioning Message . . . . . . . . . . . . . . . . . . . 38 4. Generally Useful ANCP Messages and TLVs ........................38
4.2. Generic Response Message . . . . . . . . . . . . . . . . . 39 4.1. Provisioning Message ......................................38
4.3. Target TLV . . . . . . . . . . . . . . . . . . . . . . . . 41 4.2. Generic Response Message ..................................39
4.4. Command TLV . . . . . . . . . . . . . . . . . . . . . . . 42 4.3. Target TLV ................................................41
4.5. Status-Info TLV . . . . . . . . . . . . . . . . . . . . . 42 4.4. Command TLV ...............................................41
5. Introduction To ANCP Capabilities For Digital Subscriber 4.5. Status-Info TLV ...........................................42
Lines (DSL) . . . . . . . . . . . . . . . . . . . . . . . . . 44 5. Introduction to ANCP Capabilities for Digital
5.1. DSL Access Line Identification . . . . . . . . . . . . . . 44 Subscriber Lines (DSLs) ........................................43
5.1.1. Control Context (Informative) . . . . . . . . . . . . 44 5.1. DSL Access Line Identification ............................44
5.1.2. TLVs For DSL Access Line Identification . . . . . . . 46 5.1.1. Control Context (Informative) ......................44
6. ANCP Based DSL Topology Discovery . . . . . . . . . . . . . . 49 5.1.2. TLVs for DSL Access Line Identification ............45
6.1. Control Context (Informative) . . . . . . . . . . . . . . 49 6. ANCP-Based DSL Topology Discovery ..............................48
6.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 50 6.1. Control Context (Informative) .............................48
6.2.1. Protocol Requirements On the AN Side . . . . . . . . . 51 6.2. Protocol Requirements .....................................50
6.2.2. Protocol Requirements On the NAS Side . . . . . . . . 51 6.2.1. Protocol Requirements on the AN Side ...............50
6.3. ANCP Port UP and Port DOWN Event Message Descriptions . . 51 6.2.2. Protocol Requirements on the NAS Side ..............50
6.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 53 6.3. ANCP Port Up and Port Down Event Message Descriptions .....51
6.4.1. Procedures On the AN Side . . . . . . . . . . . . . . 53 6.4. Procedures ................................................52
6.4.2. Procedures On the NAS Side . . . . . . . . . . . . . . 53 6.4.1. Procedures on the AN Side ..........................52
6.5. TLVs For DSL Line Attributes . . . . . . . . . . . . . . . 54 6.4.2. Procedures on the NAS Side .........................53
6.5.1. DSL-Line-Attributes TLV . . . . . . . . . . . . . . . 54 6.5. TLVs for DSL Line Attributes ..............................53
6.5.2. DSL-Type TLV . . . . . . . . . . . . . . . . . . . . . 54 6.5.1. DSL-Line-Attributes TLV ............................53
6.5.3. Actual-Net-Data-Rate-Upstream TLV . . . . . . . . . . 55 6.5.2. DSL-Type TLV .......................................54
6.5.4. Actual-Net-Data-Rate-Downstream TLV . . . . . . . . . 55 6.5.3. Actual-Net-Data-Rate-Upstream TLV ..................54
6.5.5. Minimum-Net-Data-Rate-Upstream TLV . . . . . . . . . . 55 6.5.4. Actual-Net-Data-Rate-Downstream TLV ................54
6.5.6. Minimum-Net-Data-Rate-Downstream TLV . . . . . . . . . 56 6.5.5. Minimum-Net-Data-Rate-Upstream TLV .................55
6.5.7. Attainable-Net-Data-Rate-Upstream TLV . . . . . . . . 56 6.5.6. Minimum-Net-Data-Rate-Downstream TLV ...............55
6.5.8. Attainable-Net-Data-Rate-Downstream TLV . . . . . . . 56 6.5.7. Attainable-Net-Data-Rate-Upstream TLV ..............55
6.5.9. Maximum-Net-Data-Rate-Upstream TLV . . . . . . . . . . 56 6.5.8. Attainable-Net-Data-Rate-Downstream TLV ............55
6.5.10. Maximum-Net-Data-Rate-Downstream TLV . . . . . . . . . 56 6.5.9. Maximum-Net-Data-Rate-Upstream TLV .................56
6.5.11. Minimum-Net-Low-Power-Data-Rate-Upstream TLV . . . . . 57 6.5.10. Maximum-Net-Data-Rate-Downstream TLV ..............56
6.5.12. Minimum-Net-Low-Power-Data-Rate-Downstream TLV . . . . 57 6.5.11. Minimum-Net-Low-Power-Data-Rate-Upstream TLV ......56
6.5.13. Maximum-Interleaving-Delay-Upstream TLV . . . . . . . 57 6.5.12. Minimum-Net-Low-Power-Data-Rate-Downstream TLV ....56
6.5.14. Actual-Interleaving-Delay-Upstream TLV . . . . . . . . 57 6.5.13. Maximum-Interleaving-Delay-Upstream TLV ...........57
6.5.15. Maximum-Interleaving-Delay-Downstream TLV . . . . . . 58 6.5.14. Actual-Interleaving-Delay-Upstream TLV ............57
6.5.16. Actual-Interleaving-Delay-Downstream . . . . . . . . . 58 6.5.15. Maximum-Interleaving-Delay-Downstream TLV .........57
6.5.17. DSL-Line-State TLV . . . . . . . . . . . . . . . . . . 58 6.5.16. Actual-Interleaving-Delay-Downstream ..............57
6.5.18. Access-Loop-Encapsulation TLV . . . . . . . . . . . . 58 6.5.17. DSL-Line-State TLV ................................58
7. ANCP based DSL Line Configuration . . . . . . . . . . . . . . 60 6.5.18. Access-Loop-Encapsulation TLV .....................58
7.1. Control Context (Informative) . . . . . . . . . . . . . . 60 7. ANCP-Based DSL Line Configuration ..............................59
7.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 61 7.1. Control Context (Informative) .............................59
7.2.1. Protocol Requirements On the NAS Side . . . . . . . . 61 7.2. Protocol Requirements .....................................61
7.2.2. Protocol Requirements On the AN Side . . . . . . . . . 61 7.2.1. Protocol Requirements on the NAS Side ..............61
7.3. ANCP Port Management (Line Configuration) Message 7.2.2. Protocol Requirements on the AN Side ...............61
Format . . . . . . . . . . . . . . . . . . . . . . . . . . 62 7.3. ANCP Port Management (Line Configuration) Message Format ..62
7.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 64 7.4. Procedures ................................................64
7.4.1. Procedures On the NAS Side . . . . . . . . . . . . . . 64 7.4.1. Procedures on the NAS Side .........................64
7.4.2. Procedures On the AN Side . . . . . . . . . . . . . . 64 7.4.2. Procedures on the AN Side ..........................64
7.5. TLVs For DSL Line Configuration . . . . . . . . . . . . . 65
7.5.1. Service-Profile-Name TLV . . . . . . . . . . . . . . . 65 7.5. TLVs for DSL Line Configuration ...........................64
8. ANCP-Based DSL Remote Line Connectivity Testing . . . . . . . 65 7.5.1. Service-Profile-Name TLV ...........................65
8.1. Control Context (Informative) . . . . . . . . . . . . . . 65 8. ANCP-Based DSL Remote Line Connectivity Testing ................65
8.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 66 8.1. Control Context (Informative) .............................65
8.2.1. Protocol Requirements On the NAS Side . . . . . . . . 66 8.2. Protocol Requirements .....................................66
8.2.2. Protocol Requirements On the AN Side . . . . . . . . . 66 8.2.1. Protocol Requirements on the NAS Side ..............66
8.3. Port Management (OAM) Message Format . . . . . . . . . . . 67 8.2.2. Protocol Requirements on the AN Side ...............66
8.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 68 8.3. Port Management (OAM) Message Format ......................67
8.4.1. NAS-Side Procedures . . . . . . . . . . . . . . . . . 68 8.4. Procedures ................................................68
8.4.2. AN-Side Procedures . . . . . . . . . . . . . . . . . . 69 8.4.1. NAS-Side Procedures ................................68
8.5. TLVs For the DSL Line Remote Connectivity Testing 8.4.2. AN-Side Procedures .................................69
Capability . . . . . . . . . . . . . . . . . . . . . . . . 70 8.5. TLVs for the DSL Line Remote Connectivity Testing
8.5.1. OAM-Loopback-Test-Parameters TLV . . . . . . . . . . . 70 Capability ................................................70
8.5.2. Opaque-Data TLV . . . . . . . . . . . . . . . . . . . 71 8.5.1. OAM-Loopback-Test-Parameters TLV ...................70
8.5.3. OAM-Loopback-Test-Response-String TLV . . . . . . . . 71 8.5.2. Opaque-Data TLV ....................................71
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71 8.5.3. OAM-Loopback-Test-Response-String TLV ..............71
9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 72 9. IANA Considerations ............................................71
9.2. IANA Actions . . . . . . . . . . . . . . . . . . . . . . . 72 10. IANA Actions ..................................................72
9.2.1. ANCP Message Type Registry . . . . . . . . . . . . . . 72 10.1. ANCP Message Type Registry ...............................72
9.2.2. ANCP Result Code Registry . . . . . . . . . . . . . . 73 10.2. ANCP Result Code Registry ................................73
9.2.3. ANCP Port Management Function Registry . . . . . . . . 74 10.3. ANCP Port Management Function Registry ...................74
9.2.4. ANCP Technology Type Registry . . . . . . . . . . . . 75 10.4. ANCP Technology Type Registry ............................75
9.2.5. ANCP Command Code Registry . . . . . . . . . . . . . . 75 10.5. ANCP Command Code Registry ...............................75
9.2.6. ANCP TLV Type Registry . . . . . . . . . . . . . . . . 75 10.6. ANCP TLV Type Registry ...................................75
9.2.7. ANCP Capability Type Registry . . . . . . . . . . . . 77 10.7. ANCP Capability Type Registry ............................77
9.2.8. Joint GSMP / ANCP Version Registry . . . . . . . . . . 77 10.8. Joint GSMP / ANCP Version Registry .......................77
10. Security Considerations . . . . . . . . . . . . . . . . . . . 78 11. Security Considerations .......................................77
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 79 12. Contributors ..................................................79
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 79 13. Acknowledgements ..............................................79
12.1. Normative References . . . . . . . . . . . . . . . . . . . 79 14. References ....................................................79
12.2. Informative References . . . . . . . . . . . . . . . . . . 80 14.1. Normative References .....................................79
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 81 14.2. Informative References ...................................80
1. Introduction 1. Introduction
This draft defines a new protocol, the Access Node Control Protocol This document defines a new protocol, the Access Node Control
(ANCP), to realize a control plane between a service-oriented layer 3 Protocol (ANCP), to realize a control plane between a service-
edge device (the Network Access Server, NAS) and a layer 2 Access oriented layer 3 edge device (the Network Access Server, NAS) and a
Node (e.g., Digital Subscriber Line Access Module, DSLAM) in order to layer 2 Access Node (e.g., Digital Subscriber Line Access
perform operations related to quality of service (QoS), services, and Multiplexer, DSLAM) in order to perform operations related to quality
subscriptions. The requirements for ANCP and the context within of service (QoS), services, and subscriptions. The requirements for
which it operates are described in [RFC5851]. ANCP and the context within which it operates are described in
[RFC5851].
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
+--------------------+ +--------------------+ +--------------------+ +--------------------+
| +----------------+ | | +----------------+ | | +----------------+ | | +----------------+ |
| | AN Control | | | | NAS Control | | | | AN Control | | | | NAS Control | |
| | Application | | | | Application | | | | Application | | | | Application | |
| +----------------+ | | +----------------+ | | +----------------+ | | +----------------+ |
| +----------------+ | | +----------------+ | | +----------------+ | | +----------------+ |
| | ANCP Agent | | ANCP Messages | | ANCP Agent | | | | ANCP Agent | | ANCP Messages | | ANCP Agent | |
| | (AN side) |<----------------------->| (NAS side) | | | | (AN side) |<----------------------->| (NAS side) | |
| +----------------+ | | +----------------+ | | +----------------+ | | +----------------+ |
+--------------------+ +--------------------+ +--------------------+ +--------------------+
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 in Section 3.2. encapsulation for ANCP is as defined in Section 3.2.
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 Sections 1.2 and 1.3 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 ANCP.
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. This section o Section 9 is the IANA Considerations section. This section
defines a number of new ANCP-specific registries, as well as the defines a number of new ANCP-specific registries as well as the
joint GSMP/ANCP version registry mentioned below. joint GSMP/ANCP version registry mentioned below.
o Section 10 addresses security considerations relating to ANCP, o Section 11 addresses security considerations relating to ANCP,
beginning with the requirements stated in [RFC5713]. beginning with the requirements stated in [RFC5713].
1.1. Historical Note 1.1. Historical Note
Initial implementations of the protocol that became ANCP were based Initial implementations of the protocol that became ANCP were based
on GSMPv3 [RFC3292]. The ANCP charter required the Working Group to on the General Switch Management Protocol version 3 (GSMPv3)
develop its protocol based on these implementations. In the end, [RFC3292]. The ANCP charter required the Working Group to develop
ANCP introduced so many extensions and modifications to GSMPv3 that its protocol based on these implementations. In the end, ANCP
the two protocols are not interoperable. Nevertheless, although this introduced so many extensions and modifications to GSMPv3 that the
two protocols are not interoperable. Nevertheless, although this
specification has no normative dependencies on [RFC3292], the mark of specification has no normative dependencies on [RFC3292], the mark of
ANCP's origins can be seen in the various unused fields within the ANCP's origins can be seen in the various unused fields within the
ANCP message header. ANCP message header.
Early in ANCP's development the decision was made to use the same TCP Early in ANCP's development, the decision was made to use the same
port and encapsulation as GSMPv3, and by the time ANCP was finished TCP port and encapsulation as GSMPv3, and by the time ANCP was
it was too late to reverse that decision because of existing finished, it was too late to reverse that decision because of
implementations. As a result, it is necessary to have a way for an existing implementations. As a result, it is necessary to have a way
ANCP peer to quickly distinguish ANCP from GSMP during initial for an ANCP peer to quickly distinguish ANCP from GSMP during initial
adjacency negotiations. This has been provided by a joint registry adjacency negotiations. This has been provided by a joint registry
of GSMP and ANCP version numbers. GSMP has version numbers 1 through of GSMP and ANCP version numbers. GSMP has version numbers 1 through
3. ANCP has the initial version number 50. 3. ANCP has the initial version number 50.
1.2. Requirements Language 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].
1.3. Terminology 1.3. Terminology
This section repeats some definitions from [RFC5851], but also adds This section repeats some definitions from [RFC5851], but it also
definitions for terms used only in this document. adds 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
Access Multiplexer (DSLAM). Multiplexer (DSLAM).
Network Access Server (NAS): [RFC5851] Network element which Network Access Server (NAS): [RFC5851] Network element that
aggregates subscriber traffic from a number of Access Nodes. The aggregates subscriber traffic from a number of Access Nodes. The
NAS is an enforcement point for policy management and IP QoS in NAS is an enforcement point for policy management and IP QoS in
the access network. It is also referred to as a Broadband Network the access network. It is also referred to as a Broadband Network
Gateway (BNG) or Broadband Remote Access Server (BRAS). Gateway (BNG) or Broadband Remote Access Server (BRAS).
Home Gateway (HGW): Network element that connects subscriber devices Home Gateway (HGW): Network element that connects subscriber devices
to the Access Node and the access network. In the case of DSL, to the Access Node and the access network. In the case of DSL,
the Home Gateway is a DSL network termination that may operate the Home Gateway is a DSL network termination that may operate
either as a layer 2 bridge or as a layer 3 router. In the latter either as a layer 2 bridge or as a layer 3 router. In the latter
case, such a device is also referred to as a Routing Gateway (RG). case, such a device is also referred to as a Routing Gateway (RG).
ANCP agent: A logical entity that implements the ANCP protocol in ANCP agent: A logical entity that implements ANCP in the Access Node
the Access Node (AN-side) or NAS (NAS-side). (AN-side) or NAS (NAS-side).
Access Node control adjacency: (modified from [RFC5851]) the Access Node control adjacency: (modified from [RFC5851]) The
relationship between the AN-side ANCP agent and the NAS-side ANCP relationship between the AN-side ANCP agent and the NAS-side ANCP
agent for the purpose of exchanging Access Node Control Protocol agent for the purpose of exchanging Access Node Control Protocol
messages. The adjacency may either be up or down, depending on messages. The adjacency may be either up or down, depending on
the result of the Access Node Control adjacency protocol the result of the Access Node Control adjacency protocol
operation. operation.
ANCP capability: A specific set of ANCP messages, message content, ANCP capability: A specific set of ANCP messages, message content,
and procedures required to implement a specific use case or set of and procedures required to implement a specific use case or set of
use cases. Some ANCP capabilities are applicable to just one use cases. Some ANCP capabilities are applicable to just one
access technology while others are technology independent. The access technology while others are technology independent. The
capabilities applicable to a given ANCP adjacency are negotiated capabilities applicable to a given ANCP adjacency are negotiated
during adjacency startup. during adjacency startup.
Type-Length-Value (TLV): a data structure consisting of a sixteen- Type-Length-Value (TLV): A data structure consisting of a 16-bit
bit type field, a sixteen-bit length field, and a variable-length type field, a sixteen-bit length field, and a variable-length
value field padded to the nearest 32-bit word boundary, as value field padded to the nearest 32-bit word boundary, as
described in Section 3.6.2. The value field of a TLV can contain described in Section 3.6.2. The value field of a TLV can contain
other TLVs. An IANA registry is maintained for values of the ANCP other TLVs. An IANA registry is maintained for values of the ANCP
TLV Type field. TLV Type field.
Net data rate: [RFC5851] defined by ITU-T G.993.2 [G.993.2], Section Net data rate: [RFC5851] Defined by ITU-T G.993.2 [G.993.2], Section
3.39, i.e., the portion of the total data rate that can be used to 3.39, i.e., the portion of the total data rate that can be used to
transmit user information (e.g., ATM cells or Ethernet frames). transmit user information (e.g., ATM cells or Ethernet frames).
It excludes overhead that pertains to the physical transmission It excludes overhead that pertains to the physical transmission
mechanism (e.g., trellis coding in the case of DSL). It includes mechanism (e.g., trellis coding in the case of DSL). It includes
TPS-TC (Transport Protocol Specific - Transmission Convergence) TPS-TC (Transport Protocol Specific - Transmission Convergence)
encapsulation; this is zero for ATM encapsulation, and non-zero encapsulation; this is zero for ATM encapsulation and non-zero for
for 64/65 encapsulation. 64/65 encapsulation.
Line rate: [RFC5851] defined by ITU-T G.993.2. It contains the Line rate: [RFC5851] Defined by ITU-T G.993.2. It contains the
complete overhead including Reed-Solomon and trellis coding. complete overhead including Reed-Solomon and trellis coding.
DSL multi-pair bonding: method for bonding (or aggregating) multiple DSL multi-pair bonding: Method for bonding (or aggregating) multiple
xDSL lines into a single bi-directional logical link, henceforth xDSL access lines into a single bidirectional logical link,
referred to in this draft as "DSL bonded circuit". DSL "multi- henceforth referred to in this document as "DSL bonded circuit".
pair" bonding allows an operator to combine the data rates on two DSL "multi-pair" bonding allows an operator to combine the data
or more copper pairs, and deliver the aggregate data rate to a rates on two or more copper pairs, and deliver the aggregate data
single customer. ITU-T recommendations G.998.1 and G.998.2 rate to a single customer. ITU-T recommendations G.998.1
respectively describe ATM and Ethernet based multi-pair bonding. [G.998.1] and G.998.2 [G.998.2], respectively, describe ATM- and
Ethernet-based multi-pair bonding.
2. Broadband Access Aggregation 2. Broadband Access Aggregation
2.1. ATM-based Broadband Aggregation 2.1. ATM-Based Broadband Aggregation
The end to end DSL network consists of network service provider (NSP) The end-to-end DSL network consists of network service provider (NSP)
and application service provider (ASP) networks, regional/access and application service provider (ASP) networks, regional/access
network, and customer premises network. Figure 2 shows ATM broadband network, and customer premises network. Figure 2 shows ATM broadband
access network components. access network components.
The regional/access network consists of the regional network, Network The regional/access network consists of the regional network, Network
Access Server (NAS), and the access network as shown in Figure 2. Access Server (NAS), and the access network as shown in Figure 2.
Its primary function is to provide end-to-end transport between the Its primary function is to provide end-to-end transport between the
customer premises and the NSP or ASP. customer premises and the NSP or ASP.
The Access Node terminates the DSL signal. It may be in the form of The Access Node terminates the DSL signal. It may be in the form of
a DSLAM in the central office, or a remote DSLAM, or a Remote Access a DSLAM in the central office, a remote DSLAM, or a Remote Access
Multiplexer (RAM). The Access Node is the first point in the network Multiplexer (RAM). The Access Node is the first point in the network
where traffic on multiple DSL lines will be aggregated onto a single where traffic on multiple DSL access lines will be aggregated onto a
network. single network.
The NAS performs multiple functions in the network. The NAS is the The NAS performs multiple functions in the network. The NAS is the
aggregation point for subscriber traffic. It provides aggregation aggregation point for subscriber traffic. It provides aggregation
capabilities (e.g. IP, PPP, ATM) between the Regional/Access Network capabilities (e.g., IP, PPP, ATM) between the Regional/Access Network
and the NSP or ASP. These include traditional ATM-based offerings and the NSP or ASP. These include traditional ATM-based offerings
and newer, more native IP-based services. This includes support for and newer, more native IP-based services. This includes support for
Point-to-Point Protocol over ATM (PPPoA) and PPP over Ethernet Point-to-Point Protocol over ATM (PPPoA) and PPP over Ethernet
(PPPoE), as well as direct IP services encapsulated over an (PPPoE), as well as direct IP services encapsulated over an
appropriate layer 2 transport. appropriate layer 2 transport.
Beyond aggregation, the NAS is also the enforcement point for policy Beyond aggregation, the NAS is also the enforcement point for policy
management and IP QoS in the regional/access networks. To allow IP management and IP QoS in the regional/access networks. To allow IP
QoS support over an existing non-IP-aware layer 2 access network QoS support over an existing non-IP-aware layer 2 access network
without using multiple layer 2 QoS classes, a mechanism based on without using multiple layer 2 QoS classes, a mechanism based on
hierarchical scheduling is used. This mechanism, defined in hierarchical scheduling is used. This mechanism, defined in
[TR-059], preserves IP QoS over the ATM network between the NAS and [TR-059], preserves IP QoS over the ATM network between the NAS and
the routing gateway (RG) at the edge of the subscriber network, by the Routing Gateway (RG) at the edge of the subscriber network, by
carefully controlling downstream traffic in the NAS, so that carefully controlling downstream traffic in the NAS, so that
significant queuing and congestion does not occur further down the significant queuing and congestion do not occur farther down the ATM
ATM network. This is achieved by using a diffserv-aware hierarchical network. This is achieved by using a Diffserv-aware hierarchical
scheduler in the NAS that will account for downstream trunk scheduler in the NAS that will account for downstream trunk
bandwidths and DSL synchronization rates. bandwidths and DSL synchronization rates.
[RFC5851] provides detailed definitions of the functions of each [RFC5851] provides detailed definitions of the functions of each
network element in the broadband reference architecture. network element in the broadband reference architecture.
Access Customer Access Customer
<--- Aggregation --> <------- Premises -------> <--- Aggregation --> <------- Premises ------->
Network Network Network Network
skipping to change at page 10, line 33 skipping to change at page 9, line 33
NSP| | +-|NAS|-| |ATM |-|Access| --||DSL |-|HGW|-|Subscriber|| NSP| | +-|NAS|-| |ATM |-|Access| --||DSL |-|HGW|-|Subscriber||
---+ Regional| | +---+ | +-----+ | Node | | ||Modem| +---+ |Devices || ---+ Regional| | +---+ | +-----+ | Node | | ||Modem| +---+ |Devices ||
|Broadband| | +---+ | +------+ | |+-----+ +----------+| |Broadband| | +---+ | +------+ | |+-----+ +----------+|
ASP|Network |-+-|NAS| +--------------|---+ +--------------------------+ ASP|Network |-+-|NAS| +--------------|---+ +--------------------------+
---+ | | +---+ | +--------------------------+ ---+ | | +---+ | +--------------------------+
| | | +---+ | |+-----+ +---+ +----------+| | | | +---+ | |+-----+ +---+ +----------+|
+---------+ +-|NAS| +-----|| DSL |-|HGW|-|Subscriber|| +---------+ +-|NAS| +-----|| DSL |-|HGW|-|Subscriber||
+---+ ||Modem| +---+ |Devices || +---+ ||Modem| +---+ |Devices ||
|+-----+ +----------+| |+-----+ +----------+|
+--------------------------+ +--------------------------+
HGW : Home Gateway HGW: Home Gateway
NAS : Network Access Server NAS: Network Access Server
Figure 2: ATM Broadband Aggregation Topology Figure 2: ATM Broadband Aggregation Topology
2.2. Ethernet-Based Broadband Aggregation 2.2. Ethernet-Based Broadband Aggregation
The Ethernet aggregation network architecture builds on the Ethernet The Ethernet aggregation network architecture builds on the Ethernet
bridging/switching concepts defined in IEEE 802. The Ethernet bridging/switching concepts defined in IEEE 802. The Ethernet
aggregation network provides traffic aggregation, class of service aggregation network provides traffic aggregation, class of service
distinction, and customer separation and traceability. VLAN tagging distinction, and customer separation and traceability. VLAN tagging,
defined in IEEE 802.1Q and being enhanced by IEEE 802.1ad is used as defined in [IEEE802.1Q] and enhanced by [IEEE802.1ad], is used as the
standard virtualization mechanism in the Ethernet aggregation standard virtualization mechanism in the Ethernet aggregation
network. The aggregation devices are "provider edge bridges" defined network. The aggregation devices are "provider edge bridges" defined
in IEEE 802.ad. in [IEEE802.1ad].
Stacked VLAN tags provide one possible way to create equivalent of Stacked VLAN tags provide one possible way to create an equivalent of
"virtual paths" and "virtual circuits" in the aggregation network. "virtual paths" and "virtual circuits" in the aggregation network.
The "outer" vlan can be used to create a form of "virtual path" The "outer" VLAN can be used to create a form of "virtual path"
between a given DSLAM and a given NAS. "Inner" VLAN tags create a between a given DSLAM and a given NAS. "Inner" VLAN tags create a
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. (ANCP) that are generally applicable.
3.1. Protocol Version 3.1. Protocol Version
ANCP messages contain an 8-bit protocol version field. For the ANCP messages contain an 8-bit protocol version field. For the
protocol version specified in this document, the value of that field protocol version specified in this document, the value of that field
MUST be set to 50. MUST be set to 50.
3.2. ANCP Transport 3.2. ANCP Transport
This document specifies the use of TCP / IPSec+IKEv2 / IP for This document specifies the use of TCP / IPsec+IKEv2 / IP for
transport of ANCP messages. For further discussion of the use of transport of ANCP messages. For further discussion of the use of
IPSec + IKEv2 see Section 10. The present section deals with the TCP IPsec and IKEv2, see Section 11. The present section deals with the
aspects. Other specifications may introduce additional transports in TCP aspects. Other specifications may introduce additional
the future. transports in the future.
In the case of ATM access, a separate PVC (control channel) In the case of ATM access, a separate permanent virtual circuit
capable of transporting IP MAY be configured between NAS and the (PVC) that is a control channel and is capable of transporting IP
AN for ANCP messages. MAY be configured between the NAS and the 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 an encapsulation When transported over TCP, ANCP messages MUST use an encapsulation
consisting of a four-byte header field prepended to the ANCP message consisting of a 4-byte header field prepended to the ANCP message as
as shown in Figure 3. 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 (16 bits): This identifies a GSMP or ANCP message. It Identifier (16 bits): This identifies a GSMP or ANCP message. It
MUST be set to 0x880C. MUST be set to 0x880C.
Length (16 bits): Total length of the ANCP message in bytes, not Length (16 bits): Total length of the ANCP message in bytes, not
including the 4-byte encapsulating header. including the 4-byte encapsulating header.
The Access Node MUST initiate the TCP session to the NAS, using The Access Node MUST initiate the TCP session to the NAS, using
skipping to change at page 12, line 42 skipping to change at page 11, line 42
The NAS MUST listen on port 6068 for incoming connections from the The NAS MUST listen on port 6068 for incoming connections from the
Access Nodes. 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].
When extracting text fields from a message, the ANCP agent MUST NOT When extracting text fields from a message, the ANCP agent MUST NOT
assume that the fields are zero-terminated. assume that the fields are zero-terminated.
3.4. Treatment of Reserved and Unused Fields 3.4. Treatment of Reserved and Unused Fields
ANCP messages contain a number of fields that are unused or reserved. ANCP messages contain a number of fields that are unused or reserved.
Some fields are always unused (typically because they were inherited Some fields are always unused (typically because they were inherited
skipping to change at page 14, line 20 skipping to change at page 13, line 20
| Sender Name | | Sender Name |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Receiver Name | | Receiver Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Port | | Sender Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Port | | Receiver Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PType | PFlag | Sender Instance | | PType |P Flag | Sender Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Receiver Instance | | Partition ID | Receiver Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 of the ANCP adjacency message are as follows: The fields of the ANCP adjacency message are as follows:
Version (8 bits): ANCP version, which is subject to negotiation. Version (8 bits): ANCP version, which is subject to negotiation.
This is the key parameter by means of which ANCP messages can be This is the key parameter by means of which ANCP messages can be
distinguished from GSMP messages received over the same port. distinguished from GSMP messages received over the same port.
Message Type (8 bits): always has value 10 (adjacency protocol). Message Type (8 bits): Always has value 10 (adjacency protocol).
Timer (8 bits): The Timer field is used to negotiate the timer value Timer (8 bits): The Timer field is used to negotiate the timer value
used in the adjacency protocol with the peer. The timer specifies used in the adjacency protocol with the peer. The timer specifies
the nominal time between periodic adjacency protocol messages. It the nominal time between periodic adjacency protocol messages. It
is a constant for the duration of an ANCP session. The Timer 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 field is specified in units of 100 ms, with a default value of 250
(i.e., 25 seconds). (i.e., 25 seconds).
M-flag (one bit): used in the SYN message to prevent the NAS from M flag (1 bit): Used in the SYN message to prevent the NAS from
synchronizing with another NAS, and the AN from synchronizing with synchronizing with another NAS and the AN from synchronizing with
another AN. In the SYN message, always set to 1 by the NAS, and another AN. In the SYN message, it is always set to 1 by the NAS
to 0 by the AN. In other adjacency message types, always set to 0 and to 0 by the AN. In other adjacency message types, it is
by the sender and ignored by the receiver. always set to 0 by the sender and ignored by the receiver.
Code (7 bits): the adjacency protocol message type. It MUST have Code (7 bits): The adjacency protocol message type. It MUST have
one of the following values: one of the following values:
Code = 1: SYN; Code = 1: SYN;
Code = 2: SYNACK; Code = 2: SYNACK;
Code = 3: ACK; Code = 3: ACK;
Code = 4: RSTACK. Code = 4: RSTACK.
Sender Name (48 bits): For the SYN, SYNACK, and ACK messages, is the Sender Name (48 bits): For the SYN, SYNACK, and ACK messages, is the
identifier of the entity sending the message. The Sender Name is identifier of the entity sending the message. The Sender Name is
a 48-bit quantity that is unique within the operational context of 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 the device. A 48-bit IEEE 802 Media Access Control (MAC) address,
used for the Sender Name. If the Ethernet encapsulation is used if available, may be used for the Sender Name. If the Ethernet
the Sender Name MUST be the Source Address from the MAC header. encapsulation is used, the Sender Name MUST be the Source Address
For the RSTACK message, the Sender Name field is set to the value from the MAC header. For the RSTACK message, the Sender Name
of the Receiver Name field from the incoming message that caused field is set to the value of the Receiver Name field from the
the RSTACK message to be generated. incoming message that caused the RSTACK message to be generated.
Receiver Name (48 bits) for the SYN, SYNACK, and ACK messages, is 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 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 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 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 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 field is set to the value of the Sender Name field from the
incoming message that caused the RSTACK message to be generated. incoming message that caused the RSTACK message to be generated.
Sender Port (32 bits): For the SYN, SYNACK, and ACK messages, is the 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 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 sent. For the RSTACK message, the Sender Port field is set to the
skipping to change at page 16, line 13 skipping to change at page 15, line 13
how the Partition ID is negotiated. how the Partition ID is negotiated.
Type of partition being requested: Type of partition being requested:
0 - no partition; 0 - no partition;
1 - fixed partition request; 1 - fixed partition request;
2 - fixed partition assigned. 2 - fixed partition assigned.
PFlag (4 bits): used to indicate the type of partition request. P Flag (4 bits): Used to indicate the type of partition request.
1 - new adjacency; 1 - new adjacency;
2 - recovered adjacency. 2 - recovered adjacency.
In case of a conflict between the peers' views of the value of In case of a conflict between the peers' views of the value of the
PFlag, the lower value is used. P Flag, the lower value is used.
Sender Instance (24 bits): For the SYN, SYNACK, and ACK messages, is 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 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 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 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 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 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. back up after going down. Zero is not a valid instance number.
For the RSTACK message, the Sender Instance field is set to the For the RSTACK message, the Sender Instance field is set to the
value of the Receiver Instance field from the incoming message value of the Receiver Instance field from the incoming message
that caused the RSTACK message to be generated. that caused the RSTACK message to be generated.
Partition ID (8 bits): field used to associate the message with a Partition ID (8 bits): Field used to associate the message with a
specific partition of the AN. The value of this field is specific partition of the AN. The value of this field is
negotiated during the adjacency procedure. The AN makes the final negotiated during the adjacency procedure. The AN makes the final
decision, but will consider a request from the NAS. If the AN decision, but will consider a request from the NAS. If the AN
does not support partitions, the value of this field MUST be 0. does not support partitions, the value of this field MUST be 0.
Otherwise, it MUST be non-zero. Otherwise, it MUST be non-zero.
Receiver Instance (24 bits): For the SYN, SYNACK, and ACK messages, Receiver Instance (24 bits): For the SYN, SYNACK, and ACK messages,
is what the sender believes is the current instance number for the 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 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 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 far end of the link, this field SHOULD be set to zero. For
the RSTACK message, the Receiver Instance field is set to the the RSTACK message, the Receiver Instance field is set to the
value of the Sender Instance field from the incoming message that value of the Sender Instance field from the incoming message that
caused the RSTACK message to be generated. 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 (8 bits): Indicates the number of Capability fields that
follow.
Total Length: indicates the total number of bytes occupied by the Total Length (16 bits): Indicates the total number of bytes occupied
capability fields that follow. by the 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 below. The detailed format of a the ANCP session is described below. The detailed format of a
capability field is shown in Figure 5 and described below. Capability field is shown in Figure 5 and described 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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Capability Field Figure 5: Capability Field
The sub-fields of this structure are as follows: The sub-fields of this structure are as follows:
Capability Type: indicates the specific capability supported. An Capability Type (16 bits): Indicates the specific capability
IANA registry exists for values of this sub-field. The values supported. An IANA registry exists for values of this sub-field.
specified by this document are listed below. The values specified by this document are listed below.
Capability Length: the number of bytes of data contained in the Capability Length (16 bits): The number of bytes of data contained
Capability Data sub-field, excluding padding. If the definition in the Capability Data sub-field, excluding padding. If the
of a particular capability includes no capability data, the value definition of a particular capability includes no capability data,
of the Capability Length sub-field is zero. the value of the Capability Length sub-field is zero.
Capability Data: contains data associated with the capability as Capability Data (as indicated by Capability Length): Contains data
specified for that capability. If the definition of a particular associated with the capability as specified for that capability.
capability includes no capability data, the Capability Data sub- If the definition of a particular capability includes no
field is absent (has zero length). Otherwise, the Capability Data capability data, the Capability Data sub-field is absent (has zero
sub-field MUST be padded with zeroes as required to terminate on a length). Otherwise, the Capability Data sub-field MUST be padded
4-byte word boundary. The possibility of specifying capability with zeroes as required to terminate on a 4-byte word boundary.
data provides the flexibility to advertise more than the mere The possibility of specifying capability data provides the
presence or absence of a capability if needed. flexibility to advertise more than the mere presence or absence of
a capability if needed.
The following capabilities are defined for ANCP as applied to DSL The following capabilities are defined for ANCP as applied to DSL
access: access:
o Capability Type : DSL Topology Discovery = 0x01 o Capability Type: DSL Topology Discovery = 0x01
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 6. Section 6.
o Capability Type : DSL Line Configuration = 0x02 o Capability Type: DSL Line Configuration = 0x02
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 7. Section 7.
o Capability Type : DSL Remote Line Connectivity Testing = 0x04 o Capability Type: DSL Remote Line Connectivity Testing = 0x04
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 In addition to the adjacency messages whose format is shown in
Figure 6, ANCP adjacency procedures use the Adjacency Update message Figure 6, ANCP adjacency procedures use the Adjacency Update message
(Figure 6) to inform other NASs controlling the same AN partition (Figure 6) to inform other NASs controlling the same AN partition
when a particular NAS joins or loses an adjacency with that when a particular NAS joins or loses an adjacency with that
partition. partition.
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
skipping to change at page 19, line 22 skipping to change at page 18, line 22
|I| SubMessage Number | Length | |I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: The Adjacency Update Message Figure 6: The Adjacency Update Message
The Adjacency Update message is identical to the general ANCP 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 header described in Section 3.6, but the field settings are in part
specific to the Adjacency Update message. The fields in this message specific to the Adjacency Update message. The fields in this message
are as follows: are as follows:
Version (8 bits): the ANCP version negotiated and running in this Version (8 bits): The ANCP version negotiated and running in this
adjacency. adjacency.
Message Type (8 bits): always 85. Message Type (8 bits): Always 85.
Result (4 bits): set to Ignore (0). Result (4 bits): Set to Ignore (0).
Code (12 bits): set to the total number of adjacencies currently Code (12 bits): Set to the total number of adjacencies currently
established on this partition, from the point of view of the AN. established on this partition, from the point of view of the AN.
Partition ID (8 bits): the partition identifier of the partition for Partition ID (8 bits): The partition identifier of the partition for
which this notification is being sent. which this notification is being sent.
Transaction Identifier (24 bits): MUST be set to 0. Transaction Identifier (24 bits): MUST be set to 0.
I (1 bit), SubMessage number (15 bits): set as described in I (1 bit), SubMessage number (15 bits): Set as described in
Section 3.6.1.7. Section 3.6.1.7.
Length (16 bits): set as described in Section 3.6.1.8. Length (16 bits): Set as described in Section 3.6.1.8.
3.5.2. ANCP Adjacency Procedures 3.5.2. ANCP Adjacency Procedures
3.5.2.1. Overview 3.5.2.1. Overview
The ANCP adjacency protocol operates symmetrically between the NAS The ANCP adjacency protocol operates symmetrically between the NAS
and the AN. In the absence of errors or race conditions, each peer and the AN. In the absence of errors or race conditions, each peer
sends a SYN message, receives a SYNACK message in acknowledgement, sends a SYN message, receives a SYNACK message in acknowledgement,
and completes the establishment of the adjacency by sending an ACK and completes the establishment of the adjacency by sending an ACK
message. Through this exchange, each peer learns the values of the message. Through this exchange, each peer learns the values of the
Name, Port, and Instance parameters identifying the other peer, and Name, Port, and Instance parameters identifying the other peer, and
the two peers negotiate the values of the Version, Timer, PFlag, and the two peers negotiate the values of the Version, Timer, P Flag, and
Partition ID parameters and the set of capabilities that the Partition ID parameters and the set of capabilities that the
adjacency will support. adjacency will support.
Once the adjacency has been established, its liveness is periodically Once the adjacency has been established, its liveness is periodically
tested. The peers engage in an ACK message exchange at a frequency tested. The peers engage in an ACK message exchange at a frequency
determined by the negotiated value of the Timer field. determined by the negotiated value of the Timer field.
If an inconsistency, loss of contact, or protocol violation is If an inconsistency, loss of contact, or protocol violation is
detected, the detecting peer can force a restart of the detected, the detecting peer can force a restart of the
synchronization process by sending an RSTACK message to the other synchronization process by sending an RSTACK message to the other
skipping to change at page 20, line 48 skipping to change at page 19, line 49
o The "Verify Adjacency State" operation consists of verifying that o The "Verify Adjacency State" operation consists of verifying that
the contents of the incoming SYNACK message match the adjacency the contents of the incoming SYNACK message match the adjacency
state values previously recorded. state values previously recorded.
o The procedure "Reset the link" is defined as: o The procedure "Reset the link" is defined as:
1. Generate a new instance number for the link. 1. Generate a new instance number for the link.
2. Delete the peer verifier (set to zero the values of Sender 2. Delete the peer verifier (set to zero the values of Sender
Instance, Sender Port, and Sender Name previously stored by Instance, Sender Port, and Sender Name previously stored by
the Record Adjacency State operation). the "Record Adjacency State" operation).
3. Send a SYN message(Section 3.5.2.3.1). 3. Send a SYN message (Section 3.5.2.3.1).
4. Enter the SYNSENT state. 4. Enter the SYNSENT state.
o The state tables use the following Boolean terms and operators. o The state tables use the following Boolean terms and operators.
A. The Sender Instance in the incoming message matches the value A. The Sender Instance in the incoming message matches the value
stored from a previous message by the "Record Adjacency State" stored from a previous message by the "Record Adjacency State"
operation. operation.
B. The Sender Instance, Sender Port, Sender Name and Partition ID B. The Sender Instance, Sender Port, Sender Name, and Partition
fields in the incoming message match the values stored from a ID fields in the incoming message match the values stored from
previous message by the "Record Adjacency State" operation. a previous message by the "Record Adjacency State" operation.
C. The Receiver Instance, Receiver Port, Receiver Name and C. The Receiver Instance, Receiver Port, Receiver Name, and
Partition ID fields in the incoming message match the values Partition ID fields in the incoming message match the values
of the Sender Instance, Sender Port, Sender Name and Partition of the Sender Instance, Sender Port, Sender Name, and
ID currently sent in outgoing SYN, SYNACK, and ACK messages, Partition ID currently sent in outgoing SYN, SYNACK, and ACK
except that the NAS always accepts the Partition ID value messages, except that the NAS always accepts the Partition ID
presented to it in a SYN or SYNACK message. value presented to it in a SYN or SYNACK message.
"&&" Represents the logical AND operation. "&&" Represents the logical AND operation.
"||" Represents the logical OR operation. "||" Represents the logical OR operation.
"!" Represents the logical negation (NOT) operation. "!" Represents the logical negation (NOT) operation.
o A timer is required for the periodic generation of SYN, SYNACK, o A timer is required for the periodic generation of SYN, SYNACK,
and ACK messages. The value of the timer is negotiated in the and ACK messages. The value of the timer is negotiated in the
Timer field. The period of the timer is unspecified but a value Timer field. The period of the timer is unspecified, but a value
of 25 seconds is suggested. Note that since ANCP uses a reliable of 25 seconds is suggested. Note that since ANCP uses a reliable
transport protocol, the timer is unlikely to expire in any state transport protocol, the timer is unlikely to expire in any state
other than ESTAB. other than ESTAB.
There are two independent events: the timer expires, and a packet There are two independent events: the timer expires, and a packet
arrives. The processing rules for these events are: arrives. The processing rules for these events are:
Timer Expires: Reset Timer Timer Expires: Reset Timer
If state = SYNSENT Send SYN If state = SYNSENT Send SYN
skipping to change at page 22, line 11 skipping to change at page 21, line 15
Packet Arrives: Packet Arrives:
If incoming message is an RSTACK: If incoming message is an RSTACK:
If (A && C && !SYNSENT) Reset the link If (A && C && !SYNSENT) Reset the link
Else discard the message. Else discard the message.
If incoming message is a SYN, SYNACK, or ACK: If incoming message is a SYN, SYNACK, or ACK:
Response defined by the following State Tables. Response defined by the following state tables.
If incoming message is any other ANCP message and state != If incoming message is any other ANCP message and state !=
ESTAB: ESTAB:
Discard incoming message. Discard incoming message.
If state = SYNSENT Send SYN (Note 1) If state = SYNSENT Send SYN (Note 1)
If state = SYNRCVD Send SYNACK (Note 1) If state = SYNRCVD Send SYNACK (Note 1)
Note 1: No more than two SYN or SYNACK messages should be sent Note 1: No more than two SYN or SYNACK messages should be sent
within any time period of length defined by the timer. within any time period of length defined by the timer.
o State synchronisation across a link is considered to be achieved o State synchronization across a link is considered to be achieved
when the protocol reaches the ESTAB state. All ANCP messages, when the protocol reaches the ESTAB state. All ANCP messages,
other than adjacency protocol messages, that are received before other than adjacency protocol messages, that are received before
synchronisation is achieved will be discarded. synchronization is achieved will be discarded.
3.5.2.2.1. State Tables 3.5.2.2.1. State Tables
State: SYNSENT State: SYNSENT
+====================================================================+ +===================================================================+
| Condition | Action | New State | | Condition | Action | New State |
+==================+=====================================+===========+ +=================+=====================================+===========+
| SYNACK && C | Update Peer Verifier; Send ACK | ESTAB | | SYNACK && C | Update Peer Verifier; Send ACK | ESTAB |
+------------------+-------------------------------------+-----------+ +-----------------+-------------------------------------+-----------+
| SYNACK && !C | Send RSTACK | SYNSENT | | SYNACK && !C | Send RSTACK | SYNSENT |
+------------------+-------------------------------------+-----------+ +-----------------+-------------------------------------+-----------+
| SYN | Update Peer Verifier; Send SYNACK | SYNRCVD | | SYN | Update Peer Verifier; Send SYNACK | SYNRCVD |
+------------------+-------------------------------------+-----------+ +-----------------+-------------------------------------+-----------+
| ACK | Send RSTACK | SYNSENT | | ACK | Send RSTACK | SYNSENT |
+====================================================================+ +===================================================================+
State: SYNRCVD State: SYNRCVD
+====================================================================+ +===================================================================+
| Condition | Action | New State | | Condition | Action | New State |
+==================+=====================================+===========+ +=================+=====================================+===========+
| SYNACK && C | Verify Adjacency State; Send ACK | ESTAB | | SYNACK && C | Verify Adjacency State; Send ACK | ESTAB |
+------------------+-------------------------------------+-----------+ +-----------------+-------------------------------------+-----------+
| SYNACK && !C | Send RSTACK | SYNRCVD | | SYNACK && !C | Send RSTACK | SYNRCVD |
+------------------+-------------------------------------+-----------+ +-----------------+-------------------------------------+-----------+
| SYN | Record Adjacency State; Send SYNACK | SYNRCVD | | SYN | Record Adjacency State; Send SYNACK | SYNRCVD |
+------------------+-------------------------------------+-----------+ +-----------------+-------------------------------------+-----------+
| ACK && B && C | Send ACK | ESTAB | | ACK && B && C | Send ACK | ESTAB |
+------------------+-------------------------------------+-----------+ +-----------------+-------------------------------------+-----------+
| ACK && !(B && C) | Send RSTACK | SYNRCVD | | ACK && !(B && C)| Send RSTACK | SYNRCVD |
+====================================================================+ +===================================================================+
State: ESTAB State: ESTAB
+====================================================================+ +===================================================================+
| Condition | Action | New State | | Condition | Action | New State |
+==================+=====================================+===========+ +=================+=====================================+===========+
| SYN || SYNACK | Send ACK (note 2) | ESTAB | | SYN || SYNACK | Send ACK (Note 2) | ESTAB |
+------------------+-------------------------------------+-----------+ +-----------------+-------------------------------------+-----------+
| ACK && B && C | Send ACK (note 3) | ESTAB | | ACK && B && C | Send ACK (Note 3) | ESTAB |
+------------------+-------------------------------------+-----------+ +-----------------+-------------------------------------+-----------+
| ACK && !(B && C) | Send RSTACK | ESTAB | | ACK && !(B && C)| Send RSTACK | ESTAB |
+====================================================================+ +===================================================================+
Note 2: No more than two ACKs should be sent within any time period 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 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 time the timer expires. In addition, one further ACK may be sent
between timer expirations if the incoming message is a SYN or SYNACK. between timer expirations if the incoming message is a SYN or SYNACK.
This additional ACK allows the adjacency protocol to reach This additional ACK allows the adjacency protocol to reach
synchronisation more quickly. synchronization more quickly.
Note 3: No more than one ACK should be sent within any time period of Note 3: No more than one ACK should be sent within any time period of
length defined by the timer. length defined by the timer.
3.5.2.3. The Adjacency Protocol SYN Message 3.5.2.3. The Adjacency Protocol SYN Message
3.5.2.3.1. Action By the Sender 3.5.2.3.1. Action by the Sender
The SYN message is sent in accordance with the state tables just The SYN message is sent in accordance with the state tables just
described. The sender sets the individual fields as follows: described. The sender sets the individual fields as follows:
Version: SHOULD be set to the highest version of ANCP that the Version: SHOULD be set to the highest version of ANCP that the
sender supports. sender supports.
Message Type: MUST be set to 10. Message Type: MUST be set to 10.
Timer: SHOULD be set to the value configured in the AN or NAS Timer: SHOULD be set to the value configured in the AN or NAS
sending the message. sending the message.
M Flag MUST be set to 1 by the NAS, and 0 by the AN. M Flag: MUST be set to 1 by the NAS, and 0 by the AN.
Code: MUST be set to 1 (SYN). Code: MUST be set to 1 (SYN).
Sender Name set as described in Section 3.5.1. Sender Name: Set as described in Section 3.5.1.
Receiver Name: SHOULD be set to 0. Receiver Name: SHOULD be set to 0.
Sender Port set as described in Section 3.5.1. Sender Port: Set as described in Section 3.5.1.
Receiver Port: SHOULD be set to 0. Receiver Port: SHOULD be set to 0.
PType: set according to the following rules: PType: Set according to the following rules:
Settings by the AN: Settings by the AN:
0 - the AN does not support partitions; 0 - the AN does not support partitions;
2 - the value of Partition ID contained in this message is 2 - the value of Partition ID contained in this message is
assigned to the current partition. assigned to the current partition.
Settings by the NAS: Settings by the NAS:
skipping to change at page 24, line 47 skipping to change at page 23, line 47
(RECOMMENDED setting); (RECOMMENDED setting);
1 - the NAS requests that the AN use the value of Partition 1 - the NAS requests that the AN use the value of Partition
ID contained in this message for the current partition. The ID contained in this message for the current partition. The
NAS MAY use this setting even if it has already received a NAS MAY use this setting even if it has already received a
SYN message from the AN, provided that the AN has indicated SYN message from the AN, provided that the AN has indicated
support for partitions. The NAS MUST be prepared to use support for partitions. The NAS MUST be prepared to use
whatever value it receives in a subsequent SYN or SYNACK whatever value it receives in a subsequent SYN or SYNACK
message, even if this differs from the requested value. message, even if this differs from the requested value.
PFlag: set to the mode of adjacency setup (new adjacency vs. P Flag: Set to the mode of adjacency setup (new adjacency vs.
recovered adjacency) requested by the sender. Warning: setting recovered adjacency) requested by the sender. Warning: setting P
PFlag=1 runs the risk of state mismatch because ANCP does not Flag=1 runs the risk of state mismatch because ANCP does not
provide the means for the NAS to audit the current state of the provide the means for the NAS to audit the current state of the
AN. AN.
Sender Instance: set as described in Section 3.5.1. Sender Instance: Set as described in Section 3.5.1.
Partition ID: MUST be set to 0 if PType=0, otherwise set to the Partition ID: MUST be set to 0 if PType=0; otherwise, set to the
assigned or requested partition identifier value. assigned or requested partition identifier value.
Receiver Instance: SHOULD be set to 0. Receiver Instance: SHOULD be set to 0.
# of Caps: MUST be set to the number of Capability fields that # of Caps: MUST be set to the number of Capability fields that
follow. follow.
Total Length: MUST be set to the total number of bytes in the Total Length: MUST be set to the total number of bytes in the
Capability fields that follow. Capability fields that follow.
Capability Fields: one Capability field MUST be present for each Capability Fields: One Capability field MUST be present for each
ANCP capability for which the sender wishes to advertise support. ANCP capability for which the sender wishes to advertise support.
3.5.2.3.2. Action By the Receiver 3.5.2.3.2. Action by the Receiver
Upon receiving a validly-formed SYN message, the receiver first Upon receiving a validly formed SYN message, the receiver first
checks the value of the Version field. If this value is not within checks the value of the Version field. If this value is not within
the range of ANCP versions that the receiver supports, the message the range of ANCP versions that the receiver supports, the message
MUST be silently ignored. Similarly, the message is silently ignored 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 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 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 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 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 MUST reflect the adjacency state as previously recorded by the
receiver. receiver.
Otherwise, the receiver MUST record the adjacency state as follows: Otherwise, the receiver MUST perform the "Record Adjacency State"
operation by recording the following fields:
Version: the supported Version value received in the SYN message. Version: The supported Version value received in the SYN message.
This value MUST be used for all subsequent ANCP messages sent This value MUST be used for all subsequent ANCP messages sent
during the life of the adjacency. during the life of the adjacency.
Timer: the larger of the Timer value received in the SYN message and Timer: The larger of the Timer value received in the SYN message and
the value with which the receiver is configured. the value with which the receiver is configured.
Sender Name: the value of the Sender Name field in the SYN message Sender Name: The value of the Sender Name field in the SYN message
just received. just received.
Receiver Name: the value used by the receiver in the Sender Name Receiver Name: The value used by the receiver in the Sender Name
field of SYN, SYNACK, and ACK messages it sends in this adjacency. 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 Sender Port: The value of the Sender Port field in the SYN message
just received. just received.
Receiver Port: the value used by the receiver in the Sender Port Receiver Port: The value used by the receiver in the Sender Port
field of SYN, SYNACK, and ACK messages it sends in this adjacency. field of SYN, SYNACK, and ACK messages it sends in this adjacency.
Sender Instance: the value of the Sender Instance field in the SYN Sender Instance: The value of the Sender Instance field in the SYN
message just received. message just received.
PFlag: the lesser of the value determined by local policy and the P Flag: The lesser of the value determined by local policy and the
value received in the SYN message. That is, preference is given value received in the SYN message. That is, preference is given
to "0 - New adjacency" if there is a conflict. 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 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 AN does not support partitions or to the non-zero value of the
partition identifier it chooses to assign otherwise. If the SYN partition identifier it chooses to assign otherwise. If the SYN
receiver is the NAS, this is set to the value of the Partition ID receiver is the NAS, this is set to the value of the Partition ID
field copied from the SYN. field copied from the SYN.
Receiver Instance: the value used by the receiver in the Sender Receiver Instance: The value used by the receiver in the Sender
Instance field of SYN, SYNACK, and ACK messages it sends in this Instance field of SYN, SYNACK, and ACK messages it sends in this
adjacency. adjacency.
Capabilities: the set of ANCP capabilities that were offered in the Capabilities: The set of ANCP capabilities that were offered in the
SYN and are supported by the receiver. SYN and are supported by the receiver.
3.5.2.4. The Adjacency Protocol SYNACK Message 3.5.2.4. The Adjacency Protocol SYNACK Message
3.5.2.4.1. Action By the Sender 3.5.2.4.1. Action by the Sender
The SYNACK is sent in response to a successfully received SYN The SYNACK is sent in response to a successfully received SYN
message, as indicated by the state tables. The Version, Timer, message, as indicated by the state tables. The Version, Timer, P
PFlag, and Partition ID fields MUST be populated with the values Flag, and Partition ID fields MUST be populated with the values
recorded as part of adjacency state. The # of Caps, Total Length, recorded as part of adjacency state. The # of Caps, Total Length,
and Capability fields MUST also be populated in accordance with the and Capability fields MUST also be populated in accordance with the
Capabilities recorded as part of adjacency state. The remaining Capabilities recorded as part of adjacency state. The remaining
fields of the SYNACK message MUST be populated as follows: fields of the SYNACK message MUST be populated as follows:
Message Type: MUST be 10. Message Type: MUST be 10.
M-flag: MUST be set to 0. M flag: MUST be set to 0.
Code: MUST be 2 (SYNACK). Code: MUST be 2 (SYNACK).
PType: MUST be 0 if the Partition ID value is 0, or 2 if the PType: MUST be 0 if the Partition ID value is 0 or 2 if the
Partition ID value is non-zero. Partition ID value is non-zero.
Sender Name: MUST be set to the Receiver Name value recorded as part Sender Name: MUST be set to the Receiver Name value recorded as part
of adjacency state. of adjacency state.
Receiver Name: MUST be set to the Sender Name value recorded as part Receiver Name: MUST be set to the Sender Name value recorded as part
of adjacency state. of adjacency state.
Sender Port: MUST be set to the Receiver Port value recorded as part Sender Port: MUST be set to the Receiver Port value recorded as part
of adjacency state. of adjacency state.
skipping to change at page 27, line 24 skipping to change at page 26, line 27
Sender Instance: MUST be set to the Receiver Instance value recorded Sender Instance: MUST be set to the Receiver Instance value recorded
as part of adjacency state. as part of adjacency state.
Receiver Instance: MUST be set to the Sender Instance value recorded Receiver Instance: MUST be set to the Sender Instance value recorded
as part of adjacency state. as part of adjacency state.
If the set of capabilities recorded in the adjacency state is empty, If the set of capabilities recorded in the adjacency state is empty,
then after sending the SYNACK the sender MUST raise an alarm to then after sending the SYNACK the sender MUST raise an alarm to
management, halt the adjacency procedure, and tear down the TCP management, halt the adjacency procedure, and tear down the TCP
session if it is not being used by another adjacency. The sender MAY session if it is not being used by another adjacency. The sender MAY
also terminate the IPSec security association if no other adjacency also terminate the IPsec security association if no other adjacency
is using it. is using it.
3.5.2.4.2. Action By the Receiver 3.5.2.4.2. Action by the Receiver
As indicated by the state tables, the receiver of a SYNACK first As indicated by the state tables, the receiver of a SYNACK first
checks that the Receiver Name, Receiver Port, and Receiver Instance checks that the Receiver Name, Receiver Port, and Receiver Instance
values match the Sender Name, Sender Port, and Sender Instance values values match the Sender Name, Sender Port, and Sender Instance values
it sent in SYN message that is being acknowledged. The AN also 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 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. 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 receiver next checks whether the set of capabilities provided in
the SYNACK is empty. If so, the receiver MUST raise an alarm to the SYNACK is empty. If so, the receiver MUST raise an alarm to
management and halt the adjacency procedure. management and halt the adjacency procedure.
Assuming that the SYNACK passes these checks, two cases arise. The Assuming that the SYNACK passes these checks, two cases arise. The
first possibility is that the receiver has already recorded adjacency first possibility is that the receiver has already recorded adjacency
state. This will occur if the SYNACK is received while the receiver state. This will occur if the SYNACK is received while the receiver
is in SYNRCVD state. In this case, the Version, Timer, Sender Name, is in SYNRCVD state. In this case, the Version, Timer, Sender Name,
Sender Port, Sender Instance, PFlag, and capability-related fields in Sender Port, Sender Instance, P Flag, and capability-related fields
the SYNACK MUST match those recorded as part of adjacency state. If in the SYNACK MUST match those recorded as part of adjacency state.
a mismatch is detected, the receiver sends an RSTACK. This is the If a mismatch is detected, the receiver sends an RSTACK. This is the
"Verify Adjacency State" procedure shown in the SYNRCVD state table. "Verify Adjacency State" procedure shown in the SYNRCVD state table.
If, on the other hand, the SYNACK is received while the receiver is 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 SYNSENT state, the receiver MUST record session state as described
in Section 3.5.2.3.2. in Section 3.5.2.3.2.
In either case, if the receiver is the NAS, it MUST accept the In either case, if the receiver is the NAS, it MUST accept the
Partition ID value provided in the SYNACK, updating its recorded Partition ID value provided in the SYNACK, updating its recorded
adjacency state if necessary. adjacency state if necessary.
3.5.2.5. The Adjacency Protocol ACK Message 3.5.2.5. The Adjacency Protocol ACK Message
3.5.2.5.1. Actions By the Sender 3.5.2.5.1. Actions by the Sender
As indicated by the state tables, the ACK message is sent in a number 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 of different circumstances. The main-line usages are as a response
to SYNACK, leading directly to the ESTAB state, and as a periodic to SYNACK, leading directly to the ESTAB state, and as a periodic
test of liveness once the ESTAB state has been reached. test of liveness once the ESTAB state has been reached.
The sender MUST populate the ACK from recorded adjacency state, The sender MUST populate the ACK from recorded adjacency state,
exactly as described in Section 3.5.2.4.1. The only difference is exactly as described in Section 3.5.2.4.1. The only difference is
that Code MUST be set to 3 (ACK). that Code MUST be set to 3 (ACK).
3.5.2.5.2. Actions By the Receiver 3.5.2.5.2. Actions by the Receiver
The required actions by the receiver are specified by the state The required actions by the receiver are specified by the state
tables. In addition to the checks B and C, the receiver SHOULD tables. In addition to the checks B and C, the receiver SHOULD
verify that the remaining contents of the ACK match the recorded verify that the remaining contents of the ACK match the recorded
adjacency state at the receiver. If that check fails the receiver adjacency state at the receiver. If that check fails, the receiver
MUST send an RSTACK as described in Section 3.5.2.6.1. MUST send an RSTACK as described in Section 3.5.2.6.1.
Once the adjacency has been established, either peer can initiate the Once the adjacency has been established, either peer can initiate the
ACK exchange that tests for liveness. To meet the restrictions on ACK exchange that tests for liveness. To meet the restrictions on
ACK frequency laid down in the notes to the state tables, it is ACK frequency laid down in the notes to the state tables, it is
desirable that only one such exchange occur during any one interval. 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 Hence, if a peer receives an ACK when in ESTAB state, it MUST reply
that ACK as directed by the state tables, but SHOULD NOT initiate to that ACK as directed by the state tables, but SHOULD NOT initiate
another ACK exchange in the same interval. To meet this objective, another ACK exchange in the same interval. To meet this objective,
the receiver MUST reset its timer when it receives an ACK while in the receiver MUST reset its timer when it receives an ACK while in
ESTAB state. ESTAB state.
It is, of course, possible that two exchanges happen because of It is, of course, possible that two exchanges happen because of
race conditions. race conditions.
3.5.2.6. The Adjacency Protocol RSTACK Message 3.5.2.6. The Adjacency Protocol RSTACK Message
3.5.2.6.1. Action By the Sender 3.5.2.6.1. Action by the Sender
The RSTACK is sent in response to various error conditions as The RSTACK is sent in response to various error conditions as
indicated by the state tables. In general it leads to a restart of indicated by the state tables. In general, it leads to a restart of
adjacency negotiations (although this takes a few steps when the adjacency negotiations (although this takes a few steps when the
original sender of the RSTACK is in ESTAB state). original sender of the RSTACK is in ESTAB state).
As indicated in Section 3.5.1, the Sender Name, Port, and Instance 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, 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. and Instance fields in the message that caused the RSTACK to be sent.
Similarly, the Receiver identifier fields in the RSTACK MUST be Similarly, the Receiver identifier fields in the RSTACK MUST be
copied from the corresponding Sender identifier fields in the message copied from the corresponding Sender identifier fields in the message
that triggered the RSTACK. that triggered the RSTACK.
If the sender has recorded adjacency state, the Version, Timer, If the sender has recorded adjacency state, the Version, Timer,
PType, PFlag, Partition ID, and capability-related fields SHOULD be PType, P Flag, Partition ID, and capability-related fields SHOULD be
set based on the recorded adjacency state. Otherwise they 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 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). MUST be 10, the M flag MUST be 0, and Code MUST be 4 (RSTACK).
3.5.2.6.2. Action By the Receiver 3.5.2.6.2. Action by the Receiver
The receiver of an RSTACK MAY attempt to diagnose the problem which The receiver of an RSTACK MAY attempt to diagnose the problem that
caused the RSTACK to be generated by comparing its own adjacency caused the RSTACK to be generated by comparing its own adjacency
state with the contents of the RSTACK. However, the primary purpose 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. of the RSTACK is to trigger action as prescribed by Section 3.5.2.2.
3.5.2.7. Loss of Synchronization 3.5.2.7. Loss of Synchronization
Loss of synchronisation MAY be declared if after synchronisation is Loss of synchronization MAY be declared if after synchronization is
achieved: achieved:
o no valid ANCP messages are received in any period of time in o no valid ANCP messages are received in any period of time in
excess of three times the value of the Timer field negotiated in excess of three times the value of the Timer field negotiated in
the adjacency protocol messages, or the adjacency protocol messages, or
o a mismatch in adjacency state is detected. o a mismatch in adjacency state is detected.
In either case the peer detecting the condition MUST send an RSTACK In either case, the peer detecting the condition MUST send an RSTACK
to the other peer as directed in Section 3.5.2.6.1, in order to to the other peer, as directed in Section 3.5.2.6.1, in order to
initiate resynchronization. initiate resynchronization.
While re-establishing synchronisation with a controller, a switch While re-establishing synchronization with a controller, a switch
SHOULD maintain its connection state, deferring the decision about SHOULD maintain its connection state, deferring the decision about
resetting the state until after synchronisation is re-established. resetting the state until after synchronization is re-established.
Once synchronisation is re-established the decision about resetting
Once synchronization is re-established, the decision about resetting
the connection state SHOULD be made based on the negotiated value of the connection state SHOULD be made based on the negotiated value of
PFlag. the P Flag.
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. See Figure 7 the adjacency messages. See Figure 7.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result| Result Code | | Version | Message Type | Result| Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier | | Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length | |I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 30, line 27 skipping to change at page 29, line 37
Figure 7: ANCP General Message Format Figure 7: ANCP General Message Format
3.6.1. The ANCP Message Header 3.6.1. The ANCP Message Header
A complete explanation of the ANCP general message header fields A complete explanation of the ANCP general message header fields
follows. follows.
3.6.1.1. Version Field (8 bits) 3.6.1.1. Version Field (8 bits)
This field carries the version of the ANCP protocol that was agreed This field carries the version of ANCP that was agreed upon for the
for the session during adjacency negotiation. session during adjacency negotiation.
3.6.1.2. Message Type Field (8 bits) 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 an IANA registry. registered in an IANA registry.
3.6.1.3. Result Field (4 bits) 3.6.1.3. Result Field (4 bits)
In request messages, the Result field indicates the circumstances In request messages, the Result field indicates the circumstances
under which a response is required. ANCP specifies what Result value under which a response is required. ANCP specifies what Result value
each request message type should have. In responses the Result field each request message type should have. In responses, the Result
indicates either Success (0x3) or Failure (0x4) as the case may be. field indicates 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 Result Code and that the request was executed successfully. The Result Code
field for a successful result is typically 0, but MAY take on field for a successful result is typically 0, but it MAY take on
other 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
Result Code value and any diagnostic data contained in a Status- Result Code value and any diagnostic data contained in a Status-
Info TLV included in the response. Info TLV included in the response.
3.6.1.4. Result Code Field (12 bits) 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 it can also be used to give further information
a success response message or an event message. In a request in a success response message or an event message. In a request
message, the Result Code field is not used and MUST be set to 0x0 (No message, the Result Code field is not used and MUST be set to 0x0 (No
result). result).
A number of Result Code values are specified below. Specification of A number of Result Code values are specified below. Specification of
additional Result Code values in extensions or updates to this additional Result Code values in extensions or updates to this
document MUST include the following information: document MUST include the following information:
o Result 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, a In addition to any suggested action in the text that follows, a count
count of the number of times a given non-zero Result Code value was of the number of times a given non-zero Result Code value was
received SHOULD be provided for management. Where an action includes received SHOULD be provided for management. Where an action includes
resending of a request, a given request SHOULD NOT be re-sent more the re-sending of a request, a given request SHOULD NOT be re-sent
than once. more than once.
This document specifies the following Result Code values. This document specifies the following Result Code values.
Result Code value: 0x2 Result Code value: 0x2
* 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 that 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.
* 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 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.
Result Code value: 0x6 Result Code value: 0x6
* 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 Result Code value indicates * Further description (if any): This Result Code value indicates
a state mismatch between the NAS and AN control applications, a state mismatch between the NAS and AN control applications,
possibly 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.
Result Code value: 0x13 Result Code value: 0x13
* 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 * Further description (e.g., memory exhausted): This Result Code
Result Code value MUST be reported only by the AN, and value MUST be reported only by the AN, and indicates a
indicates a condition that is probably unrelated to specific condition that is probably unrelated to specific access lines
access lines (although it may be related to the specific (although it may be related to the specific request).
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 Result Code value from multiple requests for the receives this Result Code value from multiple requests for the
same AN in a short interval, it SHOULD reduce the rate at which same AN in a short interval, it SHOULD reduce the rate at which
it sends requests in proportion to the rate at which requests it sends requests in proportion to the rate at which requests
are failing with Result Code = 19. It MAY retry individual are failing with Result Code = 19. It MAY retry individual
requests. If only a specific request is failing with Result requests. If only a specific request is failing with Result
skipping to change at page 33, line 41 skipping to change at page 33, line 4
requests. If only a specific request is failing with Result requests. If only a specific request is failing with Result
Code = 19, the ANCP agent in the NAS MAY request the control Code = 19, the ANCP agent in the NAS MAY request the control
application to decompose the request into simpler components if application to decompose the request into simpler components if
this is possible. this is possible.
Result Code value: 0x51 Result Code value: 0x51
* 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 Result Code value expects that support of the receiver of this Result Code value expects that support of the
message type concerned is mandatory according to the message type concerned is mandatory according to the
capabilities negotiated for the session, it MAY re-send the capabilities negotiated for the session, it MAY re-send the
message in case the message was corrupted in transit the first message in case the message was corrupted in transit the first
time. If that fails, and use of the message type cannot be time. If that fails, and use of the message type cannot be
avoided, the ANCP agent MAY reset the adjacency by sending an avoided, the ANCP agent MAY reset the adjacency by sending an
RSTACK adjacency message (Section 3.5.2.6.1) where PType is set RSTACK adjacency message as described in Section 3.5.2.6.1,
to 0 and Sender and Receiver Name, Port, and Instance are taken where Sender and Receiver Name, Port, and Instance are taken
from recorded adjacency state. If a reset does not eliminate from recorded adjacency state. If a reset does not eliminate
the problem, the receiving ANCP agent SHOULD raise an alarm to the problem, the receiving ANCP agent SHOULD raise an alarm to
management and then cease to operate. management and then cease to operate.
Result Code value: 0x53 Result Code value: 0x53
* 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.
Result Code value: 0x54 Result Code value: 0x54
skipping to change at page 34, line 43 skipping to change at page 34, line 4
* 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.
Result Code value: 0x54 Result Code value: 0x54
* 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
the length is set to zero and the value field is empty (i.e., the length is set to zero and the value field is empty (i.e.,
only the four-byte TLV header is present). only the 4-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: Re-send 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).
Result Code value: 0x55 Result Code value: 0x55
* 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 re-send 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).
Result Code value: 0x500 Result Code value: 0x500
* 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 Authentication,
mismatch between the AN and the NAS or AAA. Authorization, and Accounting (AAA).
* 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 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.
3.6.1.5. Partition ID (8 bits) 3.6.1.5. Partition ID (8 bits)
The Partition ID field MUST contain the value that was negotiated for The Partition ID field MUST contain the value that was negotiated for
Partition ID during the adjacency procedure as described above. Partition ID during the adjacency procedure as described above.
3.6.1.6. Transaction ID (24 bits) 3.6.1.6. Transaction ID (24 bits)
The Transaction ID is set by the sender of a request message to The Transaction ID is set by the sender of a request message to
associate a response message with the original request message. associate a response message with the original request message.
Unless otherwise specified for a given message type, the Transaction Unless otherwise specified for a given message type, the Transaction
ID in request messages MUST be set to a value in the range (1, 2^24 - ID in request messages MUST be set to a value in the range
1). When used in this manner, the Transaction ID sequencing MUST be (1, 2^24 - 1). When used in this manner, the Transaction ID
maintained independently for each message type within each ANCP sequencing MUST be maintained independently for each message type
adjacency. Furthermore, it SHOULD be incremented by 1 for each new within each ANCP adjacency. Furthermore, it SHOULD be incremented by
message of the given type, cycling back to 1 after running the full 1 for each new message of the given type, cycling back to 1 after
range. For event messages, the Transaction ID SHOULD be set to zero. running the full range. For event messages, the Transaction ID
SHOULD be set to zero.
Unless otherwise specified, the default behaviour for all ANCP Unless otherwise specified, the default behavior 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 (1 + 15 bits) 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 MUST 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 (16 bits) 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 4-byte
byte encapsulating header defined in Section 3.2. 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 8: The general format of a TLV is shown in Figure 8:
skipping to change at page 37, line 32 skipping to change at page 36, line 48
Length (16 bits): The number of bytes of data in the Value field of Length (16 bits): The number of bytes of data in the Value field of
the TLV, excluding any padding required to bring this TLV to a the TLV, excluding any padding required to bring this TLV to a
4-byte word boundary (see "Value" below). If a TLV contains other 4-byte word boundary (see "Value" below). If a TLV contains other
TLVs, any padding in the contained TLVs MUST be included in the TLVs, any padding in the contained TLVs MUST be included in the
value of Length. Depending on the specification of the TLV, the value of Length. Depending on the specification of the TLV, the
value of Length can be zero, a constant for all instances of the value of Length can be zero, a constant for all instances of the
TLV, or a varying quantity. TLV, or a varying quantity.
Value (variable): The actual data carried by the TLV, if any. The Value (variable): The actual data carried by the TLV, if any. The
value field in each TLV MUST be padded with zeroes as required to Value field in each TLV MUST be padded with zeroes as required to
align with a 4-byte word boundary. The Value field of a TLV MAY align with a 4-byte word boundary. The Value field of a TLV MAY
include fixed 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
skipping to change at page 38, line 24 skipping to change at page 37, line 42
request message will typically indicate that the Result field is set request message will typically indicate that the Result field is set
to Ignore (0x0) and provide procedures indicating explicitly when the to Ignore (0x0) and provide procedures indicating explicitly when the
receiver should generate a response and what message type it should receiver should generate a response and what message type it should
use. use.
The Transaction ID field is used to distinguish between multiple The Transaction ID field is used to distinguish between multiple
request messages of the same type and to associate a response message request messages of the same type and to associate a response message
to a request. Specifications of ANCP messages for applications not to a request. Specifications of ANCP messages for applications not
requiring response correlation SHOULD indicate that the Transaction requiring response correlation SHOULD indicate that the Transaction
ID MUST be set to zero in requests. Applications that require ID MUST be set to zero in requests. Applications that require
response correlation SHOULD refer to the Transaction ID behaviour response correlation SHOULD refer to the Transaction ID behavior
described in Section 3.6.1. described in Section 3.6.1.
The specification for a response message SHOULD indicate in all cases The specification for a response message SHOULD indicate in all cases
that value of the Transaction Identifier MUST be set to that of the that the value of the Transaction Identifier MUST be set to that of
corresponding request message. This allows the requester to the corresponding request message. This allows the requester to
establish whether or not correlation is needed (by setting a non-zero establish whether or not correlation is needed (by setting a non-zero
or zero value for the Transaction ID). or zero value for the Transaction ID).
4. Generally Useful ANCP Messages and TLVs 4. Generally Useful ANCP Messages and TLVs
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
specified, with the intention that particular capabilities spell out under-specified, with the intention that particular capabilities
the remaining details. spell out 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 9. 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.
skipping to change at page 39, line 27 skipping to change at page 38, line 43
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: 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 coexist 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).
Result 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.
skipping to change at page 40, line 24 skipping to change at page 39, line 42
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 10 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) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 42, line 17 skipping to change at page 41, line 43
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 11: 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. That is, the specification of
message type that can carry the Command TLV is expected to define each message type that can carry the Command TLV is expected to
the meaning of the content of the payload, although re-use of define the meaning of the content of the payload, although re-use
specifications is, of course, permissible when appropriate. of specifications is, of course, permissible when appropriate.
Support of any specific variant of the Command TLV is OPTIONAL Support of any specific variant of the Command TLV is OPTIONAL
unless the ANCP agent claims support for a capability that unless the ANCP agent claims support for a capability that
requires its use. requires its use.
Length: Variable, depending on the specific contents. Length: Variable, depending on the specific contents.
Value: Command information as defined for each message type. The Value: Command information as defined for each message type. The
field MAY include sub-TLVs. The contents of this TLV MUST be field MAY include sub-TLVs. The contents of this TLV MUST be
specified as one "command" or alternatively a sequence of one or specified as one "command" or alternatively a sequence of one or
more "commands", each beginning with a one-byte Command Code and more "commands", each beginning with a 1-byte Command Code and
possibly including other data following the Command Code. An IANA possibly including other data following the Command Code. An IANA
registry has been established for Command Code values. This registry has been established for Command Code values. This
document reserves the Command Code value 0 as an initial entry in document reserves the Command Code value 0 as an initial entry in
the registry. the registry.
4.5. Status-Info TLV 4.5. Status-Info TLV
Name: Status-Info Name: Status-Info
Type: 0x0106 Type: 0x0106
skipping to change at page 43, line 20 skipping to change at page 42, line 44
Generic Response message will usually include an instance of the Generic Response message will usually include an instance of the
Status-Info TLV. Support of the Status-Info TLV, both as sender Status-Info TLV. Support of the Status-Info TLV, both as sender
and as receiver, is REQUIRED for all ANCP agents, regardless of and as receiver, is REQUIRED for all ANCP agents, regardless of
what 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 (8 bits): see Section 3.4 for handling of reserved Reserved (8 bits): See Section 3.4 for handling of reserved
fields. fields.
Msg Type (8 bits): Message Type of the request for which this TLV Msg Type (8 bits): Message Type of the request for which this TLV
is providing diagnostics. is providing diagnostics.
Result Message Length (16 bits): Number of bytes in the error Error Message Length (16 bits): Number of bytes in the error
message, excluding padding, but including the language tag and message, excluding padding, but including the language tag and
delimiter. This MAY be zero if no error message is provided. delimiter. This MAY be zero if no error message is provided.
Result Message: Human-readable string providing information about Error Message: Human-readable string providing information about
the warning or error condition. The initial characters of the the warning or error condition. The initial characters of the
string MUST be a language tag as described in [RFC5646], string MUST be a language tag as described in [RFC5646],
terminated by a colon (":"). The actual text string follows terminated by a colon (":"). The actual text string follows
the delimiter. The field is padded at the end with zeroes as the delimiter. The field is padded at the end with zeroes as
necessary to extend it to a four-byte word boundary. necessary to extend it to a 4-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
Result Code field. Result Code field.
Figure 12 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 12: 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
(DSLs)
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
capabilities for use specifically in controlling Access Nodes serving capabilities for use specifically in controlling Access Nodes serving
DSL access (Tech Type = 0x05). The same ANs could be serving other DSL access (Tech Type = 0x05). The same ANs could be serving other
access technologies (e.g. Metro-Ethernet, Passive Optical access technologies (e.g., Metro-Ethernet, Passive Optical
Networking, WiMax), in which case the AN will also have to support Networking, WiMax), in which case the AN will also have to support
the corresponding other-technology-specific capabilities. Those the corresponding other-technology-specific capabilities. Those
additional capabilities are outside the scope of the present additional capabilities are outside the scope of the present
document. document.
5.1. DSL Access Line Identification 5.1. DSL Access Line Identification
Most ANCP messages involve actions relating to a specific access Most ANCP messages involve actions relating to a specific access
line. Thus it is necessary to describe how access lines are line. Thus, it is necessary to describe how access lines are
identified within those messages. This section defines four TLVs for identified within those messages. This section defines four TLVs for
that purpose and provides an informative description of how they are that purpose and provides an informative description of how they are
used. used.
5.1.1. Control Context (Informative) 5.1.1. Control Context (Informative)
Three types of identification are described in [TR-101] and provided Three types of identification are described in [TR-101] and provided
for in the TLVs defined in this section: for in the TLVs defined in this section:
o identification of an access line by its logical appearance on the o identification of an access line by its logical appearance on the
skipping to change at page 45, line 34 skipping to change at page 44, line 50
used in this signalling should be the same as the identification used used in this signalling should be the same as the identification used
in ANCP messages. 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 access line uniquely.
Identification by the logical appearance on the NAS side of the Identification by the logical appearance on the NAS side of the
Access Node is unique only if there is a one-to-one mapping between Access Node is unique only if there is a one-to-one mapping between
the appearances on the two sides and no identity-modifying the appearances on the two sides and no identity-modifying
aggregation between the AN and the NAS. In other cases, and in aggregation between the AN and the NAS. In other cases, and in
particular in the case of Ethernet aggregation using the N:1 VLAN particular in the case of Ethernet aggregation using the N:1 VLAN
model, the user-side access line identification is necessary, but the model, the user-side access line identification is necessary, but the
NAS-side identification is potentially useful information allowing NAS-side identification is potentially useful information allowing
the NAS to build up a picture of the aggregation network topology. the NAS to build up a picture of the aggregation network topology.
Additional identification down to the user or host level is intended Additional identification down to the user or host level is intended
to supplement rather than replace either of the other two forms of to supplement rather than replace either of the other two forms of
identification. identification.
Sections 3.8 and 3.9 of [TR-101] are contradictory on this point. Sections 3.8 and 3.9 of [TR-101] are contradictory on this point.
It is assumed here that Section 3.9 is meant to be authoritative. It is assumed here that Section 3.9 is meant to be authoritative.
The user-level identification takes the form of an administered The user-level identification takes the form of an administered
string which again is opaque at the ANCP level. string that again is opaque at the ANCP level.
The NAS control application will use the identifying information it The NAS control application will use the identifying information it
receives from the AN directly for some purposes. For examples, see receives from the AN directly for some purposes. For examples, see
the introductory part of Section 3.9 of [TR-101]. For other the introductory part of Section 3.9 of [TR-101]. For other
purposes, the NAS will build a mapping between the unique access line purposes, the NAS will build a mapping between the unique access line
identification provided by the AN, the additional identification of identification provided by the AN, the additional identification of
the user or host (where provided), and the IP interface on a the user or host (where provided), and the IP interface on a
particular host. For access lines with static IP address assignment particular host. For access lines with static IP address assignment,
that mapping could be configured instead. that mapping could be configured instead.
5.1.2. TLVs For DSL Access Line Identification 5.1.2. TLVs for DSL Access Line Identification
This section provides a normative specification of the TLVs that ANCP This section provides a normative specification of the TLVs that ANCP
provides to carry the types of identification just described. The provides to carry the types of identification just described. The
Access-Loop-Circuit-ID TLV identifies an access line by its logical Access-Loop-Circuit-ID TLV identifies an access line by its logical
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].
ANCP agents conforming to this section MUST satisfy the following ANCP agents conforming to this section MUST satisfy the following
requirements: 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.
o If the Access-Loop-Remote-Id TLV is present in a message, it MUST o If the Access-Loop-Remote-ID TLV is present in a message, it MUST
be accompanied by an Access-Loop-Circuit-ID TLV and/or an Access- be accompanied by an Access-Loop-Circuit-ID TLV and/or an Access-
Aggregation-Circuit-ID-xxx TLV with two VLAN identifiers. Aggregation-Circuit-ID-ASCII TLV or Access-Aggregation-Circuit-ID-
Binary TLV with two VLAN identifiers.
The Access-Loop-Remote-Id TLV is not enough to identify an The Access-Loop-Remote-ID TLV is not enough to identify an
access line uniquely on its own. As indicated above, an access line uniquely on its own. As indicated above, an
Access-Aggregation-Circuit-ID-xxx TLV with two VLAN identifiers Access-Aggregation-Circuit-ID-ASCII TLV or Access-Aggregation-
may or may not identify an access line uniquely, but this is up Circuit-ID-Binary TLV with two VLAN identifiers may or may not
to the control application to decide. identify an access line uniquely, but this is up to the control
application to decide.
o If the Access-Aggregation-Circuit-ID-xxx TLV is present in a o If the Access-Aggregation-Circuit-ID-ASCII TLV or Access-
message with just one VLAN identifier, it MUST be accompanied by Aggregation-Circuit-ID-Binary TLV is present in a message with
an Access-Loop-Circuit-ID TLV. just one VLAN identifier, it MUST be accompanied by an Access-
Loop-Circuit-ID TLV.
5.1.2.1. Access-Loop-Circuit-ID TLV 5.1.2.1. Access-Loop-Circuit-ID TLV
Type: 0x0001 Type: 0x0001
Description: a locally administered human-readable string generated Description: A locally administered human-readable string generated
by or configured on the Access Node, identifying the corresponding by or configured on the Access Node, identifying the corresponding
access loop logical port on the user side of the Access Node. access loop logical port on the user side of the Access Node.
Length: up to 63 bytes Length: Up to 63 bytes
Value: ASCII string Value: ASCII string
5.1.2.2. Access-Loop-Remote-Id TLV 5.1.2.2. Access-Loop-Remote-ID TLV
Type: 0x0002 Type: 0x0002
Description: an operator-configured string that uniquely identifies Description: An operator-configured string that uniquely identifies
the user on the associated access line, as described in Sections the user on the associated access line, as described in Sections
3.9.1 and 3.9.2 of [TR-101]. 3.9.1 and 3.9.2 of [TR-101].
Length: up to 63 bytes Length: Up to 63 bytes
Value: ASCII string Value: ASCII string
5.1.2.3. Access-Aggregation-Circuit-ID-Binary TLV 5.1.2.3. Access-Aggregation-Circuit-ID-Binary TLV
Type: 0x0006 Type: 0x0006
Description: This TLV identifies or partially identifies a specific Description: This TLV identifies or partially identifies a specific
access line by means of its logical circuit identifier on the NAS access line by means of its logical circuit identifier on the NAS
side of the Access Node. side of the Access Node.
For Ethernet access aggregation, where a per-subscriber (stacked) For Ethernet access aggregation, where a per-subscriber (stacked)
VLAN can be applied (1:1 model as defined in [TR-101]), the TLV VLAN can be applied (1:1 model as defined in [TR-101]), the TLV
contains two value fields. Each field carries a 12-bit VLAN contains two value fields. Each field carries a 12-bit VLAN
identifier (which is part of the VLAN tag defined by IEEE 802.1Q). identifier (which is part of the VLAN tag defined by
The first field MUST carry the inner VLAN identifier, while the [IEEE802.1Q]). The first field MUST carry the inner VLAN
second field MUST carry the outer VLAN identifier. identifier, while the second field MUST carry the outer VLAN
identifier.
When the N:1 VLAN model is used, only one VLAN tag is available. When the N:1 VLAN model is used, only one VLAN tag is available.
For the N:1 model, the Access-Aggregation-Circuit-ID-Binary TLV For the N:1 model, the Access-Aggregation-Circuit-ID-Binary TLV
contains a single value field, which MUST carry the 12-bit VLAN contains a single value field, which MUST carry the 12-bit VLAN
identifier derived from the single available VLAN tag. identifier derived from the single available VLAN tag.
In the case of an ATM aggregation network, where the DSLAM is In the case of an ATM aggregation network, where the DSLAM is
directly connected to the NAS (without an intermediate ATM directly connected to the NAS (without an intermediate ATM
switch), the VPI and VCI on the DSLAM uplink correspond uniquely switch), the Virtual Path Identifier (VPI) and Virtual Circuit
to the DSL line on the DSLAM. The Access-Aggregation-Circuit-ID- Identifier (VCI) on the DSLAM uplink correspond uniquely to the
DSL access line on the DSLAM. The Access-Aggregation-Circuit-ID-
Binary TLV MAY be used to carry the VPI and VCI. The first value Binary TLV MAY be used to carry the VPI and VCI. The first value
field of the TLV MUST carry the VCI, while the second value field 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 identifier MUST be the same as
the identifier is transmitted on the wire to identify an Ethernet when the identifier is transmitted on the wire to identify an
frame or ATM cell. Ethernet frame or ATM cell.
The Access-Aggregation-Circuit-ID-Binary is illustrated in The Access-Aggregation-Circuit-ID-Binary is illustrated in
Figure 13. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 49, line 8 skipping to change at page 48, line 35
"circuit-id". "circuit-id".
As an extension to the present document, the Access Node could As an extension to the present document, the Access Node could
convey to the NAS the characteristics (e.g., bandwidth) of the convey to the NAS the characteristics (e.g., bandwidth) of the
uplink on the Access Node. This TLV or the binary equivalent uplink on the Access Node. This TLV or the binary equivalent
defined above then serves the purpose of uniquely identifying the defined above then serves the purpose of uniquely identifying the
uplink whose characteristics are being defined. The present uplink whose characteristics are being defined. The present
document does not specify the TLVs needed to convey the uplink document does not specify the TLVs needed to convey the uplink
characteristics. characteristics.
Length: up to 63 bytes Length: Up to 63 bytes
Value: ASCII string Value: ASCII string
6. ANCP Based DSL Topology Discovery 6. ANCP-Based DSL Topology Discovery
Section 3.1 of [RFC5851] describes the requirements for the DSL Section 3.1 of [RFC5851] describes the requirements for the DSL
Topology Discovery capability. Topology Discovery capability.
6.1. Control Context (Informative) 6.1. Control Context (Informative)
The AN control application in the DSLAM requests ANCP to send a DSL- The AN control application in the DSLAM requests ANCP to send a DSL-
specific Port Up message to the NAS under the following specific Port Up message to the NAS under the following
circumstances: circumstances:
o when a new adjacency with the NAS is established, for each DSL o when a new adjacency with the NAS is established, for each DSL
loop that is synchronized at that time; loop that is synchronized at that time;
o subsequent to that, whenever a DSL loop resynchronizes; and o subsequent to that, whenever a DSL access line resynchronizes; and
o whenever the AN control application wishes to signal that a line o whenever the AN control application wishes to signal that a line
attribute has changed. attribute has changed.
The AN control application in the DSLAM requests ANCP to send a DSL- The AN control application in the DSLAM requests ANCP to send a DSL-
specific Port Down message to the NAS under the following specific Port Down message to the NAS under the following
circumstances: circumstances:
o when a new adjacency with the NAS is established, for each DSL o when a new adjacency with the NAS is established, for each DSL
loop that is provisioned but not synchronized at that time; loop that is provisioned but not synchronized at that time;
o whenever a DSL loop that is equipped in an AN but administratively o whenever a DSL access line that is equipped in an AN but
disabled is signalled as "IDLE"; and administratively disabled is signaled as "IDLE"; and
o subsequent to that, whenever a DSL loop loses synchronization. o subsequent to that, whenever a DSL access line loses
synchronization.
The AN control application passes information to identify the DSL The AN control application passes information to identify the DSL
loop to ANCP to include in the Port Up or Port Down message, along loop to ANCP to include in the Port Up or Port Down message, along
with information relating to DSL loop attributes. with information relating to DSL access line attributes.
In the case of bonded copper loops to the customer premise (as per In the case of bonded copper loops to the customer premise (as per
DSL multi-pair bonding described by [G.988.1] and [G.988.2]), the AN DSL multi-pair bonding described by [G.998.1] and [G.998.2]), the AN
control application requests that ANCP send DSL-specific Port Up and control application requests that ANCP send DSL-specific Port Up and
Port Down messages for the aggregate "DSL bonded circuit" Port Down messages for the aggregate "DSL bonded circuit"
(represented as a single logical port) as well as the individual DSL (represented as a single logical port) as well as the individual DSL
loops of which it is comprised. The information relating to DSL line access lines of which it is comprised. The information relating to
attributes that is passed by the AN control application is aggregate DSL access line attributes that is passed by the AN control
information. application is aggregate information.
ANCP generates the DSL-specific Port Up or Port Down message and ANCP generates the DSL-specific Port Up or Port Down message and
transfers it to the NAS. ANCP on the NAS side passes an indication 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 access line
performs any required accounting operations, and uses any included state, performs any required accounting operations, and uses any
line attributes to adjust the operation of its queueing/scheduling included line attributes to adjust the operation of its queuing/
mechanisms as they apply to data passing to and from that DSL loop. scheduling mechanisms as they apply to data passing to and from that
DSL access line.
Figure 14 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)
skipping to change at page 50, line 43 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 14: 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 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.
6.3. ANCP Port UP and Port DOWN Event Message Descriptions 6.3. ANCP Port Up and Port Down Event Message Descriptions
The format of the ANCP Port UP and Port DOWN Event messages is shown The format of the ANCP Port Up and Port Down Event messages is shown
in Figure 15. in Figure 15.
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 34 skipping to change at page 51, line 46
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 15: 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 Result Code field MUST be set to 0. The 4 bit Port Down. The 4-bit Result field MUST be set to zero (signifying
Result field MUST be set to 0 (signifying Ignore). The 24-bit Ignore). The 12-bit Result Code field and the 24-bit Transaction
Transaction Identifier field MUST be set to 0. Other fields in the Identifier field MUST also be set to zeroes. Other fields in the
general header MUST be set as described in Section 3.6. general header MUST be set a as described in Section 3.6.
The five word Unused field is a historical leftover. The handling of The five-word Unused field is a historical leftover. 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 belong to the "extension block", and are The remaining message fields belong to the "extension block", and are
described as follows: described as follows:
Extension Flags: The flag bits denoted by 'x' are currently Extension Flags (8 bits): 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 (8 bits): Message Type has the same value as in the
header (i.e., 80 or 81). general header (i.e., 80 or 81).
Tech Type: MUST be set to 0x05 (DSL). Tech Type (8 bits): MUST be set to 0x05 (DSL).
# of TLVs: the number of TLVs that follow, not counting TLVs Reserved (8 bits): set as described in Section 3.4.
encapsulated within other TLVs.
Extension Block Length: the total length of the TLVs carried in the # of TLVs (16 bits): The number of TLVs that follow, not counting
extension block in bytes, including any padding within individual TLVs encapsulated within other TLVs.
TLVs.
TLVs: one or more TLVs to identify a DSL line and zero or more TLVs Extension Block Length (16 bits): The total length of the TLVs
to define its characteristics. carried in the extension block in bytes, including any padding
within individual TLVs.
TLVs: One or more TLVs to identify a DSL access line and zero or
more TLVs to define its characteristics.
6.4. Procedures 6.4. Procedures
6.4.1. Procedures On the AN Side 6.4.1. Procedures on the AN Side
The AN-side ANCP agent creates and transmits a DSL-specific Port Up The AN-side ANCP agent creates and transmits a DSL-specific Port Up
or Port Down message when requested by the AN control application and or Port Down message when requested by the AN control application and
presented with the information needed to build a valid message. It presented with the information needed to build a valid message. It
is RECOMMENDED that the Access Node use a dampening mechanism per DSL is RECOMMENDED that the Access Node use a dampening mechanism per DSL
loop to control the rate at which state changes are communicated to access line to control the rate at which state changes are
the NAS. communicated 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 access line.
TLVs presenting DSL line attributes (i.e., the TLVs specified in TLVs presenting DSL access line attributes (i.e., the TLVs specified
Section 6.5) MUST be encapsulated within the DSL-Line-Attributes TLV. in Section 6.5) MUST be encapsulated within the DSL-Line-Attributes
When the DSL-Line-Attributes TLV is present in a message, it MUST TLV. When the DSL-Line-Attributes TLV is present in a message, it
contain at least one such TLV and will generally contain more than MUST contain at least one such TLV and will generally contain more
one. In the Port Up message, the DSL-Line-Attributes TLV MUST be than one. In the Port Up message, the DSL-Line-Attributes TLV MUST
present. In the Port Down message, the DSL-Line-Attributes TLV MAY be present. In the Port Down message, the DSL-Line-Attributes TLV
be present. MAY be present.
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 access line or logical port at any time
negotiation of an adjacency has been completed. It is possible for after negotiation of an adjacency has been completed. It is possible
two Port Up messages in succession to be received for the same DSL for two Port Up messages in succession to be received for the same
loop without an intervening Port Down message, and vice versa. DSL access line 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 Sections 5.1.2 and 6.5. If it finds an error, it MAY generate a
generate a Generic Response message containing an appropriate Result Generic Response message containing an appropriate Result Code value.
Code value. If it does so, the message MUST contain copies of all of If it does so, the message MUST contain copies of all of the
the identifier TLVs from Section 5.1.2 that were present in the Port identifier TLVs from Section 5.1.2 that were present in the Port Up
Up or Port Down message. The message SHOULD also contain a Status- or Port Down message. The message MUST also contain a Status-Info
Info TLV which in turn contains other information appropriate to the TLV that in turn contains other information appropriate to the
message header Result 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 6.5. TLVs for DSL Line Attributes
extracts the information from the TLVs contained in the message and
presents that information along with an indication of reported event
type to the NAS control application. If validation of individual
TLVs fails but the message as a whole can be processed, the NAS-side
ANCP agent "may" pass the valid message contents to the NAS control
application.
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
Description: This TLV encapsulates attribute values for a DSL line Description: This TLV encapsulates attribute values for a DSL access
serving a subscriber. line serving a subscriber.
Length: variable (up to 1024 bytes) Length: Variable (up to 1023 bytes)
Value: one or more encapsulated TLVs corresponding to DSL line Value: One or more encapsulated TLVs corresponding to DSL access
attributes. The DSL-Line-Attributes TLV MUST contain at least one line attributes. The DSL-Line-Attributes TLV MUST contain at
TLV when it is present in a Port Up or Port Down message. The least one TLV when it is present in a Port Up or Port Down
actual contents are determined by the AN control application. message. The actual contents are determined by the AN control
application.
6.5.2. DSL-Type TLV 6.5.2. DSL-Type TLV
Type: 0x0091 Type: 0x0091
Description: Indicates the type of transmission system in use. Description: Indicates the type of transmission system in use.
Length: 4 bytes Length: 4 bytes
Value: 32 bit unsigned integer
Value: 32-bit unsigned integer
ADSL1 = 1 ADSL1 = 1
ADSL2 = 2 ADSL2 = 2
ADSL2+ = 3 ADSL2+ = 3
VDSL1 = 4 VDSL1 = 4
VDSL2 = 5 VDSL2 = 5
SDSL = 6 SDSL = 6
OTHER = 0 OTHER = 0
6.5.3. Actual-Net-Data-Rate-Upstream TLV 6.5.3. Actual-Net-Data-Rate-Upstream TLV
Type: 0x0081 Type: 0x0081
Description: Actual upstream net data rate on a DSL line. Description: Actual upstream net data rate on a DSL access line.
Length: 4 bytes Length: 4 bytes
Value: Rate in Kbits/s as a 32 bit unsigned integer Value: Rate in kbits/s as a 32-bit unsigned integer
6.5.4. Actual-Net-Data-Rate-Downstream TLV 6.5.4. Actual-Net-Data-Rate-Downstream TLV
Type: 0x0082 Type: 0x0082
Description: Actual downstream net data rate on a DSL line. Description: Actual downstream net data rate on a DSL access line.
Length: 4 bytes Length: 4 bytes
Value: Rate in Kbits/s as a 32 bit unsigned integer Value: Rate in kbits/s as a 32-bit unsigned integer
6.5.5. Minimum-Net-Data-Rate-Upstream TLV 6.5.5. Minimum-Net-Data-Rate-Upstream TLV
Type: 0x0083 Type: 0x0083
Description: Minimum upstream net data rate desired by the operator. Description: Minimum upstream net data rate desired by the operator.
Length: 4 bytes Length: 4 bytes
Value: Rate in Kbits/s as a 32 bit unsigned integer Value: Rate in kbits/s as a 32-bit unsigned integer
6.5.6. Minimum-Net-Data-Rate-Downstream TLV 6.5.6. Minimum-Net-Data-Rate-Downstream TLV
Type: 0x0084 Type: 0x0084
Description: Minimum downstream net data rate desired by the Description: Minimum downstream net data rate desired by the
operator. operator.
Length: 4 bytes Length: 4 bytes
Value: Rate in Kbits/s as a 32 bit unsigned integer Value: Rate in kbits/s as a 32-bit unsigned integer
6.5.7. Attainable-Net-Data-Rate-Upstream TLV 6.5.7. Attainable-Net-Data-Rate-Upstream TLV
Type: 0x0085 Type: 0x0085
Description: Maximum net upstream rate that can be attained on the Description: Maximum net upstream rate that can be attained on the
DSL line. DSL access line.
Length: 4 bytes Length: 4 bytes
Value: Rate in Kbits/s as a 32 bit unsigned integer Value: Rate in kbits/s as a 32-bit unsigned integer
6.5.8. Attainable-Net-Data-Rate-Downstream TLV 6.5.8. Attainable-Net-Data-Rate-Downstream TLV
Type: 0x0086 Type: 0x0086
Description: Maximum net downstream rate that can be attained on the Description: Maximum net downstream rate that can be attained on the
DSL line. DSL access line.
Length: 4 bytes Length: 4 bytes
Value: Rate in Kbits/s as a 32 bit unsigned integer Value: Rate in kbits/s as a 32-bit unsigned integer
6.5.9. Maximum-Net-Data-Rate-Upstream TLV 6.5.9. Maximum-Net-Data-Rate-Upstream TLV
Type: 0x0087 Type: 0x0087
Description: Maximum net upstream data rate desired by the operator. Description: Maximum net upstream data rate desired by the operator.
Length: 4 bytes Length: 4 bytes
Value: Rate in Kbits/s as a 32 bit unsigned integer Value: Rate in kbits/s as a 32-bit unsigned integer
6.5.10. Maximum-Net-Data-Rate-Downstream TLV 6.5.10. Maximum-Net-Data-Rate-Downstream TLV
Type: 0x0088 Type: 0x0088
Description: Maximum net downstream data rate desired by the Description: Maximum net downstream data rate desired by the
operator. operator.
Length: 4 bytes Length: 4 bytes
Value: Rate in Kbits/s as a 32 bit unsigned integer Value: Rate in kbits/s as a 32-bit unsigned integer
6.5.11. Minimum-Net-Low-Power-Data-Rate-Upstream TLV 6.5.11. Minimum-Net-Low-Power-Data-Rate-Upstream TLV
Type: 0x0089 Type: 0x0089
Description: Minimum net upstream data rate desired by the operator Description: Minimum net upstream data rate desired by the operator
in low power state. in low power state.
Length: 4 bytes Length: 4 bytes
Value: Rate in Kbits/s as a 32 bit unsigned integer Value: Rate in kbits/s as a 32-bit unsigned integer
6.5.12. Minimum-Net-Low-Power-Data-Rate-Downstream TLV 6.5.12. Minimum-Net-Low-Power-Data-Rate-Downstream TLV
Type: 0x008A Type: 0x008A
Description: Minimum net downstream data rate desired by the Description: Minimum net downstream data rate desired by the
operator in low power state. operator in low power state.
Length: 4 bytes Length: 4 bytes
Value: Rate in Kbits/s as a 32 bit unsigned integer Value: Rate in kbits/s as a 32-bit unsigned integer
6.5.13. Maximum-Interleaving-Delay-Upstream TLV 6.5.13. Maximum-Interleaving-Delay-Upstream TLV
Type: 0x008B Type: 0x008B
Description: maximum one way interleaving delay. Description: Maximum one-way interleaving delay.
Length: 4 bytes Length: 4 bytes
Value: Time in ms as a 32 bit unsigned integer Value: Time in ms as a 32-bit unsigned integer
6.5.14. Actual-Interleaving-Delay-Upstream TLV 6.5.14. Actual-Interleaving-Delay-Upstream TLV
Type: 0x008C Type: 0x008C
Description: Value corresponding to the interleaver setting. Description: Value corresponding to the interleaver setting.
Length: 4 bytes Length: 4 bytes
Value: Time in ms as a 32 bit unsigned integer Value: Time in ms as a 32-bit unsigned integer
6.5.15. Maximum-Interleaving-Delay-Downstream TLV 6.5.15. Maximum-Interleaving-Delay-Downstream TLV
Type: 0x008D Type: 0x008D
Description: maximum one way interleaving delay. Description: Maximum one-way interleaving delay.
Length: 4 bytes Length: 4 bytes
Value: Time in ms as a 32 bit unsigned integer Value: Time in ms as a 32-bit unsigned integer
6.5.16. Actual-Interleaving-Delay-Downstream 6.5.16. Actual-Interleaving-Delay-Downstream
Type: 0x008E Type: 0x008E
Description: Value corresponding to the interleaver setting. Description: Value corresponding to the interleaver setting.
Length: 4 bytes Length: 4 bytes
Value: Time in ms as a 32 bit unsigned integer Value: Time in ms as a 32-bit unsigned integer
6.5.17. DSL-Line-State TLV 6.5.17. DSL-Line-State TLV
Type: 0x008F Type: 0x008F
Description: The state of the DSL line. Description: The state of the DSL access line.
Length: 4 bytes Length: 4 bytes
Value: 32 bit unsigned integer Value: 32-bit unsigned integer
SHOWTIME = 1 SHOWTIME = 1
IDLE = 2 IDLE = 2
SILENT = 3 SILENT = 3
6.5.18. Access-Loop-Encapsulation TLV 6.5.18. Access-Loop-Encapsulation TLV
Type: 0x0090 Type: 0x0090
Description: The data link protocol and, optionally, the Description: The data link protocol and, optionally, the
encapsulation overhead on the access loop. When this TLV is encapsulation overhead on the access loop. When this TLV is
present, at least the data link protocol MUST be indicated. The present, at least the data link protocol MUST be indicated. The
encapsulation overhead MAY be indicated. The Access Node MAY encapsulation overhead MAY be indicated. The Access Node MAY
choose to not convey the encapsulation on the access loop by choose to not convey the encapsulation on the access loop by
specifying values of 0 (NA) for the two encapsulation fields. specifying values of 0 (NA) for the two encapsulation fields.
Length: 3 bytes Length: 3 bytes
skipping to change at page 59, line 15 skipping to change at page 58, line 34
Description: The data link protocol and, optionally, the Description: The data link protocol and, optionally, the
encapsulation overhead on the access loop. When this TLV is encapsulation overhead on the access loop. When this TLV is
present, at least the data link protocol MUST be indicated. The present, at least the data link protocol MUST be indicated. The
encapsulation overhead MAY be indicated. The Access Node MAY encapsulation overhead MAY be indicated. The Access Node MAY
choose to not convey the encapsulation on the access loop by choose to not convey the encapsulation on the access loop by
specifying values of 0 (NA) for the two encapsulation fields. specifying values of 0 (NA) for the two encapsulation fields.
Length: 3 bytes Length: 3 bytes
Value: The three bytes (most to least significant) and valid set of Value: The 3 bytes (most to least significant) and valid set of
values for each byte are defined as follows: values for each byte are defined as follows:
Byte 1: Data Link Byte 1: Data Link
ATM AAL5 = 0 ATM AAL5 = 0
ETHERNET = 1 ETHERNET = 1
Byte 2: Encapsulation 1 Byte 2: Encapsulation 1
skipping to change at page 59, line 40 skipping to change at page 59, line 11
Single-tagged Ethernet = 2 Single-tagged Ethernet = 2
Double-tagged Ethernet = 3 Double-tagged Ethernet = 3
Byte 3: Encapsulation 2 Byte 3: Encapsulation 2
NA = 0 NA = 0
PPPoA LLC = 1 PPPoA LLC = 1
PPPoA NULL = 2 PPPoA Null = 2
IPoA LLC = 3 IPoA LLC = 3
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 16. 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) |
skipping to change at page 60, line 18 skipping to change at page 59, line 37
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 16: 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 access line or
triggered by a subsequent user session establishment (via PPP or triggered by a subsequent user session establishment (via PPP or
DHCP), RADIUS/AAA sends service parameters to the NAS control DHCP), RADIUS/AAA sends service parameters to the NAS control
application for configuration on the access line. The NAS control application for configuration on the access line. The NAS control
application passes the request on to the NAS-side agent, which sends application passes the request on to the NAS-side agent, which sends
the 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 17 summarizes the interaction. Figure 17 summarizes the interaction.
Home Access NAS RADIUS/AAA Home Access NAS RADIUS/AAA
skipping to change at page 60, line 50 skipping to change at page 60, line 20
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 17: 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 18 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 18: Message flow - ANCP Mapping For Updated Line Configuration OSS: Operations Support System
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 access line configuration capability is assigned capability
0x0002. No capability data is associated with this capability. type 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 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.
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 access line configuration
format shown in Figure 19. has the 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) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Unused (12 bytes) ~ ~ Unused (12 bytes) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused (2 bytes) | Function=8 | X-Function=0 | | Unused (2 bytes) | Function=8 | X-Function=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused (4 bytes) | | Unused (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Message Type | Reserved | |x|x|x|x|x|x|x|x| Message Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs | Extension Block length (bytes) | | # of TLVs | Extension Block length (bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Access line identifying TLV(s) ~ ~ Access line identifying TLV(s) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ 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 19: 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 Result Code
The Message Type field MUST be set to 32. The 12 bit Result Code field MUST be set to 0x0. The 4-bit Result field MUST be set to
field MUST be set to 0x0. The 4 bit Result field MUST be set to either 0x1 (Nack) or 0x2 (AckAll), as determined by policy on the
either 1 (NAck) or 2 (AckAll), as determined by policy on the NAS. NAS. The 24-bit Transaction Identifier field MUST be set to a
The 24-bit Transaction Identifier field MUST be set to a positive positive value. Other fields in the general header MUST be set as
value. Other fields in the general header MUST be set as described described in Section 3.6.
in Section 3.6.
The handling of the various unused/reserved fields is described in The handling of the various unused/reserved fields is described in
Section 3.4. Section 3.4.
The remaining message fields are described as follows: The remaining message fields are described as follows:
Function: action to be performed. For line configuration, Function Function (8 bits): Action to be performed. For line configuration,
MUST be set to 8 (Configure Connection Service Data). This action Function MUST be set to 8 (Configure Connection Service Data).
type requests the Access Node (i.e., DSLAM) to apply service This action type requests the Access Node (i.e., DSLAM) to apply
configuration data contained in the line configuration TLVs to the service configuration data contained in the line configuration
DSL line designated by the access line identifying TLVs. TLVs to the DSL access line designated by the access line
identifying TLVs.
X-Function: qualifies the action set by Function. For DSL line X-Function (8 bits): Qualifies the action set by Function. For DSL
configuration, this field MUST be set to 0. access line configuration, this field MUST be set to 0.
Extension Flags: the flag bits denoted by 'x' before the Message Extension Flags (8 bits): The flag bits denoted by 'x' before the
Type field are reserved for future use. Message Type field are reserved for future use.
Message Type: Message Type has the same value as in the general Message Type (8 bits): Message Type has the same value as in the
header (i.e., 32). general header (i.e., 32).
Reserved (16 bits): reserved for future use. Reserved (16 bits): Reserved for future use.
# of TLVs: the number of TLVs that follow, not counting TLVs # of TLVs (16 bits): The number of TLVs that follow, not counting
encapsulated within other TLVs. TLVs encapsulated within other TLVs.
Extension Block Length: the total length of the TLVs carried in the Extension Block Length (16 bits): The total length of the TLVs
extension block in bytes, including any padding within individual carried in the extension block in bytes, including any padding
TLVs. within individual TLVs.
TLVs: two or more TLVs to identify a DSL line and configure its TLVs: Two or more TLVs to identify a DSL access line and configure
service data. its service data.
Other ANCP capabilities, either specific to DSL or technology- Other ANCP capabilities, either specific to DSL or technology-
independent, MAY reuse the Port Management message for service independent, MAY reuse the Port Management message for service
configuration. If the settings of the fixed fields are compatible configuration. If the settings of the fixed fields are compatible
with the settings just described, the same Port Management message with the settings just described, the same Port Management message
that is used for DSL line configuration MAY be used to carry TLVs that is used for DSL access line configuration MAY be used to carry
relating to the other capabilities that apply to the same DSL loop. TLVs relating to the other capabilities that apply to the same DSL
access line.
Use of the Port Management message for configuration MAY also be Use of the Port Management message for configuration MAY also be
generalized to other access technologies, if the respective generalized to other access technologies, if the respective
capabilities specify use of access line identifiers appropriate to capabilities specify use of access line identifiers appropriate to
those technologies in place of the identifiers defined in those technologies in place of the identifiers defined in
Section 5.1.2. Section 5.1.2.
7.4. Procedures 7.4. Procedures
Service configuration MAY be performed on an access line regardless Service configuration MAY be performed on an access line regardless
of its current state. of its current state.
7.4.1. Procedures On the NAS Side 7.4.1. Procedures on the NAS Side
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 MUST create and
send a Port Management message with the fixed fields set as described send a Port Management message with the fixed fields set as described
in the previous section. The message MUST contain one or more TLVs in the previous section. The message MUST contain one or more TLVs
to identify an access line according the requirements of to identify an access line according the requirements of
Section 5.1.2. The NAS MUST include one or more TLVs to configure Section 5.1.2. The NAS MUST include one or more TLVs to configure
line service parameters for that line. Section 7.5 currently line service parameters for that line. Section 7.5 currently
identifies only one such TLV, Service-Profile-Name, but other TLVs identifies only one such TLV, Service-Profile-Name, but other TLVs
MAY be added by extensions to ANCP. MAY be added by extensions to ANCP.
7.4.2. Procedures On the AN Side 7.4.2. Procedures on the AN Side
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 access line or logical
any time after negotiation of an adjacency has been completed. port at 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 Sections 5.1.2 and 7.5. If it finds an error it MUST return a
return a Port Management response message which copies the Port Port Management response message that copies the Port Management
Management request as it was received, but has the Result header request as it was received, but has the Result header field set to
field set to 0x04 (Failure) and the Result Code field set to the 0x04 (Failure) and the Result Code field set to the appropriate
appropriate value. The AN-side agent MAY add a Status-Info TLV value. The AN-side agent MAY add a Status-Info TLV (Section 4.5) to
(Section 4.5) to provide further information on the error, provide further information on the error, particularly if this is
particularly if this is recommended in Section 3.6.1.4 for the given recommended in Section 3.6.1.4 for the given Result Code value. If
Result Code value. If it does so, the various length fields and the it does so, the various length fields and the # of TLVs field within
# of TLVs field within the message MUST be adjusted accordingly. the message MUST be adjusted accordingly.
If the received message passes validation, the AN-side ANCP agent
"must" extract the information from the TLVs contained in the message
and present that information to the AN control application. In
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
application that a response is required. When the AN control
application indicates that it has processed the request successfully,
the AN-side agent MUST return a Port Management response message
which duplicates the request except that the Result header field is
set to 0x3 (Success). (The Result Code field, as in the original
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 access 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 access line (e.g., rates, interleaving delay, multicast
entitlement access-list). channel entitlement access-list).
7.5.1. Service-Profile-Name TLV 7.5.1. Service-Profile-Name TLV
Type: 0x0005 Type: 0x0005
Description: Reference to a pre-configured profile on the DSLAM that Description: Reference to a pre-configured profile on the DSLAM that
contains service specific data for the subscriber. contains service-specific data for the subscriber.
Length: up to 64 bytes Length: Up to 64 bytes
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 initiates 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 line. 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 (Operations,
control application has supplied test parameters, they are used, Administration, and Maintenance, OAM) message. If the NAS control
otherwise the AN control application uses default test parameters. application has supplied test parameters, they are used; otherwise,
If a loop count parameter provided by the NAS is outside the valid the AN control application uses default test parameters. If a loop
range, the AN does not execute the test, but returns a result count parameter provided by the NAS is outside the valid range, the
indicating that the test has failed due to an invalid parameter. If AN does not execute the test, but returns a result indicating that
the test takes longer than the timeout value (default or provided by the test has failed due to an invalid parameter. If the test takes
the NAS) the AN control application can return a failure result longer than the timeout value (default or provided by the NAS), the
indicating timeout or else can send no response. The AN control AN control application can return a failure result indicating timeout
application can provide a human-readable string describing the test or else can send no response. The AN control application can provide
results, for both failures and successes. If provided, this string a human-readable string describing the test results, for both
is included in the response. Responses always include the opaque failures and successes. If provided, this string is included in the
data, if any, provided by the NAS control application. response. Responses always include the opaque data, if any, provided
by the NAS control application.
Figure 20 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 20: Message Flow For ANCP based OAM CPE: Customer Premises Equipment
EFM: Ethernet First Mile
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 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.
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 access line testing has the same
as for DSL line configuration (see Section 7.3), with the following format as for DSL access line configuration (see Section 7.3), with
differences: the following 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 (0x2), 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 subscriber service information.
The Port Management (OAM) message is illustrated in Figure 21. 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) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port (unused) | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Unused (12 bytes) ~
| Port Session Number (unused) | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Sequence Number (unused) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|x|x|x|x|x|x|x| Dur. (unused) | Function=9 | X-Function=0 | | Unused (2 bytes) | Function=9 | X-Function=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Flags (unused) | Flow Control Flags (unused) | | Unused (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Message Type | Reserved | |x|x|x|x|x|x|x|x| Message Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs | Extension Block length (bytes) | | # of TLVs | Extension Block length (bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Access line identifying TLV(s) ~ ~ Access line identifying TLV(s) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ 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 21: Port Management Message For DSL Line Remote Connectivity Figure 21: Port Management Message for
Testing DSL Line Remote Connectivity 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
skipping to change at page 69, line 15 skipping to change at page 69, line 13
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 Sections 5.1.2 and 8.5. If it finds an error it MUST return a
return a Port Management response message which copies the Port Port Management response message that copies the Port Management
Management request as it was received, but has the Result header request as it was received, but has the Result header field set to
field set to 0x04 (Failure) and the Result Code field set to the 0x04 (Failure) and the Result Code field set to the appropriate
appropriate value. Result Code value 0x509 as described below MAY value. Result Code value 0x509 as described below MAY apply, as well
apply, as well as the other Result Code values documented in as the other Result Code values documented in Section 3.6.1.4.
Section 3.6.1.4. Result Code value 0x509 SHOULD be used if the OAM- Result Code value 0x509 SHOULD be used if the OAM-Loopback-Test-
Loopback-Test-Parameters TLV is present with an invalid value of the Parameters TLV is present with an invalid value of the Count field.
Count field. The AN-side agent MAY add a Status-Info TLV The AN-side agent MAY add a Status-Info TLV (Section 4.5) to provide
(Section 4.5) to provide further information on the error, further information on the error, particularly if this is recommended
particularly if this is recommended in Section 3.6.1.4 for the given in Section 3.6.1.4 for the given Result Code value. If it does so,
Result Code value. If it does so, the various length fields and the the various length fields and the # of TLVs field within the message
# of TLVs field within the message MUST be adjusted accordingly. 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
extracts the information from the TLVs contained in the message and extracts the information from the TLVs contained in the message and
presents that information to the AN control application. It MUST NOT presents that information to the AN control application. It MUST NOT
generate an immediate response to the request, but MUST instead wait generate an immediate response to the request, but it MUST instead
for the AN control application to indicate that the response should wait for the AN control application to indicate that the response
be sent. should 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 creates and sends a necessary information to do so, the AN-side agent creates and sends a
Port Management (OAM) response to the original request. The Result Port Management (OAM) response to the original request. The Result
field MUST be set to Success (0x3) or Failure (0x4), and the Result field MUST be set to Success (0x3) or Failure (0x4), and the Result
Code field SHOULD be set to one of the following values, as indicated Code field SHOULD be set to one of the following values, as indicated
by the AN control application. by the AN control application.
0x500: Specified access line does not exist. See the documentation 0x500: Specified access line does not exist. See the documentation
of Result Code 0x500 in Section 3.6.1.4 for more information. The of Result Code 0x500 in Section 3.6.1.4 for more information. The
Result header field MUST be set to Failure (0x4). Result header field MUST be set to Failure (0x4).
0x501: Loopback test timed out. The Result header field MUST be set 0x501: Loopback test timed out. The Result header field MUST be set
to Failure (0x4). to Failure (0x4).
0x503: DSL line status showtime 0x503: DSL access line status showtime
0x504: DSL access line status idle
0x504: DSL line status idle
0x505: DSL line status silent 0x505: DSL access line status silent
0x506: DSL line status training 0x506: DSL access line status training
0x507: DSL line integrity error 0x507: DSL access line integrity error
0x508: DSLAM resource not available. The Result header field MUST 0x508: DSLAM resource not available. The Result header field MUST
be set to Failure (0x04). be set to Failure (0x04).
0x509: Invalid test parameter. The Result header field MUST be set 0x509: Invalid test parameter. The Result header field MUST 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
The following TLVs have been defined for use with the DSL line The following TLVs have been defined for use with the DSL access line
testing capability. testing capability.
8.5.1. OAM-Loopback-Test-Parameters TLV 8.5.1. OAM-Loopback-Test-Parameters TLV
Type: 0x0007 Type: 0x0007
Description: Parameters intended to override the default values for Description: Parameters intended to override the default values for
this loopback test. this loopback test.
Length: 2 bytes Length: 2 bytes
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 to indicate that the DSLAM MUST use a locally be used to indicate that the DSLAM MUST use a locally
determined value for the timeout. determined value for the timeout.
The OAM-Loopback-Test-Parameters TLV is illustrated in Figure 22 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 22: 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.
Length: 8 bytes Length: 8 bytes
Value: Two 32 bit unsigned integers. Value: Two 32-bit unsigned integers.
8.5.3. OAM-Loopback-Test-Response-String TLV 8.5.3. OAM-Loopback-Test-Response-String TLV
Type: 0x0009 Type: 0x0009
Description: Suitably formatted string containing useful details Description: Suitably formatted string containing useful details
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
IANA NOTE: please replace "RFCXXXX" with the number of this This section documents the following IANA actions:
specification.
9.1. Summary
This section requests the following IANA actions:
o establishment of the following new ANCP registries: o establishment of the following new ANCP registries:
ANCP Message Types; ANCP Message Types;
ANCP Result Codes; ANCP Result Codes;
ANCP Port Management Functions; 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.
skipping to change at page 72, line 28 skipping to change at page 72, line 17
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 establishment of a new joint GSMP/ANCP version registry;
o addition of ANCP as another user of TCP port 6068 in the port o addition of ANCP as another user of TCP port 6068 in the port
number registry at http://www.iana.org/assignments/port-numbers. number registry available from http://www.iana.org. The current
The current user is GSMP. user is GSMP.
All of these actions are described in detail below except for the All of these actions are described in detail below except for the
port registration, for which the final point above should provide port registration, for which the final point above provides
sufficient information. sufficient information.
9.2. IANA Actions 10. IANA Actions
9.2.1. ANCP Message Type Registry 10.1. ANCP Message Type Registry
IANA is requested to create a new registry, Access Network Control IANA has created a new registry, ANCP Message Types. Additions to
Protocol (ANCP) Message Types. Additions to that registry are that registry are permitted by Standards Action, as defined by
permitted by Standards Action, as defined by [RFC5226]. The values [RFC5226]. The values for Message Type MAY range from 0 to 255, but
for Message Type MAY range from 0 to 255, but new Message Types new Message Types SHOULD be assigned values sequentially from 90
SHOULD be assigned values sequentially from 90 onwards (noting that onwards (noting that 91 and 93 are already assigned). The initial
91 and 93 are already assigned). The initial contents of the ANCP contents of the ANCP Message Types registry are as follows:
Message Types registry are as follows:
+--------------+--------------------+-----------+ +--------------+--------------------+-----------+
| Message Type | Message Name | Reference | | Message Type | Message Name | Reference |
+--------------+--------------------+-----------+ +--------------+--------------------+-----------+
| 10 | Adjacency Protocol | RFCXXXX | | 10 | Adjacency Protocol | RFC 6320 |
| 32 | Port Management | RFCXXXX | | 32 | Port Management | RFC 6320 |
| 80 | Port Up | RFCXXXX | | 80 | Port Up | RFC 6320 |
| 81 | Port Down | RFCXXXX | | 81 | Port Down | RFC 6320 |
| 85 | Adjacency Update | RFCXXXX | | 85 | Adjacency Update | RFC 6320 |
| 91 | Generic Response | RFCXXXX | | 91 | Generic Response | RFC 6320 |
| 93 | Provisioning | RFCXXXX | | 93 | Provisioning | RFC 6320 |
+--------------+--------------------+-----------+ +--------------+--------------------+-----------+
9.2.2. ANCP Result Code Registry 10.2. ANCP Result Code Registry
IANA is requested to create a new registry, Access Network Control IANA has created a new registry, ANCP Result Codes. The
Protocol (ANCP) Result Codes. The documentation of new Result Codes documentation of new Result Codes MUST include the following
MUST include the following information: information:
o Result Code value TBD (as assigned by IANA); o Result Code value (as assigned by IANA);
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.
The values for Result Code are expressed in hexadecimal, and MAY The values for Result Code are expressed in hexadecimal and MAY range
range from 0x0 to 0xFFFFFF. The range 0x0 to 0xFFF is reserved for from 0x0 to 0xFFFFFF. The range 0x0 to 0xFFF is allocated by the
allocation by the criterion of IETF Review, as defined by [RFC5226]. criterion of IETF Review, as defined by [RFC5226]. IANA SHOULD
IANA SHOULD allocate new Result Code values from this range allocate new Result Code values from this range sequentially
sequentially beginning at 0x100. The range 0x1000 onwards is beginning at 0x100. The range 0x1000 onwards is allocated by the
allocated by the criterion of Specification Required, as defined by criterion of Specification Required, as defined by [RFC5226]. IANA
[RFC5226]. IANA SHOULD allocate new Result Code values from this SHOULD allocate new Result Code values from this range sequentially
range sequentially beginning at 0x1000. The initial contents of the beginning at 0x1000. The initial contents of the ANCP Message Types
ANCP Message Types registry are as follows: registry are as follows:
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
| Result | One-line description | Reference | | Result | One-line description | Reference |
| Code | | | | Code | | |
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
| 0x0 | No result | RFCXXXX | | 0x0 | No result | RFC 6320 |
| 0x2 | Invalid request message | RFCXXXX | | 0x2 | Invalid request message | RFC 6320 |
| 0x6 | One or more of the specified ports are | RFCXXXX | | 0x6 | One or more of the specified ports are | RFC 6320 |
| | down | | | | down | |
| 0x13 | Out of resources | RFCXXXX | | 0x13 | Out of resources | RFC 6320 |
| 0x51 | Request message type not implemented | RFCXXXX | | 0x51 | Request message type not implemented | RFC 6320 |
| 0x53 | Malformed message | RFCXXXX | | 0x53 | Malformed message | RFC 6320 |
| 0x54 | Mandatory TLV missing | RFCXXXX | | 0x54 | Mandatory TLV missing | RFC 6320 |
| 0x55 | Invalid TLV contents | RFCXXXX | | 0x55 | Invalid TLV contents | RFC 6320 |
| 0x500 | One or more of the specified ports do | RFCXXXX | | 0x500 | One or more of the specified ports do | RFC 6320 |
| | not exist | | | | not exist | |
| 0x501 | Loopback test timed out (0x501) | RFCXXXX | | 0x501 | Loopback test timed out | RFC 6320 |
| 0x502 | Reserved (0x502) | RFCXXXX | | 0x502 | Reserved | RFC 6320 |
| 0x503 | DSL line status showtime (0x503) | RFCXXXX | | 0x503 | DSL access line status showtime | RFC 6320 |
| 0x504 | DSL line status idle (0x504) | RFCXXXX | | 0x504 | DSL access line status idle | RFC 6320 |
| 0x505 | DSL line status silent (0x505) | RFCXXXX | | 0x505 | DSL access line status silent | RFC 6320 |
| 0x506 | DSL line status training (0x506) | RFCXXXX | | 0x506 | DSL access line status training | RFC 6320 |
| 0x507 | DSL line integrity error (0x507) | RFCXXXX | | 0x507 | DSL access line integrity error | RFC 6320 |
| 0x508 | DSLAM resource not available (0x508) | RFCXXXX | | 0x508 | DSLAM resource not available | RFC 6320 |
| 0x509 | Invalid test parameter (0x509) | RFCXXXX | | 0x509 | Invalid test parameter | RFC 6320 |
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
9.2.3. ANCP Port Management Function Registry 10.3. ANCP Port Management Function Registry
IANA is requested to create a new Access Network Control Protocol IANA has created a new ANCP Port Management Function registry, with
(ANCP) Port Management Function registry, with the following initial the following initial entries. Additions to this registry will be by
entries. Additions to this registry will be by Standards Action, as Standards Action, as defined by [RFC5226]. Values may range from 0
defined by [RFC5226]. Values may range from 0 to 255. IANA SHOULD to 255. IANA SHOULD assign values sequentially beginning with 1,
assign values sequentially beginning with 1, taking account of the taking account of the values already assigned below.
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 | RFC 6320 |
| 8 | Configure Connection Service Data | RFCXXXX | | 8 | Configure Connection Service Data | RFC 6320 |
| 9 | Remote Loopback | RFCXXXX | | 9 | Remote Loopback | RFC 6320 |
+----------------+-----------------------------------+-----------+ +----------------+-----------------------------------+-----------+
9.2.4. ANCP Technology Type Registry 10.4. ANCP Technology Type Registry
IANA is requested to create a new Access Network Control Protocol IANA has created a new ANCP Technology Type registry, with additions
(ANCP) Technology Type registry, with additions by Expert Review, as by Expert Review, as defined by [RFC5226]. The Technology Type MUST
defined by [RFC5226]. The Technology Type MUST designate a distinct designate a distinct access transport technology. Values may range
access transport technology. Values may range from 0 to 255. IANA from 0 to 255. IANA SHOULD assign new values sequentially beginning
SHOULD assign new values sequentially beginning at 2, taking into at 2, taking into account of the values already assigned below. The
account of the values already assigned below. The initial entries initial entries are as follows:
are as follows:
+-----------------+--------------------------+-----------+ +-----------------+-------------------------------+-----------+
| Tech Type Value | Tech Type Name | Reference | | Tech Type Value | Tech Type Name | Reference |
+-----------------+--------------------------+-----------+ +-----------------+-------------------------------+-----------+
| 0 | Not technology dependent | RFCXXXX | | 0 | Not technology dependent | RFC 6320 |
| 1 | PON | RFCXXXX | | 1 | Passive Optical Network (PON) | RFC 6320 |
| 5 | DSL | RFCXXXX | | 5 | Digital Subscriber Line (DSL) | RFC 6320 |
| 255 | Reserved | RFCXXXX | | 255 | Reserved | RFC 6320 |
+-----------------+--------------------------+-----------+ +-----------------+-------------------------------+-----------+
9.2.5. ANCP Command Code Registry 10.5. ANCP Command Code Registry
IANA is requested to create a new Access Network Control Protocol IANA has created a new ANCP Command Code registry, with additions by
(ANCP) Command Code registry, with additions by Standards Action, as Standards Action, as defined by [RFC5226]. Values may range from 0
defined by [RFC5226]. Values may range from 0 to 255. IANA SHOULD to 255. IANA SHOULD assign new values sequentially beginning with 1.
assign new values sequentially beginning with 1. The initial entry The initial entry is as follows:
is as follows:
+--------------------+-----------------------------+-----------+ +--------------------+-----------------------------+-----------+
| Command Code Value | Command Code Directive Name | Reference | | Command Code Value | Command Code Directive Name | Reference |
+--------------------+-----------------------------+-----------+ +--------------------+-----------------------------+-----------+
| 0 | Reserved | RFCXXXX | | 0 | Reserved | RFC 6320 |
+--------------------+-----------------------------+-----------+ +--------------------+-----------------------------+-----------+
9.2.6. ANCP TLV Type Registry 10.6. ANCP TLV Type Registry
IANA is requested to create a new Access Network Control Protocol IANA has created a new ANCP TLV Type registry. Values are expressed
(ANCP) TLV Type registry. Values are expressed in hexadecimal and in hexadecimal and may range from 0x0000 to 0xFFFF. Additions in the
may range from 0x0000 to 0xFFFF. Additions in the range 0x0000 to range 0x0000 to 0x1FFF are by IETF Review, as defined by [RFC5226].
0x1FFF are by IETF Review, as defined by [RFC5226]. IANA SHOULD IANA SHOULD assign new values in this range sequentially beginning at
assign new values in this range sequentially beginning at 0x100 and 0x100, taking account of the assignments already made below.
taking account of the assignments already made below. Additions in Additions in the range 0x2000 to 0xFFFF are by Specification
the range 0x2000 to 0xFFFF are by Specification Required, again as Required, again as defined by [RFC5226]. IANA SHOULD assign new
defined by [RFC5226]. IANA SHOULD assign new values in this range values in this range sequentially beginning at 0x2000. In both
sequentially beginning at 0x2000. In both cases, the documentation cases, the documentation of the TLV MUST provide:
of the TLV MUST provide:
o a TLV name following the convention used for the initial entries o a TLV name following the convention used for the initial entries
(capitalized words separated by hyphens); (capitalized words separated by hyphens);
o a brief description of the intended use; o a brief description of the intended use;
o a precise description of the contents of each fixed field, o a precise description of the contents of each fixed field,
including its length, type, and units (if applicable); including its length, type, and units (if applicable);
o identification of any mandatory encapsulated TLVs; o identification of any mandatory encapsulated TLVs;
o an indication of whether optional TLVs may be encapsulated, with o an indication of whether optional TLVs may be encapsulated, with
whatever information is available on their identity (could range whatever information is available on their identity (could range
from a general class of information to specific TLV names, from a general class of information to specific TLV names,
depending on the nature of the TLV being defined. depending on the nature of the TLV being defined).
The initial entries are as follows: The initial entries are as follows:
+----------+--------------------------------------------+-----------+ +----------+--------------------------------------------+-----------+
| Type | TLV Name | Reference | | Type Code| TLV Name | Reference |
| Code | | |
+----------+--------------------------------------------+-----------+ +----------+--------------------------------------------+-----------+
| 0x0000 | Reserved | RFCXXXX | | 0x0000 | Reserved | RFC 6320 |
| 0x0001 | Access-Loop-Circuit-ID | RFCXXXX | | 0x0001 | Access-Loop-Circuit-ID | RFC 6320 |
| 0x0002 | Access-Loop-Remote-Id | RFCXXXX | | 0x0002 | Access-Loop-Remote-ID | RFC 6320 |
| 0x0003 | Access-Aggregation-Circuit-ID-ASCII | RFCXXXX | | 0x0003 | Access-Aggregation-Circuit-ID-ASCII | RFC 6320 |
| 0x0004 | DSL-Line-Attributes | RFCXXXX | | 0x0004 | DSL-Line-Attributes | RFC 6320 |
| 0x0005 | Service-Profile-Name | RFCXXXX | | 0x0005 | Service-Profile-Name | RFC 6320 |
| 0x0006 | Access-Aggregation-Circuit-ID-Binary | RFCXXXX | | 0x0006 | Access-Aggregation-Circuit-ID-Binary | RFC 6320 |
| 0x0007 | OAM-Loopback-Test-Parameters | RFCXXXX | | 0x0007 | OAM-Loopback-Test-Parameters | RFC 6320 |
| 0x0008 | Opaque-Data | RFCXXXX | | 0x0008 | Opaque-Data | RFC 6320 |
| 0x0009 | OAM-Loopback-Test-Response-String | RFCXXXX | | 0x0009 | OAM-Loopback-Test-Response-String | RFC 6320 |
| 0x0011 | Command | RFCXXXX | | 0x0011 | Command | RFC 6320 |
| 0x0081 | Actual-Net-Data-Upstream | RFCXXXX | | 0x0081 | Actual-Net-Data-Rate-Upstream | RFC 6320 |
| 0x0082 | Actual-Net-Data-Rate-Downstream | RFCXXXX | | 0x0082 | Actual-Net-Data-Rate-Downstream | RFC 6320 |
| 0x0083 | Minimum-Net-Data-Rate-Upstream | RFCXXXX | | 0x0083 | Minimum-Net-Data-Rate-Upstream | RFC 6320 |
| 0x0084 | Minimum-Net-Data-Rate-Downstream | RFCXXXX | | 0x0084 | Minimum-Net-Data-Rate-Downstream | RFC 6320 |
| 0x0085 | Attainable-Net-Data-Rate-Upstream | RFCXXXX | | 0x0085 | Attainable-Net-Data-Rate-Upstream | RFC 6320 |
| 0x0086 | Attainable-Net-Data-Rate-Downstream | RFCXXXX | | 0x0086 | Attainable-Net-Data-Rate-Downstream | RFC 6320 |
| 0x0087 | Maximum-Net-Data-Rate-Upstream | RFCXXXX | | 0x0087 | Maximum-Net-Data-Rate-Upstream | RFC 6320 |
| 0x0088 | Maximum-Net-Data-Rate-Downstream | RFCXXXX | | 0x0088 | Maximum-Net-Data-Rate-Downstream | RFC 6320 |
| 0x0089 | Minimum-Net-Low-Power-Data-Rate-Upstream | RFCXXXX | | 0x0089 | Minimum-Net-Low-Power-Data-Rate-Upstream | RFC 6320 |
| 0x008A | Minimum-Net-Low-Power-Data-Rate-Downstream | RFCXXXX | | 0x008A | Minimum-Net-Low-Power-Data-Rate-Downstream | RFC 6320 |
| 0x008B | Maximum-Interleaving-Delay-Upstream | RFCXXXX | | 0x008B | Maximum-Interleaving-Delay-Upstream | RFC 6320 |
| 0x008C | Actual-Interleaving-Delay-Upstream | RFCXXXX | | 0x008C | Actual-Interleaving-Delay-Upstream | RFC 6320 |
| 0x008D | Maximum-Interleaving-Delay-Downstream | RFCXXXX | | 0x008D | Maximum-Interleaving-Delay-Downstream | RFC 6320 |
| 0x008E | Actual-Interleaving-Delay-Downstream | RFCXXXX | | 0x008E | Actual-Interleaving-Delay-Downstream | RFC 6320 |
| 0x008F | DSL-Line-State | RFCXXXX | | 0x008F | DSL-Line-State | RFC 6320 |
| 0x0090 | Access-Loop-Encapsulation | RFCXXXX | | 0x0090 | Access-Loop-Encapsulation | RFC 6320 |
| 0x0091 | DSL-Type | RFCXXXX | | 0x0091 | DSL-Type | RFC 6320 |
| 0x0106 | Status-Info | RFCXXXX | | 0x0106 | Status-Info | RFC 6320 |
| 0x1000 | Target (single access line variant) | RFCXXXX | | 0x1000 | Target (single access line variant) | RFC 6320 |
| 0x1001 - | Reserved for Target variants | RFCXXXX | | 0x1001 - | Reserved for Target variants | RFC 6320 |
| 0x1020 | | | | 0x1020 | | |
+----------+--------------------------------------------+-----------+ +----------+--------------------------------------------+-----------+
9.2.7. ANCP Capability Type Registry 10.7. ANCP Capability Type Registry
IANA is requested to create a new Access Network Control Protocol IANA has created a new ANCP Capability Type registry, with additions
(ANCP) Capability Type registry, with additions by Standards Action by Standards Action as defined by [RFC5226]. Values may range from 0
as defined by [RFC5226]. Values may range from 0 to 255. IANA to 255. IANA SHOULD assign values sequentially beginning at 5. The
SHOULD assign values sequentially beginning at 5. The specification specification for a given capability MUST indicate the Technology
for a given capability MUST indicate the Technology Type value with Type value with which it is associated. The specification MUST
which it is associated. The specification MUST further indicate further indicate whether the capability is associated with any
whether the capability is associated with any capability data. capability data. Normally, a capability is expected to be defined in
Normally a capability is expected to be defined in the same document the same document that specifies the implementation of that
that specifies the implementation of that capability in protocol capability in protocol terms. The initial entries in the ANCP
terms. The initial entries in the ANCP capability registry are as capability registry are as follows:
follows:
+-------+------------------------+--------+-------------+-----------+ +-------+------------------------+--------+-------------+-----------+
| Value | Capability Type Name | Tech | Capability | Reference | | Value | Capability Type Name | Tech | Capability | Reference |
| | | Type | Data? | | | | | Type | Data? | |
+-------+------------------------+--------+-------------+-----------+ +-------+------------------------+--------+-------------+-----------+
| 0 | Reserved | | | RFCXXXX | | 0 | Reserved | | | RFC 6320 |
| 1 | DSL Topology Discovery | 5 | No | RFCXXXX | | 1 | DSL Topology Discovery | 5 | No | RFC 6320 |
| 2 | DSL Line Configuration | 5 | No | RFCXXXX | | 2 | DSL Line Configuration | 5 | No | RFC 6320 |
| 3 | Reserved | | | RFCXXXX | | 3 | Reserved | | | RFC 6320 |
| 4 | DSL Line Testing | 5 | No | RFCXXXX | | 4 | DSL Line Testing | 5 | No | RFC 6320 |
+-------+------------------------+--------+-------------+-----------+ +-------+------------------------+--------+-------------+-----------+
9.2.8. Joint GSMP / ANCP Version Registry 10.8. Joint GSMP / ANCP Version Registry
IANA is requested to create a new joint GSMP / ANCP Version registry. IANA has created a new joint GSMP / ANCP Version registry. Additions
Additions to this registry are by Standards Action as defined by to this registry are by Standards Action as defined by [RFC5226].
[RFC5226]. Values may range from 0 to 255. Values for the General Values may range from 0 to 255. Values for the General Switch
Switch Management Protocol (GSMP) MUST be assigned sequentially Management Protocol (GSMP) MUST be assigned sequentially beginning
beginning with 4 for the next version. Values for the Access Network with 4 for the next version. Values for the Access Network Control
Control Protocol (ANCP) MUST be assigned sequentially beginning with Protocol (ANCP) MUST be assigned sequentially beginning with 50 for
50 for the present version. The initial entries are as follows: the present version. The initial entries are as follows:
+---------+----------------+-----------+ +---------+----------------+-----------+
| Version | Description | Reference | | Version | Description | Reference |
+---------+----------------+-----------+ +---------+----------------+-----------+
| 1 | GSMP Version 1 | RFC1987 | | 1 | GSMP Version 1 | RFC 1987 |
| 2 | GSMP Version 2 | RFC2297 | | 2 | GSMP Version 2 | RFC 2297 |
| 3 | GSMP Version 3 | RFC3292 | | 3 | GSMP Version 3 | RFC 3292 |
| 50 | ANCP Version 1 | RFCXXXX | | 50 | ANCP Version 1 | RFC 6320 |
+---------+----------------+-----------+ +---------+----------------+-----------+
10. Security Considerations 11. Security Considerations
Security of the ANCP protocol is discussed in [RFC5713]. A number of Security of ANCP is discussed in [RFC5713]. A number of security
security requirements on ANCP are stated in Section 8 of that requirements on ANCP are stated in Section 8 of that document. Those
document. Those applicable to ANCP itself are copied to the present applicable to ANCP itself are copied to the present document:
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 78, line 33 skipping to change at page 78, line 26
o The protocol solution MUST provide data-origin authentication. o The protocol solution MUST provide data-origin authentication.
o The protocol solution MUST be robust against denial-of-service o The protocol solution MUST be robust against denial-of-service
(DoS) attacks. In this context, the protocol solution MUST (DoS) attacks. In this context, the protocol solution MUST
consider a specific mechanism for the DoS that the user might consider a specific mechanism for the DoS that the user might
create by sending many IGMP messages. create by sending many IGMP messages.
o The protocol solution SHOULD offer confidentiality protection. o The protocol solution SHOULD offer confidentiality protection.
o The protocol solution SHOULD ensure that operations in default o The protocol solution SHOULD ensure that operations in default
configuration guarantees a low number of AN/NAS protocol configuration guarantee a low number of AN/NAS protocol
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. However, the use of TLS has been requirements listed above. However, the use of TLS has been
rejected. The deciding point is a detail of protocol design that was rejected. The deciding point is a detail of protocol design that was
unavailable when [RFC5713] was written. The ANCP adjacency is a unavailable when [RFC5713] was written. The ANCP adjacency is a
major point of vulnerability for denial-of-service attacks. If the major point of vulnerability for denial-of-service attacks. If the
adjacency can be shut down, either the AN clears its state pending adjacency can be shut down, either the AN clears its state pending
reestablishment of the adjacency, or the possibility of mismatches reestablishment of the adjacency, or the possibility of mismatches
between the AN's and NAS's view of state on the AN is opened up. Two between the AN's and NAS's view of state on the AN is opened up. Two
ways to cause an adjacency to be taken down are to modify messages so ways to cause an adjacency to be taken down are to modify messages so
that the ANCP agents conclude that they are no longer synchronized, that the ANCP agents conclude that they are no longer synchronized,
or to attack the underlying TCP session. TLS will protect message or to attack the underlying TCP session. TLS will protect message
contents, but not the TCP connection. One has to use either IPsec or contents but not the TCP connection. One has to use either IPsec or
the TCP authentication option [RFC5925] for that. Hence the the TCP authentication option [RFC5925] for that. Hence, the
conclusion that ANCP MUST run over IPsec with IKEv2 for conclusion that ANCP MUST run over IPsec with IKEv2 for
authentication and key management. 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, and anti-replay capability. The traffic flow
service of ESP is unnecessary and, in fact, unworkable in the case of confidentiality service of ESP is unnecessary and, in fact,
ANCP. unworkable in the case of ANCP.
IKEv2 [RFC5996] is also REQUIRED, to meet the requirements for mutual IKEv2 [RFC5996] is also REQUIRED, to meet the requirements for mutual
authentication and authorization. Since the NAS and AN MAY be in authentication and authorization. Since the NAS and AN MAY be in
different trust domains, the use of certificates for mutual different trust domains, the use of certificates for mutual
authentication could be the most practical approach. However, this authentication could be the most practical approach. However, this
is up to the operator(s) concerned. is up to the operator(s) concerned.
The AN MUST play the role of initiator of the IKEv2 conversation. The AN MUST play the role of initiator of the IKEv2 conversation.
11. Acknowledgements 12. Contributors
Swami Subramanian was an early member of the authors' team. The ANCP
Working Group is grateful to Roberta Maglione, who served as design
team member and primary editor of this document for two years before
stepping down.
13. Acknowledgements
The authors would like to thank everyone who provided comments or 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. The authors acknowledge the inputs provided
the authors' team. The ANCP Working Group is grateful to Roberta by Wojciech Dec, Peter Arberg, Josef Froehler, Derek Harkness, Kim
Maglione, who served as design team member and primary editor of this Hyldgaard, Sandy Ng, Robert Peschi, and Michel Platnic, and the
document for two years before stepping down. The authors acknowledge further comments provided by Mykyta Yevstifeyev, Brian Carter, Ben
the inputs provided by Wojciech Dec, Peter Arberg, Josef Froehler, Campbell, Alexey Melnikov, Adrian Farrel, Robert Sparks, Peter St.
Derek Harkness, Kim Hyldgaard, Sandy Ng, Robert Peschi, and Michel Andre, Sean Turner, Dan Romascanu, Brian Carter, and Michael Scott.
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 14. References
12.1. Normative References 14.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.
"General Switch Management Protocol (GSMP) V3", RFC 3292, Worster, "General Switch Management Protocol (GSMP)
June 2002. V3", RFC 3292, June 2002.
[RFC3293] Worster, T., Doria, A., and J. Buerkle, "General Switch [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
Management Protocol (GSMP) Packet Encapsulations for 10646", STD 63, RFC 3629, November 2003.
Asynchronous Transfer Mode (ATM), Ethernet and
Transmission Control Protocol (TCP)", RFC 3293, June 2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
10646", STD 63, RFC 3629, November 2003. Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
Internet Protocol", RFC 4301, December 2005. RFC 4303, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
RFC 4303, December 2005. Languages", BCP 47, RFC 5646, September 2009.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
Languages", BCP 47, RFC 5646, September 2009. "Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 14.2. Informative References
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
12.2. Informative References [G.993.2] "ITU-T Recommendation G.993.2, Very high speed digital
subscriber line transceivers 2 (VDSL2)", 2006.
[G.988.1] "ITU-T recommendation G.998.1, ATM-based multi-pair [G.998.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.998.2] "ITU-T Recommendation G.998.2, Ethernet-based multi-
bonding,", 2005. pair bonding,", 2005.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [IEEE802.1Q] IEEE, "IEEE 802.1Q-2005, IEEE Standard for Local and
RFC 2131, March 1997. Metropolitan Area Networks - Virtual Bridged Local
Area Networks - Revision", 2005.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", [IEEE802.1ad] IEEE, "IEEE 802.1ad-2005, Amendment to IEEE 802.1Q-
RFC 3046, January 2001. 2005. IEEE Standard for Local and Metropolitan Area
Networks - Virtual Bridged Local Area Networks -
Revision - Amendment 4: Provider Bridges", 2005.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
and M. Carney, "Dynamic Host Configuration Protocol for RFC 2131, March 1997.
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
(DHCPv6) Relay Agent Remote-ID Option", RFC 4649, RFC 3046, January 2001.
August 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,
IANA Considerations Section in RFCs", BCP 26, RFC 5226, C., and M. Carney, "Dynamic Host Configuration
May 2008. Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for
(TLS) Protocol Version 1.2", RFC 5246, August 2008. IPv6 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649,
August 2006.
[RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
Threats and Security Requirements for the Access Node an IANA Considerations Section in RFCs", BCP 26,
Control Protocol (ANCP)", RFC 5713, January 2010. RFC 5226, May 2008.
[RFC5851] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
Wadhwa, "Framework and Requirements for an Access Node Security (TLS) Protocol Version 1.2", RFC 5246,
Control Mechanism in Broadband Multi-Service Networks", August 2008.
RFC 5851, May 2010.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP [RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder,
Authentication Option", RFC 5925, June 2010. "Security Threats and Security Requirements for the
Access Node Control Protocol (ANCP)", RFC 5713,
January 2010.
[TR-058] Elias, M. and S. Ooghe, "DSL Forum TR-058, Multi-Service [RFC5851] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S.
Architecture & Framework Requirements", September 2003. Wadhwa, "Framework and Requirements for an Access Node
Control Mechanism in Broadband Multi-Service
Networks", RFC 5851, May 2010.
[TR-059] Anschutz, T., "DSL Forum TR-059, DSL Evolution - [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Architecture Requirements for the Support of QoS-Enabled Authentication Option", RFC 5925, June 2010.
IP Services", September 2003.
[TR-092] DSL Forum (now the Broadband Forum), "DSL Forum TR-092, [TR-058] Broadband Forum, "TR-058, Multi-Service Architecture &
Broadband Remote access server requirements document", Framework Requirements", September 2003.
2005.
[TR-101] Cohen et al, "Architecture & Transport: "Migration to [TR-059] Broadband Forum, "TR-059, DSL Evolution - Architecture
Ethernet Based DSL Aggregation", DSL Forum TR-101", 2005. Requirements for the Support of QoS-Enabled IP
Services", September 2003.
[TR-147] Voight et al, "Layer 2 Control Mechanism For Broadband [TR-092] Broadband Forum, "TR-092, Broadband Remote access
Multi-Service Architectures", 2008. server requirements document", 2005.
[US_ASCII] [TR-101] Broadband Forum, "TR-101, Architecture & Transport:
American National Standards Institute, "Coded Character Migration to Ethernet Based DSL Aggregation", 2005.
Set - 7-bit American Standard Code for Information
Interchange", ANSI X.34, 1986. [TR-147] Broadband Forum, "TR-147, Layer 2 Control Mechanism
For Broadband Multi-Service Architectures", 2008.
[US_ASCII] American National Standards Institute, "Coded
Character Set - 7-bit American Standard Code for
Information Interchange", ANSI X.34, 1986.
Authors' Addresses Authors' Addresses
Sanjay Wadhwa Sanjay Wadhwa
Alcatel-Lucent Alcatel-Lucent
701 E Middlefield Rd
Mountain View, CA 94043-4079
USA
EMail: sanjay.wadhwa@alcatel-lucent.com
Phone:
Fax:
Email: sanjay.wadhwa@alcatel-lucent.com
Jerome Moisand Jerome Moisand
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
USA USA
Phone: EMail: jmoisand@juniper.net
Fax:
Email: jmoisand@juniper.net
Thomas Haag Thomas Haag
Deutsche Telekom Deutsche Telekom
Heinrich-Hertz-Strasse 3-7 Heinrich-Hertz-Strasse 3-7
Darmstadt, 64295 Darmstadt 64295
Germany Germany
Phone: +49 6151 628 2088 EMail: haagt@telekom.de
Fax:
Email: haagt@telekom.de
Norbert Voigt Norbert Voigt
Nokia Siemens Networks Nokia Siemens Networks
Siemensallee 1 Siemensallee 1
Greifswald 17489 Greifswald 17489
Germany Germany
Email: norbert.voigt@nsn.com EMail: norbert.voigt@nsn.com
Tom Taylor (editor) Tom Taylor (editor)
Huawei Technologies Huawei Technologies
1852 Lorraine Ave
Ottawa Ottawa
Canada Canada
Email: tom111.taylor@bell.net EMail: tom111.taylor@bell.net
 End of changes. 438 change blocks. 
1006 lines changed or deleted 1007 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/