idnits 2.17.1 draft-ietf-ancp-protocol-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1003 has weird spacing: '...er Name set a...' == Line 1007 has weird spacing: '...er Port set a...' -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 26, 2011) is 4748 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'G.993.2' is mentioned on line 324, but not defined == Unused Reference: 'RFC3293' is defined on line 3572, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Wadhwa 3 Internet-Draft Alcatel-Lucent 4 Intended status: Standards Track J. Moisand 5 Expires: October 28, 2011 Juniper Networks 6 T. Haag 7 Deutsche Telekom 8 N. Voigt 9 Nokia Siemens Networks 10 T. Taylor, Ed. 11 Huawei Technologies 12 April 26, 2011 14 Protocol for Access Node Control Mechanism in Broadband Networks 15 draft-ietf-ancp-protocol-17 17 Abstract 19 This document describes the Access Node Control Protocol (ANCP). 20 ANCP operates between a Network Access Server (NAS) and an Access 21 Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in 22 a multi-service reference architecture in order to perform QoS- 23 related, service-related and subscriber-related operations. Use 24 cases for ANCP are documented in RFC 5851. As well as describing the 25 base ANCP protocol, this document specifies capabilities for Digital 26 Subscriber Line (DSL) topology discovery, line configuration, and 27 remote line connectivity testing. The design of ANCP allows for 28 protocol extensions in other documents if they are needed to support 29 other use cases and other access technologies. 31 ANCP is based on GSMPv3 (RFC 3292), but with many modifications and 32 extensions, to the point that the two protocols are not 33 interoperable. For this reason, ANCP was assigned a separate version 34 number to distinguish it. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on October 28, 2011. 53 Copyright Notice 55 Copyright (c) 2011 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 This document may contain material from IETF Documents or IETF 69 Contributions published or made publicly available before November 70 10, 2008. The person(s) controlling the copyright in some of this 71 material may not have granted the IETF Trust the right to allow 72 modifications of such material outside the IETF Standards Process. 73 Without obtaining an adequate license from the person(s) controlling 74 the copyright in such materials, this document may not be modified 75 outside the IETF Standards Process, and derivative works of it may 76 not be created outside the IETF Standards Process, except to format 77 it for publication as an RFC or to translate it into languages other 78 than English. 80 Table of Contents 82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 83 1.1. Historical Note . . . . . . . . . . . . . . . . . . . . . 7 84 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 7 85 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 86 2. Broadband Access Aggregation . . . . . . . . . . . . . . . . . 9 87 2.1. ATM-based Broadband Aggregation . . . . . . . . . . . . . 9 88 2.2. Ethernet-Based Broadband Aggregation . . . . . . . . . . . 10 89 3. Access Node Control Protocol -- General Aspects . . . . . . . 11 90 3.1. Protocol Version . . . . . . . . . . . . . . . . . . . . . 11 91 3.2. ANCP Transport . . . . . . . . . . . . . . . . . . . . . . 11 92 3.3. Encoding of Text Fields . . . . . . . . . . . . . . . . . 12 93 3.4. Treatment of Reserved and Unused Fields . . . . . . . . . 12 94 3.5. The ANCP Adjacency Protocol . . . . . . . . . . . . . . . 13 95 3.5.1. ANCP Adjacency Message Format . . . . . . . . . . . . 13 96 3.5.2. ANCP Adjacency Procedures . . . . . . . . . . . . . . 19 97 3.6. ANCP General Message Formats . . . . . . . . . . . . . . . 29 98 3.6.1. The ANCP Message Header . . . . . . . . . . . . . . . 30 99 3.6.2. The ANCP Message Body . . . . . . . . . . . . . . . . 36 100 3.7. General Principles for the Design of ANCP Messages . . . . 37 101 4. Generally Useful ANCP Messages and TLVs . . . . . . . . . . . 38 102 4.1. Provisioning Message . . . . . . . . . . . . . . . . . . . 38 103 4.2. Generic Response Message . . . . . . . . . . . . . . . . . 39 104 4.3. Target TLV . . . . . . . . . . . . . . . . . . . . . . . . 41 105 4.4. Command TLV . . . . . . . . . . . . . . . . . . . . . . . 42 106 4.5. Status-Info TLV . . . . . . . . . . . . . . . . . . . . . 42 107 5. Introduction To ANCP Capabilities For Digital Subscriber 108 Lines (DSL) . . . . . . . . . . . . . . . . . . . . . . . . . 44 109 5.1. DSL Access Line Identification . . . . . . . . . . . . . . 44 110 5.1.1. Control Context (Informative) . . . . . . . . . . . . 44 111 5.1.2. TLVs For DSL Access Line Identification . . . . . . . 46 112 6. ANCP Based DSL Topology Discovery . . . . . . . . . . . . . . 49 113 6.1. Control Context (Informative) . . . . . . . . . . . . . . 49 114 6.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 50 115 6.2.1. Protocol Requirements On the AN Side . . . . . . . . . 51 116 6.2.2. Protocol Requirements On the NAS Side . . . . . . . . 51 117 6.3. ANCP Port UP and Port DOWN Event Message Descriptions . . 51 118 6.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 53 119 6.4.1. Procedures On the AN Side . . . . . . . . . . . . . . 53 120 6.4.2. Procedures On the NAS Side . . . . . . . . . . . . . . 53 121 6.5. TLVs For DSL Line Attributes . . . . . . . . . . . . . . . 54 122 6.5.1. DSL-Line-Attributes TLV . . . . . . . . . . . . . . . 54 123 6.5.2. DSL-Type TLV . . . . . . . . . . . . . . . . . . . . . 54 124 6.5.3. Actual-Net-Data-Rate-Upstream TLV . . . . . . . . . . 55 125 6.5.4. Actual-Net-Data-Rate-Downstream TLV . . . . . . . . . 55 126 6.5.5. Minimum-Net-Data-Rate-Upstream TLV . . . . . . . . . . 55 127 6.5.6. Minimum-Net-Data-Rate-Downstream TLV . . . . . . . . . 56 128 6.5.7. Attainable-Net-Data-Rate-Upstream TLV . . . . . . . . 56 129 6.5.8. Attainable-Net-Data-Rate-Downstream TLV . . . . . . . 56 130 6.5.9. Maximum-Net-Data-Rate-Upstream TLV . . . . . . . . . . 56 131 6.5.10. Maximum-Net-Data-Rate-Downstream TLV . . . . . . . . . 56 132 6.5.11. Minimum-Net-Low-Power-Data-Rate-Upstream TLV . . . . . 57 133 6.5.12. Minimum-Net-Low-Power-Data-Rate-Downstream TLV . . . . 57 134 6.5.13. Maximum-Interleaving-Delay-Upstream TLV . . . . . . . 57 135 6.5.14. Actual-Interleaving-Delay-Upstream TLV . . . . . . . . 57 136 6.5.15. Maximum-Interleaving-Delay-Downstream TLV . . . . . . 58 137 6.5.16. Actual-Interleaving-Delay-Downstream . . . . . . . . . 58 138 6.5.17. DSL-Line-State TLV . . . . . . . . . . . . . . . . . . 58 139 6.5.18. Access-Loop-Encapsulation TLV . . . . . . . . . . . . 58 140 7. ANCP based DSL Line Configuration . . . . . . . . . . . . . . 60 141 7.1. Control Context (Informative) . . . . . . . . . . . . . . 60 142 7.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 61 143 7.2.1. Protocol Requirements On the NAS Side . . . . . . . . 61 144 7.2.2. Protocol Requirements On the AN Side . . . . . . . . . 61 145 7.3. ANCP Port Management (Line Configuration) Message 146 Format . . . . . . . . . . . . . . . . . . . . . . . . . . 62 147 7.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 64 148 7.4.1. Procedures On the NAS Side . . . . . . . . . . . . . . 64 149 7.4.2. Procedures On the AN Side . . . . . . . . . . . . . . 64 150 7.5. TLVs For DSL Line Configuration . . . . . . . . . . . . . 65 151 7.5.1. Service-Profile-Name TLV . . . . . . . . . . . . . . . 65 152 8. ANCP-Based DSL Remote Line Connectivity Testing . . . . . . . 65 153 8.1. Control Context (Informative) . . . . . . . . . . . . . . 65 154 8.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 66 155 8.2.1. Protocol Requirements On the NAS Side . . . . . . . . 66 156 8.2.2. Protocol Requirements On the AN Side . . . . . . . . . 66 157 8.3. Port Management (OAM) Message Format . . . . . . . . . . . 67 158 8.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 68 159 8.4.1. NAS-Side Procedures . . . . . . . . . . . . . . . . . 68 160 8.4.2. AN-Side Procedures . . . . . . . . . . . . . . . . . . 69 161 8.5. TLVs For the DSL Line Remote Connectivity Testing 162 Capability . . . . . . . . . . . . . . . . . . . . . . . . 70 163 8.5.1. OAM-Loopback-Test-Parameters TLV . . . . . . . . . . . 70 164 8.5.2. Opaque-Data TLV . . . . . . . . . . . . . . . . . . . 71 165 8.5.3. OAM-Loopback-Test-Response-String TLV . . . . . . . . 71 166 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71 167 9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 72 168 9.2. IANA Actions . . . . . . . . . . . . . . . . . . . . . . . 72 169 9.2.1. ANCP Message Type Registry . . . . . . . . . . . . . . 72 170 9.2.2. ANCP Result Code Registry . . . . . . . . . . . . . . 73 171 9.2.3. ANCP Port Management Function Registry . . . . . . . . 74 172 9.2.4. ANCP Technology Type Registry . . . . . . . . . . . . 75 173 9.2.5. ANCP Command Code Registry . . . . . . . . . . . . . . 75 174 9.2.6. ANCP TLV Type Registry . . . . . . . . . . . . . . . . 75 175 9.2.7. ANCP Capability Type Registry . . . . . . . . . . . . 77 176 9.2.8. Joint GSMP / ANCP Version Registry . . . . . . . . . . 77 177 10. Security Considerations . . . . . . . . . . . . . . . . . . . 78 178 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 79 179 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 79 180 12.1. Normative References . . . . . . . . . . . . . . . . . . . 79 181 12.2. Informative References . . . . . . . . . . . . . . . . . . 80 182 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 81 184 1. Introduction 186 This draft defines a new protocol, the Access Node Control Protocol 187 (ANCP), to realize a control plane between a service-oriented layer 3 188 edge device (the Network Access Server, NAS) and a layer 2 Access 189 Node (e.g., Digital Subscriber Line Access Module, DSLAM) in order to 190 perform operations related to quality of service (QoS), services, and 191 subscriptions. The requirements for ANCP and the context within 192 which it operates are described in [RFC5851]. 194 ANCP provides its services to control applications operating in the 195 AN and NAS respectively. This relationship is shown in Figure 1. 196 Specification of the control applications is beyond the scope of this 197 document, but informative partial descriptions are provided as 198 necessary to give a context for the operation of the protocol. 200 Access Node Network Access Server 201 +--------------------+ +--------------------+ 202 | +----------------+ | | +----------------+ | 203 | | AN Control | | | | NAS Control | | 204 | | Application | | | | Application | | 205 | +----------------+ | | +----------------+ | 206 | +----------------+ | | +----------------+ | 207 | | ANCP Agent | | ANCP Messages | | ANCP Agent | | 208 | | (AN side) |<----------------------->| (NAS side) | | 209 | +----------------+ | | +----------------+ | 210 +--------------------+ +--------------------+ 212 Figure 1: Architectural Context For the Access Node Control Protocol 214 At various points in this document, information flows between the 215 control applications and ANCP are described. The purpose of such 216 descriptions is to clarify the boundary between this specification 217 and, for example, [TR-147]. There is no intention to place limits on 218 the degree to which the control application and the protocol 219 implementation are integrated. 221 This specification specifies ANCP transport over TCP/IP. TCP 222 encapsulation for ANCP is as defined in Section 3.2. 224 The organization of this document is as follows: 226 o The next two sub-sections introduce some terminology that will be 227 useful in understanding the rest of the document. 229 o Section 2 provides a description of the access networks within 230 which ANCP will typically be deployed. 232 o Section 3 specifies generally applicable aspects of the ANCP 233 protocol. 235 o Section 4 specifies some messages and TLVs intended for use by 236 multiple capabilities spanning multiple technologies. 238 o Section 5 and the three following sections describe and specify 239 the ANCP implementation of three capabilities applicable to the 240 control of DSL access technology: topology discovery, line 241 configuration, and remote line connectivity testing. 243 o Section 9 is the IANA Considerations section. This section 244 defines a number of new ANCP-specific registries, as well as the 245 joint GSMP/ANCP version registry mentioned below. 247 o Section 10 addresses security considerations relating to ANCP, 248 beginning with the requirements stated in [RFC5713]. 250 1.1. Historical Note 252 Initial implementations of the protocol that became ANCP were based 253 on GSMPv3 [RFC3292]. The ANCP charter required the Working Group to 254 develop its protocol based on these implementations. In the end, 255 ANCP introduced so many extensions and modifications to GSMPv3 that 256 the two protocols are not interoperable. Nevertheless, although this 257 specification has no normative dependencies on [RFC3292], the mark of 258 ANCP's origins can be seen in the various unused fields within the 259 ANCP message header. 261 Early in ANCP's development the decision was made to use the same TCP 262 port and encapsulation as GSMPv3, and by the time ANCP was finished 263 it was too late to reverse that decision because of existing 264 implementations. As a result, it is necessary to have a way for an 265 ANCP peer to quickly distinguish ANCP from GSMP during initial 266 adjacency negotiations. This has been provided by a joint registry 267 of GSMP and ANCP version numbers. GSMP has version numbers 1 through 268 3. ANCP has the initial version number 50. 270 1.2. Requirements Language 272 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 273 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 274 document are to be interpreted as described in [RFC2119]. 276 1.3. Terminology 278 This section repeats some definitions from [RFC5851], but also adds 279 definitions for terms used only in this document. 281 Access Node (AN): [RFC5851] Network device, usually located at a 282 service provider central office or street cabinet that terminates 283 access (local) loop connections from subscribers. In case the 284 access loop is a Digital Subscriber Line (DSL), the Access Node 285 provides DSL signal termination, and is referred to as a DSL 286 Access Multiplexer (DSLAM). 288 Network Access Server (NAS): [RFC5851] Network element which 289 aggregates subscriber traffic from a number of Access Nodes. The 290 NAS is an enforcement point for policy management and IP QoS in 291 the access network. It is also referred to as a Broadband Network 292 Gateway (BNG) or Broadband Remote Access Server (BRAS). 294 Home Gateway (HGW): Network element that connects subscriber devices 295 to the Access Node and the access network. In the case of DSL, 296 the Home Gateway is a DSL network termination that may operate 297 either as a layer 2 bridge or as a layer 3 router. In the latter 298 case, such a device is also referred to as a Routing Gateway (RG). 300 ANCP agent: A logical entity that implements the ANCP protocol in 301 the Access Node (AN-side) or NAS (NAS-side). 303 Access Node control adjacency: (modified from [RFC5851]) the 304 relationship between the AN-side ANCP agent and the NAS-side ANCP 305 agent for the purpose of exchanging Access Node Control Protocol 306 messages. The adjacency may either be up or down, depending on 307 the result of the Access Node Control adjacency protocol 308 operation. 310 ANCP capability: A specific set of ANCP messages, message content, 311 and procedures required to implement a specific use case or set of 312 use cases. Some ANCP capabilities are applicable to just one 313 access technology while others are technology independent. The 314 capabilities applicable to a given ANCP adjacency are negotiated 315 during adjacency startup. 317 Type-Length-Value (TLV): a data structure consisting of a sixteen- 318 bit type field, a sixteen-bit length field, and a variable-length 319 value field padded to the nearest 32-bit word boundary, as 320 described in Section 3.6.2. The value field of a TLV can contain 321 other TLVs. An IANA registry is maintained for values of the ANCP 322 TLV Type field. 324 Net data rate: [RFC5851] defined by ITU-T G.993.2 [G.993.2], Section 325 3.39, i.e., the portion of the total data rate that can be used to 326 transmit user information (e.g., ATM cells or Ethernet frames). 327 It excludes overhead that pertains to the physical transmission 328 mechanism (e.g., trellis coding in the case of DSL). It includes 329 TPS-TC (Transport Protocol Specific - Transmission Convergence) 330 encapsulation; this is zero for ATM encapsulation, and non-zero 331 for 64/65 encapsulation. 333 Line rate: [RFC5851] defined by ITU-T G.993.2. It contains the 334 complete overhead including Reed-Solomon and trellis coding. 336 DSL multi-pair bonding: method for bonding (or aggregating) multiple 337 xDSL lines into a single bi-directional logical link, henceforth 338 referred to in this draft as "DSL bonded circuit". DSL "multi- 339 pair" bonding allows an operator to combine the data rates on two 340 or more copper pairs, and deliver the aggregate data rate to a 341 single customer. ITU-T recommendations G.998.1 and G.998.2 342 respectively describe ATM and Ethernet based multi-pair bonding. 344 2. Broadband Access Aggregation 346 2.1. ATM-based Broadband Aggregation 348 The end to end DSL network consists of network service provider (NSP) 349 and application service provider (ASP) networks, regional/access 350 network, and customer premises network. Figure 2 shows ATM broadband 351 access network components. 353 The regional/access network consists of the regional network, Network 354 Access Server (NAS), and the access network as shown in Figure 2. 355 Its primary function is to provide end-to-end transport between the 356 customer premises and the NSP or ASP. 358 The Access Node terminates the DSL signal. It may be in the form of 359 a DSLAM in the central office, or a remote DSLAM, or a Remote Access 360 Multiplexer (RAM). The Access Node is the first point in the network 361 where traffic on multiple DSL lines will be aggregated onto a single 362 network. 364 The NAS performs multiple functions in the network. The NAS is the 365 aggregation point for subscriber traffic. It provides aggregation 366 capabilities (e.g. IP, PPP, ATM) between the Regional/Access Network 367 and the NSP or ASP. These include traditional ATM-based offerings 368 and newer, more native IP-based services. This includes support for 369 Point-to-Point Protocol over ATM (PPPoA) and PPP over Ethernet 370 (PPPoE), as well as direct IP services encapsulated over an 371 appropriate layer 2 transport. 373 Beyond aggregation, the NAS is also the enforcement point for policy 374 management and IP QoS in the regional/access networks. To allow IP 375 QoS support over an existing non-IP-aware layer 2 access network 376 without using multiple layer 2 QoS classes, a mechanism based on 377 hierarchical scheduling is used. This mechanism, defined in 378 [TR-059], preserves IP QoS over the ATM network between the NAS and 379 the routing gateway (RG) at the edge of the subscriber network, by 380 carefully controlling downstream traffic in the NAS, so that 381 significant queuing and congestion does not occur further down the 382 ATM network. This is achieved by using a diffserv-aware hierarchical 383 scheduler in the NAS that will account for downstream trunk 384 bandwidths and DSL synchronization rates. 386 [RFC5851] provides detailed definitions of the functions of each 387 network element in the broadband reference architecture. 389 Access Customer 390 <--- Aggregation --> <------- Premises -------> 391 Network Network 393 +------------------+ +--------------------------+ 394 +---------+ +---+ | +-----+ +------+ | |+-----+ +---+ +---------+ | 395 NSP| | +-|NAS|-| |ATM |-|Access| --||DSL |-|HGW|-|Subscriber|| 396 ---+ Regional| | +---+ | +-----+ | Node | | ||Modem| +---+ |Devices || 397 |Broadband| | +---+ | +------+ | |+-----+ +----------+| 398 ASP|Network |-+-|NAS| +--------------|---+ +--------------------------+ 399 ---+ | | +---+ | +--------------------------+ 400 | | | +---+ | |+-----+ +---+ +----------+| 401 +---------+ +-|NAS| +-----|| DSL |-|HGW|-|Subscriber|| 402 +---+ ||Modem| +---+ |Devices || 403 |+-----+ +----------+| 404 +--------------------------+ 405 HGW : Home Gateway 406 NAS : Network Access Server 408 Figure 2: ATM Broadband Aggregation Topology 410 2.2. Ethernet-Based Broadband Aggregation 412 The Ethernet aggregation network architecture builds on the Ethernet 413 bridging/switching concepts defined in IEEE 802. The Ethernet 414 aggregation network provides traffic aggregation, class of service 415 distinction, and customer separation and traceability. VLAN tagging 416 defined in IEEE 802.1Q and being enhanced by IEEE 802.1ad is used as 417 standard virtualization mechanism in the Ethernet aggregation 418 network. The aggregation devices are "provider edge bridges" defined 419 in IEEE 802.ad. 421 Stacked VLAN tags provide one possible way to create equivalent of 422 "virtual paths" and "virtual circuits" in the aggregation network. 423 The "outer" vlan can be used to create a form of "virtual path" 424 between a given DSLAM and a given NAS. "Inner" VLAN tags create a 425 form of "virtual circuit" on a per DSL line basis. This is the 1:1 426 VLAN allocation model. An alternative model is to bridge sessions 427 from multiple subscribers behind a DSLAM into a single VLAN in the 428 aggregation network. This is the N:1 VLAN allocation model. Section 429 1.6 of [TR-101] provides brief definitions of these two models, while 430 section 2.5.1 describes them in more detail. 432 3. Access Node Control Protocol -- General Aspects 434 This section specifies aspects of the Access Node Control Protocol 435 (ANCP) that are generally applicable. 437 3.1. Protocol Version 439 ANCP messages contain an 8-bit protocol version field. For the 440 protocol version specified in this document, the value of that field 441 MUST be set to 50. 443 3.2. ANCP Transport 445 This document specifies the use of TCP / IPSec+IKEv2 / IP for 446 transport of ANCP messages. For further discussion of the use of 447 IPSec + IKEv2 see Section 10. The present section deals with the TCP 448 aspects. Other specifications may introduce additional transports in 449 the future. 451 In the case of ATM access, a separate PVC (control channel) 452 capable of transporting IP MAY be configured between NAS and the 453 AN for ANCP messages. 455 In the case of an Ethernet access/aggregation network, a typical 456 practice is to send the Access Node Control Protocol messages over 457 a dedicated Ethernet virtual LAN (VLAN) using a separate VLAN 458 identifier (VLAN ID). 460 When transported over TCP, ANCP messages MUST use an encapsulation 461 consisting of a four-byte header field prepended to the ANCP message 462 as shown in Figure 3. 464 0 1 2 3 465 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 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Identifier (0x880C) | Length | 468 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | | 470 ~ ANCP Message ~ 471 | | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 Figure 3: Encapsulation of ANCP Messages Over TCP/IP 476 The fields of the encapsulating header are as follows: 478 Identifier (16 bits): This identifies a GSMP or ANCP message. It 479 MUST be set to 0x880C. 481 Length (16 bits): Total length of the ANCP message in bytes, not 482 including the 4-byte encapsulating header. 484 The Access Node MUST initiate the TCP session to the NAS, using 485 destination port 6068. 487 This is necessary to avoid static address provisioning on the NAS 488 for all the ANs that are being served by the NAS. It is easier to 489 configure a given AN with the single IP address of the NAS that 490 serves the AN. 492 The NAS MUST listen on port 6068 for incoming connections from the 493 Access Nodes. 495 In the event of an ANCP transport protocol failure, all pending ANCP 496 messages destined to the disconnected recipient SHOULD be discarded 497 until the transport connection is re-established. 499 3.3. Encoding of Text Fields 501 In ANCP, all text fields use UTF-8 encoding [RFC3629]. Note that US 502 ASCII characters have the same representation when coded as UTF-8 as 503 they do when coded according to [US_ASCII]. 505 When extracting text fields from a message, the ANCP agent MUST NOT 506 assume that the fields are zero-terminated. 508 3.4. Treatment of Reserved and Unused Fields 510 ANCP messages contain a number of fields that are unused or reserved. 511 Some fields are always unused (typically because they were inherited 512 from GSMPv3 but are not useful in the ANCP context). Others are 513 reserved in the current specification, but are provided for 514 flexibility in future extensions to ANCP. Both reserved and unused 515 fields MUST be set to zeroes by the sender and MUST be ignored by the 516 receiver. 518 Unused bits in a flag field are shown in figures as 'x'. The above 519 requirement (sender set to zero, receiver ignore) applies to such 520 unused bits. 522 3.5. The ANCP Adjacency Protocol 524 ANCP uses the adjacency protocol to synchronize the NAS and Access 525 Nodes and maintain the ANCP session. After the TCP connection is 526 established, adjacency protocol messages MUST be exchanged as 527 specified in this section. ANCP messages other than adjacency 528 protocol messages MUST NOT be sent until the adjacency protocol has 529 achieved synchronization. 531 3.5.1. ANCP Adjacency Message Format 533 The ANCP adjacency message format is shown in Figure 4 below. 535 0 1 2 3 536 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 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Version | Message Type | Timer |M| Code | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Sender Name | 541 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | | | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 544 | Receiver Name | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Sender Port | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Receiver Port | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | PType | PFlag | Sender Instance | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Partition ID | Receiver Instance | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Reserved | # of Caps | Total Length | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | | 557 ~ Capability Fields ~ 558 | | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 Figure 4: ANCP Adjacency Message Format 563 The fields of the ANCP adjacency message are as follows: 565 Version (8 bits): ANCP version, which is subject to negotiation. 566 This is the key parameter by means of which ANCP messages can be 567 distinguished from GSMP messages received over the same port. 569 Message Type (8 bits): always has value 10 (adjacency protocol). 571 Timer (8 bits): The Timer field is used to negotiate the timer value 572 used in the adjacency protocol with the peer. The timer specifies 573 the nominal time between periodic adjacency protocol messages. It 574 is a constant for the duration of an ANCP session. The Timer 575 field is specified in units of 100ms, with a default value of 250 576 (i.e., 25 seconds). 578 M-flag (one bit): used in the SYN message to prevent the NAS from 579 synchronizing with another NAS, and the AN from synchronizing with 580 another AN. In the SYN message, always set to 1 by the NAS, and 581 to 0 by the AN. In other adjacency message types, always set to 0 582 by the sender and ignored by the receiver. 584 Code (7 bits): the adjacency protocol message type. It MUST have 585 one of the following values: 587 Code = 1: SYN; 589 Code = 2: SYNACK; 591 Code = 3: ACK; 593 Code = 4: RSTACK. 595 Sender Name (48 bits): For the SYN, SYNACK, and ACK messages, is the 596 identifier of the entity sending the message. The Sender Name is 597 a 48-bit quantity that is unique within the operational context of 598 the device. A 48-bit IEEE 802 MAC address, if available, may be 599 used for the Sender Name. If the Ethernet encapsulation is used 600 the Sender Name MUST be the Source Address from the MAC header. 601 For the RSTACK message, the Sender Name field is set to the value 602 of the Receiver Name field from the incoming message that caused 603 the RSTACK message to be generated. 605 Receiver Name (48 bits) for the SYN, SYNACK, and ACK messages, is 606 the name of the entity that the sender of the message believes is 607 at the far end of the link. If the sender of the message does not 608 know the name of the entity at the far end of the link, this field 609 SHOULD be set to zero. For the RSTACK message, the Receiver Name 610 field is set to the value of the Sender Name field from the 611 incoming message that caused the RSTACK message to be generated. 613 Sender Port (32 bits): For the SYN, SYNACK, and ACK messages, is the 614 local port number of the link across which the message is being 615 sent. For the RSTACK message, the Sender Port field is set to the 616 value of the Receiver Port field from the incoming message that 617 caused the RSTACK message to be generated. 619 Receiver Port (32 bits): For the SYN, SYNACK, and ACK messages, is 620 what the sender believes is the local port number for the link, 621 allocated by the entity at the far end of the link. If the sender 622 of the message does not know the port number at the far end of the 623 link, this field SHOULD be set to zero. For the RSTACK message, 624 the Receiver Port field is set to the value of the Sender Port 625 field from the incoming message that caused the RSTACK message to 626 be generated. 628 PType (4 bits): PType is used to specify if partitions are used and 629 how the Partition ID is negotiated. 631 Type of partition being requested: 633 0 - no partition; 635 1 - fixed partition request; 637 2 - fixed partition assigned. 639 PFlag (4 bits): used to indicate the type of partition request. 641 1 - new adjacency; 643 2 - recovered adjacency. 645 In case of a conflict between the peers' views of the value of 646 PFlag, the lower value is used. 648 Sender Instance (24 bits): For the SYN, SYNACK, and ACK messages, is 649 the sender's instance number for the link to the peer. It is used 650 to detect when the link comes back up after going down or when the 651 identity of the entity at the other end of the link changes. The 652 instance number is a 24-bit number that is guaranteed to be unique 653 within the recent past and to change when the link or node comes 654 back up after going down. Zero is not a valid instance number. 655 For the RSTACK message, the Sender Instance field is set to the 656 value of the Receiver Instance field from the incoming message 657 that caused the RSTACK message to be generated. 659 Partition ID (8 bits): field used to associate the message with a 660 specific partition of the AN. The value of this field is 661 negotiated during the adjacency procedure. The AN makes the final 662 decision, but will consider a request from the NAS. If the AN 663 does not support partitions, the value of this field MUST be 0. 664 Otherwise, it MUST be non-zero. 666 Receiver Instance (24 bits): For the SYN, SYNACK, and ACK messages, 667 is what the sender believes is the current instance number for the 668 link, allocated by the entity at the far end of the link. If the 669 sender of the message does not know the current instance number at 670 the far end of the link, this field SHOULD be set to zero. For 671 the RSTACK message, the Receiver Instance field is set to the 672 value of the Sender Instance field from the incoming message that 673 caused the RSTACK message to be generated. 675 Reserved (8 bits): reserved for use by a future version of this 676 specification. 678 # of Caps: indicates the number of capability fields that follow. 680 Total Length: indicates the total number of bytes occupied by the 681 capability fields that follow. 683 Capability Fields: Each capability field indicates one ANCP 684 capability supported by the sender of the adjacency message. 685 Negotiation of a common set of capabilities to be supported within 686 the ANCP session is described below. The detailed format of a 687 capability field is shown in Figure 5 and described below. 689 0 1 2 3 690 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 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | Capability Type | Capability Length | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | | 695 ~ ~ 696 ~ Capability Data ~ 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 Figure 5: Capability Field 701 The sub-fields of this structure are as follows: 703 Capability Type: indicates the specific capability supported. An 704 IANA registry exists for values of this sub-field. The values 705 specified by this document are listed below. 707 Capability Length: the number of bytes of data contained in the 708 Capability Data sub-field, excluding padding. If the definition 709 of a particular capability includes no capability data, the value 710 of the Capability Length sub-field is zero. 712 Capability Data: contains data associated with the capability as 713 specified for that capability. If the definition of a particular 714 capability includes no capability data, the Capability Data sub- 715 field is absent (has zero length). Otherwise, the Capability Data 716 sub-field MUST be padded with zeroes as required to terminate on a 717 4-byte word boundary. The possibility of specifying capability 718 data provides the flexibility to advertise more than the mere 719 presence or absence of a capability if needed. 721 The following capabilities are defined for ANCP as applied to DSL 722 access: 724 o Capability Type : DSL Topology Discovery = 0x01 726 Access technology: DSL 728 Length (in bytes) : 0 730 Capability Data : NULL 732 For the detailed protocol specification of this capability see 733 Section 6. 735 o Capability Type : DSL Line Configuration = 0x02 737 Access technology: DSL 739 Length (in bytes) : 0 741 Capability Data : NULL 743 For the detailed protocol specification of this capability see 744 Section 7. 746 o Capability Type : DSL Remote Line Connectivity Testing = 0x04 748 Access technology: DSL 750 Length (in bytes) : 0 752 Capability Data : NULL 754 For the detailed protocol specification of this capability see 755 Section 8. 757 In addition to the adjacency messages whose format is shown in 758 Figure 6, ANCP adjacency procedures use the Adjacency Update message 759 (Figure 6) to inform other NASs controlling the same AN partition 760 when a particular NAS joins or loses an adjacency with that 761 partition. 763 0 1 2 3 764 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 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Version | Message Type | Result| Code | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | Partition ID | Transaction Identifier | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 |I| SubMessage Number | Length | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 Figure 6: The Adjacency Update Message 775 The Adjacency Update message is identical to the general ANCP message 776 header described in Section 3.6, but the field settings are in part 777 specific to the Adjacency Update message. The fields in this message 778 are as follows: 780 Version (8 bits): the ANCP version negotiated and running in this 781 adjacency. 783 Message Type (8 bits): always 85. 785 Result (4 bits): set to Ignore (0). 787 Code (12 bits): set to the total number of adjacencies currently 788 established on this partition, from the point of view of the AN. 790 Partition ID (8 bits): the partition identifier of the partition for 791 which this notification is being sent. 793 Transaction Identifier (24 bits): MUST be set to 0. 795 I (1 bit), SubMessage number (15 bits): set as described in 796 Section 3.6.1.7. 798 Length (16 bits): set as described in Section 3.6.1.8. 800 3.5.2. ANCP Adjacency Procedures 802 3.5.2.1. Overview 804 The ANCP adjacency protocol operates symmetrically between the NAS 805 and the AN. In the absence of errors or race conditions, each peer 806 sends a SYN message, receives a SYNACK message in acknowledgement, 807 and completes the establishment of the adjacency by sending an ACK 808 message. Through this exchange, each peer learns the values of the 809 Name, Port, and Instance parameters identifying the other peer, and 810 the two peers negotiate the values of the Version, Timer, PFlag, and 811 Partition ID parameters and the set of capabilities that the 812 adjacency will support. 814 Once the adjacency has been established, its liveness is periodically 815 tested. The peers engage in an ACK message exchange at a frequency 816 determined by the negotiated value of the Timer field. 818 If an inconsistency, loss of contact, or protocol violation is 819 detected, the detecting peer can force a restart of the 820 synchronization process by sending an RSTACK message to the other 821 end. 823 Once an adjacency has been established, if more than one NAS has 824 established an adjacency to the same partition, then the AN sends an 825 Adjacency Update message to each such NAS to let it know how many 826 established adjacencies the partition currently supports. Similarly, 827 if an adjacency is lost, the AN sends an Adjacency Update message to 828 each of the remaining adjacent NASs to let them know about the change 829 in status. 831 3.5.2.2. Adjacency Protocol State Machine 833 The adjacency protocol is described by the following rules and state 834 tables. It begins with the sending of a SYN by each end as soon as 835 the transport connection has been established. If at any point the 836 operations A, B, C, or "Verify Adjacent State" defined below detect a 837 mismatch, a log SHOULD be generated, identifying the fields concerned 838 and the expected and received values for each. 840 The rules and state tables use the following operations: 842 o The "Record Adjacency State" operation is defined in 843 Section 3.5.2.3.2. 845 o The "Verify Adjacency State" operation consists of verifying that 846 the contents of the incoming SYNACK message match the adjacency 847 state values previously recorded. 849 o The procedure "Reset the link" is defined as: 851 1. Generate a new instance number for the link. 853 2. Delete the peer verifier (set to zero the values of Sender 854 Instance, Sender Port, and Sender Name previously stored by 855 the Record Adjacency State operation). 857 3. Send a SYN message(Section 3.5.2.3.1). 859 4. Enter the SYNSENT state. 861 o The state tables use the following Boolean terms and operators. 863 A. The Sender Instance in the incoming message matches the value 864 stored from a previous message by the "Record Adjacency State" 865 operation. 867 B. The Sender Instance, Sender Port, Sender Name and Partition ID 868 fields in the incoming message match the values stored from a 869 previous message by the "Record Adjacency State" operation. 871 C. The Receiver Instance, Receiver Port, Receiver Name and 872 Partition ID fields in the incoming message match the values 873 of the Sender Instance, Sender Port, Sender Name and Partition 874 ID currently sent in outgoing SYN, SYNACK, and ACK messages, 875 except that the NAS always accepts the Partition ID value 876 presented to it in a SYN or SYNACK message. 878 "&&" Represents the logical AND operation. 880 "||" Represents the logical OR operation. 882 "!" Represents the logical negation (NOT) operation. 884 o A timer is required for the periodic generation of SYN, SYNACK, 885 and ACK messages. The value of the timer is negotiated in the 886 Timer field. The period of the timer is unspecified but a value 887 of 25 seconds is suggested. Note that since ANCP uses a reliable 888 transport protocol, the timer is unlikely to expire in any state 889 other than ESTAB. 891 There are two independent events: the timer expires, and a packet 892 arrives. The processing rules for these events are: 894 Timer Expires: Reset Timer 896 If state = SYNSENT Send SYN 898 If state = SYNRCVD Send SYNACK 900 If state = ESTAB Send ACK 902 Packet Arrives: 904 If incoming message is an RSTACK: 906 If (A && C && !SYNSENT) Reset the link 908 Else discard the message. 910 If incoming message is a SYN, SYNACK, or ACK: 912 Response defined by the following State Tables. 914 If incoming message is any other ANCP message and state != 915 ESTAB: 917 Discard incoming message. 919 If state = SYNSENT Send SYN (Note 1) 921 If state = SYNRCVD Send SYNACK (Note 1) 923 Note 1: No more than two SYN or SYNACK messages should be sent 924 within any time period of length defined by the timer. 926 o State synchronisation across a link is considered to be achieved 927 when the protocol reaches the ESTAB state. All ANCP messages, 928 other than adjacency protocol messages, that are received before 929 synchronisation is achieved will be discarded. 931 3.5.2.2.1. State Tables 933 State: SYNSENT 935 +====================================================================+ 936 | Condition | Action | New State | 937 +==================+=====================================+===========+ 938 | SYNACK && C | Update Peer Verifier; Send ACK | ESTAB | 939 +------------------+-------------------------------------+-----------+ 940 | SYNACK && !C | Send RSTACK | SYNSENT | 941 +------------------+-------------------------------------+-----------+ 942 | SYN | Update Peer Verifier; Send SYNACK | SYNRCVD | 943 +------------------+-------------------------------------+-----------+ 944 | ACK | Send RSTACK | SYNSENT | 945 +====================================================================+ 946 State: SYNRCVD 948 +====================================================================+ 949 | Condition | Action | New State | 950 +==================+=====================================+===========+ 951 | SYNACK && C | Verify Adjacency State; Send ACK | ESTAB | 952 +------------------+-------------------------------------+-----------+ 953 | SYNACK && !C | Send RSTACK | SYNRCVD | 954 +------------------+-------------------------------------+-----------+ 955 | SYN | Record Adjacency State; Send SYNACK | SYNRCVD | 956 +------------------+-------------------------------------+-----------+ 957 | ACK && B && C | Send ACK | ESTAB | 958 +------------------+-------------------------------------+-----------+ 959 | ACK && !(B && C) | Send RSTACK | SYNRCVD | 960 +====================================================================+ 962 State: ESTAB 964 +====================================================================+ 965 | Condition | Action | New State | 966 +==================+=====================================+===========+ 967 | SYN || SYNACK | Send ACK (note 2) | ESTAB | 968 +------------------+-------------------------------------+-----------+ 969 | ACK && B && C | Send ACK (note 3) | ESTAB | 970 +------------------+-------------------------------------+-----------+ 971 | ACK && !(B && C) | Send RSTACK | ESTAB | 972 +====================================================================+ 974 Note 2: No more than two ACKs should be sent within any time period 975 of length defined by the timer. Thus, one ACK MUST be sent every 976 time the timer expires. In addition, one further ACK may be sent 977 between timer expirations if the incoming message is a SYN or SYNACK. 978 This additional ACK allows the adjacency protocol to reach 979 synchronisation more quickly. 981 Note 3: No more than one ACK should be sent within any time period of 982 length defined by the timer. 984 3.5.2.3. The Adjacency Protocol SYN Message 986 3.5.2.3.1. Action By the Sender 988 The SYN message is sent in accordance with the state tables just 989 described. The sender sets the individual fields as follows: 991 Version: SHOULD be set to the highest version of ANCP that the 992 sender supports. 994 Message Type: MUST be set to 10. 996 Timer: SHOULD be set to the value configured in the AN or NAS 997 sending the message. 999 M Flag MUST be set to 1 by the NAS, and 0 by the AN. 1001 Code: MUST be set to 1 (SYN). 1003 Sender Name set as described in Section 3.5.1. 1005 Receiver Name: SHOULD be set to 0. 1007 Sender Port set as described in Section 3.5.1. 1009 Receiver Port: SHOULD be set to 0. 1011 PType: set according to the following rules: 1013 Settings by the AN: 1015 0 - the AN does not support partitions; 1017 2 - the value of Partition ID contained in this message is 1018 assigned to the current partition. 1020 Settings by the NAS: 1022 0 - the NAS leaves the decision on partitioning to the AN 1023 (RECOMMENDED setting); 1025 1 - the NAS requests that the AN use the value of Partition 1026 ID contained in this message for the current partition. The 1027 NAS MAY use this setting even if it has already received a 1028 SYN message from the AN, provided that the AN has indicated 1029 support for partitions. The NAS MUST be prepared to use 1030 whatever value it receives in a subsequent SYN or SYNACK 1031 message, even if this differs from the requested value. 1033 PFlag: set to the mode of adjacency setup (new adjacency vs. 1034 recovered adjacency) requested by the sender. Warning: setting 1035 PFlag=1 runs the risk of state mismatch because ANCP does not 1036 provide the means for the NAS to audit the current state of the 1037 AN. 1039 Sender Instance: set as described in Section 3.5.1. 1041 Partition ID: MUST be set to 0 if PType=0, otherwise set to the 1042 assigned or requested partition identifier value. 1044 Receiver Instance: SHOULD be set to 0. 1046 # of Caps: MUST be set to the number of Capability fields that 1047 follow. 1049 Total Length: MUST be set to the total number of bytes in the 1050 Capability fields that follow. 1052 Capability Fields: one Capability field MUST be present for each 1053 ANCP capability for which the sender wishes to advertise support. 1055 3.5.2.3.2. Action By the Receiver 1057 Upon receiving a validly-formed SYN message, the receiver first 1058 checks the value of the Version field. If this value is not within 1059 the range of ANCP versions that the receiver supports, the message 1060 MUST be silently ignored. Similarly, the message is silently ignored 1061 if the M-flag is 0 and the receiver is an AN, or if the M-flag is 1 1062 and the receiver is a NAS. If these checks are passed and the 1063 receiver is in ESTAB state, it returns an ACK (as indicated by the 1064 ESTAB state table in Section 3.5.2.2.1). The contents of the ACK 1065 MUST reflect the adjacency state as previously recorded by the 1066 receiver. 1068 Otherwise, the receiver MUST record the adjacency state as follows: 1070 Version: the supported Version value received in the SYN message. 1071 This value MUST be used for all subsequent ANCP messages sent 1072 during the life of the adjacency. 1074 Timer: the larger of the Timer value received in the SYN message and 1075 the value with which the receiver is configured. 1077 Sender Name: the value of the Sender Name field in the SYN message 1078 just received. 1080 Receiver Name: the value used by the receiver in the Sender Name 1081 field of SYN, SYNACK, and ACK messages it sends in this adjacency. 1083 Sender Port: the value of the Sender Port field in the SYN message 1084 just received. 1086 Receiver Port: the value used by the receiver in the Sender Port 1087 field of SYN, SYNACK, and ACK messages it sends in this adjacency. 1089 Sender Instance: the value of the Sender Instance field in the SYN 1090 message just received. 1092 PFlag: the lesser of the value determined by local policy and the 1093 value received in the SYN message. That is, preference is given 1094 to "0 - New adjacency" if there is a conflict. 1096 Partition ID: if the SYN receiver is the AN, this is set to 0 if the 1097 AN does not support partitions, or to the non-zero value of the 1098 partition identifier it chooses to assign otherwise. If the SYN 1099 receiver is the NAS, this is set to the value of the Partition ID 1100 field copied from the SYN. 1102 Receiver Instance: the value used by the receiver in the Sender 1103 Instance field of SYN, SYNACK, and ACK messages it sends in this 1104 adjacency. 1106 Capabilities: the set of ANCP capabilities that were offered in the 1107 SYN and are supported by the receiver. 1109 3.5.2.4. The Adjacency Protocol SYNACK Message 1111 3.5.2.4.1. Action By the Sender 1113 The SYNACK is sent in response to a successfully received SYN 1114 message, as indicated by the state tables. The Version, Timer, 1115 PFlag, and Partition ID fields MUST be populated with the values 1116 recorded as part of adjacency state. The # of Caps, Total Length, 1117 and Capability fields MUST also be populated in accordance with the 1118 Capabilities recorded as part of adjacency state. The remaining 1119 fields of the SYNACK message MUST be populated as follows: 1121 Message Type: MUST be 10. 1123 M-flag: MUST be set to 0. 1125 Code: MUST be 2 (SYNACK). 1127 PType: MUST be 0 if the Partition ID value is 0, or 2 if the 1128 Partition ID value is non-zero. 1130 Sender Name: MUST be set to the Receiver Name value recorded as part 1131 of adjacency state. 1133 Receiver Name: MUST be set to the Sender Name value recorded as part 1134 of adjacency state. 1136 Sender Port: MUST be set to the Receiver Port value recorded as part 1137 of adjacency state. 1139 Receiver Port: MUST be set to the Sender Port value recorded as part 1140 of adjacency state. 1142 Sender Instance: MUST be set to the Receiver Instance value recorded 1143 as part of adjacency state. 1145 Receiver Instance: MUST be set to the Sender Instance value recorded 1146 as part of adjacency state. 1148 If the set of capabilities recorded in the adjacency state is empty, 1149 then after sending the SYNACK the sender MUST raise an alarm to 1150 management, halt the adjacency procedure, and tear down the TCP 1151 session if it is not being used by another adjacency. The sender MAY 1152 also terminate the IPSec security association if no other adjacency 1153 is using it. 1155 3.5.2.4.2. Action By the Receiver 1157 As indicated by the state tables, the receiver of a SYNACK first 1158 checks that the Receiver Name, Receiver Port, and Receiver Instance 1159 values match the Sender Name, Sender Port, and Sender Instance values 1160 it sent in SYN message that is being acknowledged. The AN also 1161 checks that the PType and Partition ID match. If any of these checks 1162 fail, the receiver sends an RSTACK as described in Section 3.5.2.6.1. 1164 The receiver next checks whether the set of capabilities provided in 1165 the SYNACK is empty. If so, the receiver MUST raise an alarm to 1166 management and halt the adjacency procedure. 1168 Assuming that the SYNACK passes these checks, two cases arise. The 1169 first possibility is that the receiver has already recorded adjacency 1170 state. This will occur if the SYNACK is received while the receiver 1171 is in SYNRCVD state. In this case, the Version, Timer, Sender Name, 1172 Sender Port, Sender Instance, PFlag, and capability-related fields in 1173 the SYNACK MUST match those recorded as part of adjacency state. If 1174 a mismatch is detected, the receiver sends an RSTACK. This is the 1175 "Verify Adjacency State" procedure shown in the SYNRCVD state table. 1177 If, on the other hand, the SYNACK is received while the receiver is 1178 in SYNSENT state, the receiver MUST record session state as described 1179 in Section 3.5.2.3.2. 1181 In either case, if the receiver is the NAS, it MUST accept the 1182 Partition ID value provided in the SYNACK, updating its recorded 1183 adjacency state if necessary. 1185 3.5.2.5. The Adjacency Protocol ACK Message 1187 3.5.2.5.1. Actions By the Sender 1189 As indicated by the state tables, the ACK message is sent in a number 1190 of different circumstances. The main-line usages are as a response 1191 to SYNACK, leading directly to the ESTAB state, and as a periodic 1192 test of liveness once the ESTAB state has been reached. 1194 The sender MUST populate the ACK from recorded adjacency state, 1195 exactly as described in Section 3.5.2.4.1. The only difference is 1196 that Code MUST be set to 3 (ACK). 1198 3.5.2.5.2. Actions By the Receiver 1200 The required actions by the receiver are specified by the state 1201 tables. In addition to the checks B and C, the receiver SHOULD 1202 verify that the remaining contents of the ACK match the recorded 1203 adjacency state at the receiver. If that check fails the receiver 1204 MUST send an RSTACK as described in Section 3.5.2.6.1. 1206 Once the adjacency has been established, either peer can initiate the 1207 ACK exchange that tests for liveness. To meet the restrictions on 1208 ACK frequency laid down in the notes to the state tables, it is 1209 desirable that only one such exchange occur during any one interval. 1210 Hence if a peer receives an ACK when in ESTAB state, it MUST reply to 1211 that ACK as directed by the state tables, but SHOULD NOT initiate 1212 another ACK exchange in the same interval. To meet this objective, 1213 the receiver MUST reset its timer when it receives an ACK while in 1214 ESTAB state. 1216 It is, of course, possible that two exchanges happen because of 1217 race conditions. 1219 3.5.2.6. The Adjacency Protocol RSTACK Message 1221 3.5.2.6.1. Action By the Sender 1223 The RSTACK is sent in response to various error conditions as 1224 indicated by the state tables. In general it leads to a restart of 1225 adjacency negotiations (although this takes a few steps when the 1226 original sender of the RSTACK is in ESTAB state). 1228 As indicated in Section 3.5.1, the Sender Name, Port, and Instance 1229 fields in the RSTACK MUST be copied from the Receiver, Name, Port, 1230 and Instance fields in the message that caused the RSTACK to be sent. 1231 Similarly, the Receiver identifier fields in the RSTACK MUST be 1232 copied from the corresponding Sender identifier fields in the message 1233 that triggered the RSTACK. 1235 If the sender has recorded adjacency state, the Version, Timer, 1236 PType, PFlag, Partition ID, and capability-related fields SHOULD be 1237 set based on the recorded adjacency state. Otherwise they SHOULD be 1238 the same as the sender would send in a SYN message. The Message Type 1239 MUST be 10, the M-flag MUST be 0, and Code MUST be 4 (RSTACK). 1241 3.5.2.6.2. Action By the Receiver 1243 The receiver of an RSTACK MAY attempt to diagnose the problem which 1244 caused the RSTACK to be generated by comparing its own adjacency 1245 state with the contents of the RSTACK. However, the primary purpose 1246 of the RSTACK is to trigger action as prescribed by Section 3.5.2.2. 1248 3.5.2.7. Loss of Synchronization 1250 Loss of synchronisation MAY be declared if after synchronisation is 1251 achieved: 1253 o no valid ANCP messages are received in any period of time in 1254 excess of three times the value of the Timer field negotiated in 1255 the adjacency protocol messages, or 1257 o a mismatch in adjacency state is detected. 1259 In either case the peer detecting the condition MUST send an RSTACK 1260 to the other peer as directed in Section 3.5.2.6.1, in order to 1261 initiate resynchronization. 1263 While re-establishing synchronisation with a controller, a switch 1264 SHOULD maintain its connection state, deferring the decision about 1265 resetting the state until after synchronisation is re-established. 1266 Once synchronisation is re-established the decision about resetting 1267 the connection state SHOULD be made based on the negotiated value of 1268 PFlag. 1270 3.6. ANCP General Message Formats 1272 This section describes the general format of ANCP messages other than 1273 the adjacency messages. See Figure 7 1274 0 1 2 3 1275 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 1276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 | Version | Message Type | Result| Result Code | 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 | Partition ID | Transaction Identifier | 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 |I| SubMessage Number | Length | 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1283 | | 1284 ~ Message Payload ~ 1285 | | 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1288 Figure 7: ANCP General Message Format 1290 3.6.1. The ANCP Message Header 1292 A complete explanation of the ANCP general message header fields 1293 follows. 1295 3.6.1.1. Version Field (8 bits) 1297 This field carries the version of the ANCP protocol that was agreed 1298 for the session during adjacency negotiation. 1300 3.6.1.2. Message Type Field (8 bits) 1302 This field indicates the ANCP message type. Message type values are 1303 registered in an IANA registry. 1305 3.6.1.3. Result Field (4 bits) 1307 In request messages, the Result field indicates the circumstances 1308 under which a response is required. ANCP specifies what Result value 1309 each request message type should have. In responses the Result field 1310 indicates either Success (0x3) or Failure (0x4) as the case may be. 1312 Ignore: Res = 0x0 - Treat this field as a "no operation" and follow 1313 the response procedures specified for the received message type. 1315 Nack: Res = 0x1 - Result value indicating that a response is 1316 expected to the request only in cases of failure caused during the 1317 processing of the message contents or of the contained 1318 directive(s). 1320 AckAll: Res = 0x2 - Result value indicating that a response to the 1321 message is requested in all cases. 1323 Success: Res = 0x3 - Result value indicating that this is a response 1324 and that the request was executed successfully. The Result Code 1325 field for a successful result is typically 0, but MAY take on 1326 other values as specified for particular message types. 1328 Failure: Res = 0x4 - Result value indicating that this is a response 1329 and that the request was not executed successfully. The receiver 1330 of the response SHOULD take further action as indicated by the 1331 Result Code value and any diagnostic data contained in a Status- 1332 Info TLV included in the response. 1334 3.6.1.4. Result Code Field (12 bits) 1336 This field gives further information concerning the result in a 1337 response message. It is mostly used to pass an error code in a 1338 failure response but can also be used to give further information in 1339 a success response message or an event message. In a request 1340 message, the Result Code field is not used and MUST be set to 0x0 (No 1341 result). 1343 A number of Result Code values are specified below. Specification of 1344 additional Result Code values in extensions or updates to this 1345 document MUST include the following information: 1347 o Result Code value; 1349 o One-line description; 1351 o Where condition detected: (control application or ANCP agent); 1353 o Further description (if any); 1355 o Required additional information in the response message; 1357 o Target (control application or ANCP agent at the peer that sent 1358 the original request); 1360 o Action RECOMMENDED for the receiving ANCP agent 1362 In addition to any suggested action in the text which follows, a 1363 count of the number of times a given non-zero Result Code value was 1364 received SHOULD be provided for management. Where an action includes 1365 resending of a request, a given request SHOULD NOT be re-sent more 1366 than once. 1368 This document specifies the following Result Code values. 1370 Result Code value: 0x2 1372 * One-line description: Invalid request message 1374 * Where condition detected: ANCP agent 1376 * Further description: The request was a properly formed message 1377 which violates the protocol through its timing or direction of 1378 transmission. The most likely reason for this outcome in the 1379 field will be a race condition. 1381 * Required additional information in the response message: none, 1382 if the response message is of the same type as the request. As 1383 specified in Section 4.2 if the response message is a Generic 1384 Response message. 1386 * Target: ANCP agent at the peer that sent the original request 1388 * Action RECOMMENDED for the receiving ANCP agent: The original 1389 request MAY be re-sent once only after a short delay. Inform 1390 the control application with appropriate identification of the 1391 failed transaction if the second attempt fails or no second 1392 attempt is made. 1394 Result Code value: 0x6 1396 * One-line description: One or more of the specified ports are 1397 down 1399 * Where condition detected: control application 1401 * Further description (if any): This Result Code value indicates 1402 a state mismatch between the NAS and AN control applications, 1403 possibly due to a race condition. 1405 * Required additional information in the response message: if the 1406 request identified multiple access lines or the response is a 1407 Generic Response message, then the response MUST contain a 1408 Status-Info TLV encapsulating TLV(s) containing the line 1409 identifier(s) of the access lines that are not operational. 1411 * Target: control application at the peer that sent the original 1412 request 1414 * Action RECOMMENDED for the receiving ANCP agent: indicate the 1415 error and forward the line identifier(s) to the control 1416 application. 1418 Result Code value: 0x13 1420 * One-line description: Out of resources 1422 * Where condition detected: ANCP protocol layer or control 1423 application 1425 * Further description: (e.g., memory exhausted, etc.). This 1426 Result Code value MUST be reported only by the AN, and 1427 indicates a condition that is probably unrelated to specific 1428 access lines (although it may be related to the specific 1429 request). 1431 * Required additional information in the response message: none, 1432 if the response message is of the same type as the request. As 1433 specified in Section 4.2 if the response message is a Generic 1434 Response message. 1436 * Target: ANCP agent at the peer that sent the original request 1438 * Action RECOMMENDED for the receiving ANCP agent: If the NAS 1439 receives this Result Code value from multiple requests for the 1440 same AN in a short interval, it SHOULD reduce the rate at which 1441 it sends requests in proportion to the rate at which requests 1442 are failing with Result Code = 19. It MAY retry individual 1443 requests. If only a specific request is failing with Result 1444 Code = 19, the ANCP agent in the NAS MAY request the control 1445 application to decompose the request into simpler components if 1446 this is possible. 1448 Result Code value: 0x51 1450 * One-line description: Request message type not implemented 1452 * Where condition detected: ANCP agent 1454 * Further description: This could indicate a mismatch in protocol 1455 version or capability state. It is also possible that support 1456 of a specific message is optional within some ANCP capability. 1458 * Required additional information in the response message: none, 1459 if the response message is of the same type as the request. As 1460 specified in Section 4.2 if the response message is a Generic 1461 Response message. 1463 * Target: ANCP agent at the peer that sent the original request 1465 * Action RECOMMENDED for the receiving ANCP agent: If the 1466 receiver of this Result Code value expects that support of the 1467 message type concerned is mandatory according to the 1468 capabilities negotiated for the session, it MAY re-send the 1469 message in case the message was corrupted in transit the first 1470 time. If that fails, and use of the message type cannot be 1471 avoided, the ANCP agent MAY reset the adjacency by sending an 1472 RSTACK adjacency message (Section 3.5.2.6.1) where PType is set 1473 to 0 and Sender and Receiver Name, Port, and Instance are taken 1474 from recorded adjacency state. If a reset does not eliminate 1475 the problem, the receiving ANCP agent SHOULD raise an alarm to 1476 management and then cease to operate. 1478 Result Code value: 0x53 1480 * One-line description: Malformed message 1482 * Where condition detected: ANCP agent 1484 * Further description: This could be the result of corruption in 1485 transit, or an error in implementation at one end or the other. 1487 * Required additional information in the response message: none, 1488 if the response message is of the same type as the request. As 1489 specified in Section 4.2 if the response message is a Generic 1490 Response message. 1492 * Target: ANCP agent at the peer that sent the original request 1494 * Action RECOMMENDED for the receiving ANCP agent: The request 1495 SHOULD be re-sent once to eliminate the possibility of in- 1496 transit corruption. 1498 Result Code value: 0x54 1500 * One-line description: Mandatory TLV missing 1502 * Where condition detected: ANCP agent 1504 * Further description: none. 1506 * Required additional information in the response message: the 1507 response message MUST contain a Status-Info message that 1508 encapsulates an instance of each missing mandatory TLV, where 1509 the length is set to zero and the value field is empty (i.e., 1510 only the four-byte TLV header is present). 1512 * Target: ANCP agent at the peer that sent the original request 1514 * Action RECOMMENDED for the receiving ANCP agent: resend the 1515 message with the missing TLV(s), if possible. Otherwise, 1516 report the error to the control application with an indication 1517 of the missing information required to construct the missing 1518 TLV(s). 1520 Result Code value: 0x55 1522 * One-line description: Invalid TLV contents 1524 * Where condition detected: ANCP agent 1526 * Further description: the contents of one or more TLVs in the 1527 request do not match the specifications provided for the those 1528 TLVs. 1530 * Required additional information in the response message: the 1531 response MUST contain a Status-Info TLV encapsulating the 1532 erroneous TLVs copied from the original request. 1534 * Target: ANCP agent at the peer that sent the original request 1536 * Action RECOMMENDED for the receiving ANCP agent: correct the 1537 error and resend the request, if possible. Otherwise, report 1538 the error to the control application with an indication of the 1539 erroneous information associated with the invalid TLV(s). 1541 Result Code value: 0x500 1543 * One-line description: One or more of the specified ports do not 1544 exist 1546 * Where condition detected: control application 1548 * Further description (if any): this may indicate a configuration 1549 mismatch between the AN and the NAS or AAA. 1551 * Required additional information in the response message: if the 1552 request identified multiple access lines or the response is a 1553 Generic Response message, then the response MUST contain a 1554 Status-Info TLV encapsulating TLV(s) containing the rejected 1555 line identifier(s). 1557 * Target: control application at the peer that sent the original 1558 request 1560 * Action RECOMMENDED for the receiving ANCP agent: indicate the 1561 error and forward the line identifiers to the control 1562 application. 1564 3.6.1.5. Partition ID (8 bits) 1566 The Partition ID field MUST contain the value that was negotiated for 1567 Partition ID during the adjacency procedure as described above. 1569 3.6.1.6. Transaction ID (24 bits) 1571 The Transaction ID is set by the sender of a request message to 1572 associate a response message with the original request message. 1573 Unless otherwise specified for a given message type, the Transaction 1574 ID in request messages MUST be set to a value in the range (1, 2^24 - 1575 1). When used in this manner, the Transaction ID sequencing MUST be 1576 maintained independently for each message type within each ANCP 1577 adjacency. Furthermore, it SHOULD be incremented by 1 for each new 1578 message of the given type, cycling back to 1 after running the full 1579 range. For event messages, the Transaction ID SHOULD be set to zero. 1581 Unless otherwise specified, the default behaviour for all ANCP 1582 responses is that the value of the Transaction ID MUST be copied from 1583 the corresponding request message. 1585 3.6.1.7. I flag and SubMessage Number (1 + 15 bits) 1587 In GSMPv3 these provide a mechanism for message fragmentation. 1588 Because ANCP uses TCP transport, this mechanism is unnecessary. An 1589 ANCP agent MUST set the I Flag and subMessage Number fields to 1 to 1590 signify "no fragmentation". 1592 3.6.1.8. Length (16 bits) 1594 This field MUST be set to the length of the ANCP message in bytes, 1595 including its header fields and message body but excluding the four- 1596 byte encapsulating header defined in Section 3.2. 1598 3.6.2. The ANCP Message Body 1600 The detailed contents of the message payload portion of a given ANCP 1601 message can vary with the capability in the context of which it is 1602 being used. However, the general format consists of zero or more 1603 fixed fields, followed by a variable amount of data in the form of 1604 Type-Length-Value (TLV) data structures. 1606 The general format of a TLV is shown in Figure 8: 1608 0 1 2 3 1609 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 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1611 | Type (IANA registered) | Length | 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 | | 1614 ~ Value ~ 1615 | | 1616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1618 Figure 8: General TLV Format 1620 The fields of a TLV are defined as follows: 1622 Type (16 bits): The TLV Type is an unsigned value identifying the 1623 TLV type and nature of its contents. An IANA registry has been 1624 established for ANCP TLV Type codes. 1626 Length (16 bits): The number of bytes of data in the Value field of 1627 the TLV, excluding any padding required to bring this TLV to a 1628 4-byte word boundary (see "Value" below). If a TLV contains other 1629 TLVs, any padding in the contained TLVs MUST be included in the 1630 value of Length. Depending on the specification of the TLV, the 1631 value of Length can be zero, a constant for all instances of the 1632 TLV, or a varying quantity. 1634 Value (variable): The actual data carried by the TLV, if any. The 1635 value field in each TLV MUST be padded with zeroes as required to 1636 align with a 4-byte word boundary. The Value field of a TLV MAY 1637 include fixed fields and/or other TLVs. 1639 Unless otherwise specified, TLVs MAY be added to a message in any 1640 order. If the recipient of a message does not understand a 1641 particular TLV, it MUST silently ignore it. 1643 A number of TLVs are specified in the remainder of this document. 1645 3.7. General Principles for the Design of ANCP Messages 1647 ANCP allows for two messaging constructs to support request/response 1648 interaction: 1650 a. The same message type is used for both the request message and 1651 the response message. The Result and Result Code field settings 1652 are used to differentiate between request and response messages. 1654 b. The request and response messages use two different message 1655 types. 1657 The first approach is illustrated by the protocol specifications in 1658 Section 8.4, the second by specifications in Section 6.4. The 1659 purpose of this section is to provide more details about the second 1660 approach in order to allow the use of this messaging construct for 1661 the development of additional ANCP extensions. 1663 As Section 3.6 indicated, all ANCP messages other than adjacency 1664 messages share a common header format. When the response message 1665 type is different from that of the request, the specification of the 1666 request message will typically indicate that the Result field is set 1667 to Ignore (0x0) and provide procedures indicating explicitly when the 1668 receiver should generate a response and what message type it should 1669 use. 1671 The Transaction ID field is used to distinguish between multiple 1672 request messages of the same type and to associate a response message 1673 to a request. Specifications of ANCP messages for applications not 1674 requiring response correlation SHOULD indicate that the Transaction 1675 ID MUST be set to zero in requests. Applications that require 1676 response correlation SHOULD refer to the Transaction ID behaviour 1677 described in Section 3.6.1. 1679 The specification for a response message SHOULD indicate in all cases 1680 that value of the Transaction Identifier MUST be set to that of the 1681 corresponding request message. This allows the requester to 1682 establish whether or not correlation is needed (by setting a non-zero 1683 or zero value for the Transaction ID). 1685 4. Generally Useful ANCP Messages and TLVs 1687 This section defines two messages and a number of TLVs that could be 1688 useful in multiple capabilities. In some cases the content is under- 1689 specified, with the intention that particular capabilities spell out 1690 the remaining details. 1692 4.1. Provisioning Message 1694 The Provisioning message is sent by the NAS to the AN to provision 1695 information of global scope (i.e., not associated with specific 1696 access lines) on the AN. The Provisioning message has the format 1697 shown in Figure 9. Support of the Provisioning message is OPTIONAL 1698 unless the ANCP agent claims support for a capability that requires 1699 its use. 1701 0 1 2 3 1702 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 1703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1704 | TCP/IP Encapsulating Header (Section 3.2) | 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1706 | ANCP General Message Header | 1707 + (Section 3.6.1) + 1708 | | 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1710 | | 1711 ~ TLVs ~ 1712 | | 1713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1715 Figure 9: Format of the Provisioning Message 1717 The message header field settings given below are REQUIRED in the 1718 Provisioning message. The remaining message header fields MUST be 1719 set as specified in Section 3.6.1. Which TLVs to carry in the 1720 Provisioning message is specified as part of the specification of the 1721 capabilities that use that message. The Provisioning message MAY be 1722 used to carry data relating to more than one capability at once, 1723 assuming that the capabilities concerned can co-exist and have all 1724 been negotiated during adjacency establishment. 1726 Message Type: MUST be set to 93. 1728 Result: MUST be set to 0x0 (Ignore). 1730 Result Code: MUST be set to zero. 1732 Transaction ID: MUST be populated with a non-zero value chosen in 1733 the manner described in Section 3.6.1.6. 1735 If the AN can process the message successfully and accept all the 1736 provisioning directives contained in it, the AN MUST NOT send any 1737 response. 1739 Unless otherwise specified for a particular capability, if the AN 1740 fails to process the message successfully it MUST send a Generic 1741 Response message (Section 4.2) indicating failure and providing 1742 appropriate diagnostic information. 1744 4.2. Generic Response Message 1746 This section defines the Generic Response message. The Generic 1747 Response message MAY be specified as the appropriate response to a 1748 message defined in an extension to ANCP, instead of a more specific 1749 response message. As a general guideline, specification of the 1750 Generic Response message as a response is appropriate where no data 1751 needs to be returned to the peer other than a result (success or 1752 failure), plus, in the case of a failure, a code indicating the 1753 reason for failure and a limited amount of diagnostic data. 1754 Depending on the particular use case, the Generic Response message 1755 MAY be sent by either the NAS or the AN. 1757 Support of the Generic Response message, both as sender and as 1758 receiver, is REQUIRED for all ANCP agents, regardless of what 1759 capabilities they support. 1761 The AN or NAS MAY send a Generic Response message indicating a 1762 failure condition independently of a specific request before closing 1763 the adjacency as a consequence of that failure condition. In this 1764 case, the sender MUST set the Transaction ID field in the header and 1765 the Message Type field within the Status-Info TLV to zeroes. The 1766 receiver MAY record the information contained in the Status-Info TLV 1767 for management use. 1769 The format of the Generic Response message is shown in Figure 10 1771 0 1 2 3 1772 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 1773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1774 | TCP/IP Encapsulating Header (Section 3.2) | 1775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1776 | ANCP General Message Header | 1777 + (Section 3.6.1) + 1778 | | 1779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1780 | Access line identifying TLV(s) | 1781 + (copied from original request) + 1782 | | 1783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1784 | Status-Info TLV | 1785 ~ (Section 4.5) ~ 1786 | | 1787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1789 NOTE: TLVs MAY be in a different order from what is shown in this 1790 figure. 1792 Figure 10: Structure of the Generic Response Message 1794 This document specifies the following header fields. The remaining 1795 fields in the ANCP general message header MUST be set as specified in 1796 Section 3.6.1. 1798 Message Type: MUST be set to 91. 1800 Result: MUST be set to 0x3 (Success) or 0x4 (Failure). 1802 Result Code: MUST be set to zero for success or an appropriate non- 1803 zero value for failure. 1805 Transaction ID: MUST be copied from the message to which this 1806 message is a response. 1808 If the original request applied to a specific access line or set of 1809 lines, the TLVs identifying the line(s) and possibly the user MUST be 1810 copied into the Generic Response message at the top level. 1812 The Status-Info TLV MAY be present in a success response, to provide 1813 a warning as defined for a specific request message type. It MUST be 1814 present in a failure response. See Section 4.5 for a detailed 1815 description of the Status-Info TLV. The actual contents will depend 1816 on the request message type this message is responding to and the 1817 value of the Result Code field. 1819 To prevent an infinite loop of error responses, if the Generic 1820 Response message is itself in error, the receiver MUST NOT generate 1821 an error response in return. 1823 4.3. Target TLV 1825 Type: 0x1000 to 0x1020 depending on the specific content. Only 1826 0x1000 has been assigned in this specification (see below). 1827 Support of any specific variant of the Target TLV is OPTIONAL 1828 unless the ANCP agent claims support for a capability that 1829 requires its use. 1831 Description: The Target TLV (0x1000 - 0x1020) is intended to be a 1832 general means to represent different types of objects. 1834 Length: Variable, depending on the specific object type. 1836 Value: Target information as defined for each object type. The 1837 Value field MAY consist of sub-TLVs. 1839 TLV Type 0x1000 is assigned to a variant of the Target TLV 1840 representing a single access line and encapsulating one or more sub- 1841 TLVs identifying the target. Figure 11 is an example illustrating 1842 the TLV format for a single port identified by an Access-Loop- 1843 Circuit-ID TLV (0x0001) (Section 5.1.2.1). 1845 0 1 2 3 1846 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 1847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1848 | TLV Type = 0x1000 |Length = Circuit-ID Length + 4 | 1849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1850 | Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length | 1851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1852 | | 1853 ~ Access Loop Circuit ID ~ 1854 | | 1855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1857 Figure 11: Example of Target TLV For Single Access Line 1859 4.4. Command TLV 1861 Type: 0x0011 1863 Description: The Command TLV (0x0011) is intended to be a general 1864 means of encapsulating one or more command directives in a TLV 1865 oriented message. The semantics of the command can be specified 1866 for each message type using it. I.e., the specification of each 1867 message type that can carry the Command TLV is expected to define 1868 the meaning of the content of the payload, although re-use of 1869 specifications is, of course, permissible when appropriate. 1870 Support of any specific variant of the Command TLV is OPTIONAL 1871 unless the ANCP agent claims support for a capability that 1872 requires its use. 1874 Length: Variable, depending on the specific contents. 1876 Value: Command information as defined for each message type. The 1877 field MAY include sub-TLVs. The contents of this TLV MUST be 1878 specified as one "command" or alternatively a sequence of one or 1879 more "commands", each beginning with a one-byte Command Code and 1880 possibly including other data following the Command Code. An IANA 1881 registry has been established for Command Code values. This 1882 document reserves the Command Code value 0 as an initial entry in 1883 the registry. 1885 4.5. Status-Info TLV 1887 Name: Status-Info 1889 Type: 0x0106 1890 Description: The Status-Info-TLV is intended to be a general 1891 container for warning or error diagnostics relating to commands 1892 and/or requests. It is a supplement to the Result Code field in 1893 the ANCP general header. The specifications for individual 1894 message types MAY indicate the use of this TLV as part of 1895 responses, particularly for failures. As mentioned above, the 1896 Generic Response message will usually include an instance of the 1897 Status-Info TLV. Support of the Status-Info TLV, both as sender 1898 and as receiver, is REQUIRED for all ANCP agents, regardless of 1899 what capabilities they support. 1901 Length: Variable, depending on the specific contents. 1903 Value: The following fixed fields. In addition, sub-TLVs MAY be 1904 appended to provide further diagnostic information. 1906 Reserved (8 bits): see Section 3.4 for handling of reserved 1907 fields. 1909 Msg Type (8 bits): Message Type of the request for which this TLV 1910 is providing diagnostics. 1912 Result Message Length (16 bits): Number of bytes in the error 1913 message, excluding padding, but including the language tag and 1914 delimiter. This MAY be zero if no error message is provided. 1916 Result Message: Human-readable string providing information about 1917 the warning or error condition. The initial characters of the 1918 string MUST be a language tag as described in [RFC5646], 1919 terminated by a colon (":"). The actual text string follows 1920 the delimiter. The field is padded at the end with zeroes as 1921 necessary to extend it to a four-byte word boundary. 1923 Section 3.6.1.4 provides recommendations for what TLVs to add in 1924 the Status-Info TLV for particular values of the message header 1925 Result Code field. 1927 Figure 12 illustrates the Status-Info TLV. 1929 0 1 2 3 1930 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 1931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1932 | TLV Type = 0x0106 | Length | 1933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1934 | Reserved | Msg Type | Error Message Length | 1935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1936 | Error Message (padded to 4 byte boundary) | 1937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1938 | optional sub-TLVs... | 1939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1941 Figure 12: The Status-Info TLV 1943 5. Introduction To ANCP Capabilities For Digital Subscriber Lines (DSL) 1945 DSL is a widely deployed access technology for Broadband Access for 1946 Next Generation Networks. Specifications such as [TR-059], [TR-058], 1947 and [TR-092] describe possible architectures for these access 1948 networks. The scope of these specifications includes the delivery of 1949 voice, video, and data services. 1951 The next three sections of this document specify basic ANCP 1952 capabilities for use specifically in controlling Access Nodes serving 1953 DSL access (Tech Type = 0x05). The same ANs could be serving other 1954 access technologies (e.g. Metro-Ethernet, Passive Optical 1955 Networking, WiMax), in which case the AN will also have to support 1956 the corresponding other-technology-specific capabilities. Those 1957 additional capabilities are outside the scope of the present 1958 document. 1960 5.1. DSL Access Line Identification 1962 Most ANCP messages involve actions relating to a specific access 1963 line. Thus it is necessary to describe how access lines are 1964 identified within those messages. This section defines four TLVs for 1965 that purpose and provides an informative description of how they are 1966 used. 1968 5.1.1. Control Context (Informative) 1970 Three types of identification are described in [TR-101] and provided 1971 for in the TLVs defined in this section: 1973 o identification of an access line by its logical appearance on the 1974 user side of the Access Node; 1976 o identification of an access line by its logical appearance on the 1977 NAS side of the Access Node; and 1979 o identification down to the user or host level as a supplement to 1980 access line identification in one of the other two forms. 1982 All of these identifiers originate with the AN control application, 1983 during the process of DSL topology discovery. The control 1984 application chooses which identifiers to use and the values to place 1985 into them on a line-by-line basis, based on AN configuration and 1986 deployment considerations. 1988 Aside from its use in ANCP signalling, access line identification is 1989 also used in DHCP ([RFC2131], [RFC3315]) transactions involving hosts 1990 served by DSL. Either the AN or the NAS can serve as a DHCP relay 1991 node. [TR-101] requires the AN or NAS in this role to add access 1992 line identification in Option 82 (Information) ([RFC3046], with its 1993 IPv6 equivalent in [RFC4649]) to each DHCP request it forwards to the 1994 DHCP server. It is desirable for efficiency that the identification 1995 used in this signalling should be the same as the identification used 1996 in ANCP messages. 1998 From the point of view of ANCP itself, the identifiers are opaque. 1999 From the point of view of the AN control application, the syntax for 2000 the user-side access line identifier is the same as specified in 2001 Section 3.9.3 of [TR-101] for DHCP Option 82. The syntax for the 2002 ASCII form of the NAS-side access line identifier will be similar. 2004 Access line identification by logical appearance on the user side of 2005 the Access Node will always identify a DSL loop uniquely. 2006 Identification by the logical appearance on the NAS side of the 2007 Access Node is unique only if there is a one-to-one mapping between 2008 the appearances on the two sides and no identity-modifying 2009 aggregation between the AN and the NAS. In other cases, and in 2010 particular in the case of Ethernet aggregation using the N:1 VLAN 2011 model, the user-side access line identification is necessary, but the 2012 NAS-side identification is potentially useful information allowing 2013 the NAS to build up a picture of the aggregation network topology. 2015 Additional identification down to the user or host level is intended 2016 to supplement rather than replace either of the other two forms of 2017 identification. 2019 Sections 3.8 and 3.9 of [TR-101] are contradictory on this point. 2020 It is assumed here that Section 3.9 is meant to be authoritative. 2022 The user-level identification takes the form of an administered 2023 string which again is opaque at the ANCP level. 2025 The NAS control application will use the identifying information it 2026 receives from the AN directly for some purposes. For examples, see 2027 the introductory part of Section 3.9 of [TR-101]. For other 2028 purposes, the NAS will build a mapping between the unique access line 2029 identification provided by the AN, the additional identification of 2030 the user or host (where provided), and the IP interface on a 2031 particular host. For access lines with static IP address assignment 2032 that mapping could be configured instead. 2034 5.1.2. TLVs For DSL Access Line Identification 2036 This section provides a normative specification of the TLVs that ANCP 2037 provides to carry the types of identification just described. The 2038 Access-Loop-Circuit-ID TLV identifies an access line by its logical 2039 appearance on the user side of the Access Node. Two alternatives, 2040 the Access-Aggregation-Circuit-ID-ASCII TLV and the Access- 2041 Aggregation-Circuit-ID-Binary TLV, identify an access line by its 2042 logical appearance on the NAS side of the Access Node. It is 2043 unlikely that a given AN uses both of these TLVs, either for the same 2044 line or for different lines, since they carry equivalent information. 2045 Finally, the Access-Loop-Remote-Id TLV contains an operator- 2046 configured string that uniquely identifies the user on the associated 2047 access line, as described in Sections 3.9.1 and 3.9.2 of [TR-101]. 2049 ANCP agents conforming to this section MUST satisfy the following 2050 requirements: 2052 o ANCP agents MUST be able to build and send the Access-Loop- 2053 Circuit-ID TLV, the Access-Loop-Remote-Id TLV, and either the 2054 Access-Aggregation-Circuit-ID-ASCII TLV or the Access-Aggregation- 2055 Circuit-ID-Binary TLV (implementation choice), when passed the 2056 associated information from the AN control application. 2058 o ANCP agents MUST be able to receive all four TLV types, extract 2059 the relevant information, and pass it to the control application. 2061 o If the Access-Loop-Remote-Id TLV is present in a message, it MUST 2062 be accompanied by an Access-Loop-Circuit-ID TLV and/or an Access- 2063 Aggregation-Circuit-ID-xxx TLV with two VLAN identifiers. 2065 The Access-Loop-Remote-Id TLV is not enough to identify an 2066 access line uniquely on its own. As indicated above, an 2067 Access-Aggregation-Circuit-ID-xxx TLV with two VLAN identifiers 2068 may or may not identify an access line uniquely, but this is up 2069 to the control application to decide. 2071 o If the Access-Aggregation-Circuit-ID-xxx TLV is present in a 2072 message with just one VLAN identifier, it MUST be accompanied by 2073 an Access-Loop-Circuit-ID TLV. 2075 5.1.2.1. Access-Loop-Circuit-ID TLV 2077 Type: 0x0001 2079 Description: a locally administered human-readable string generated 2080 by or configured on the Access Node, identifying the corresponding 2081 access loop logical port on the user side of the Access Node. 2083 Length: up to 63 bytes 2085 Value: ASCII string 2087 5.1.2.2. Access-Loop-Remote-Id TLV 2089 Type: 0x0002 2091 Description: an operator-configured string that uniquely identifies 2092 the user on the associated access line, as described in Sections 2093 3.9.1 and 3.9.2 of [TR-101]. 2095 Length: up to 63 bytes 2097 Value: ASCII string 2099 5.1.2.3. Access-Aggregation-Circuit-ID-Binary TLV 2101 Type: 0x0006 2103 Description: This TLV identifies or partially identifies a specific 2104 access line by means of its logical circuit identifier on the NAS 2105 side of the Access Node. 2107 For Ethernet access aggregation, where a per-subscriber (stacked) 2108 VLAN can be applied (1:1 model as defined in [TR-101]), the TLV 2109 contains two value fields. Each field carries a 12-bit VLAN 2110 identifier (which is part of the VLAN tag defined by IEEE 802.1Q). 2111 The first field MUST carry the inner VLAN identifier, while the 2112 second field MUST carry the outer VLAN identifier. 2114 When the N:1 VLAN model is used, only one VLAN tag is available. 2115 For the N:1 model, the Access-Aggregation-Circuit-ID-Binary TLV 2116 contains a single value field, which MUST carry the 12-bit VLAN 2117 identifier derived from the single available VLAN tag. 2119 In the case of an ATM aggregation network, where the DSLAM is 2120 directly connected to the NAS (without an intermediate ATM 2121 switch), the VPI and VCI on the DSLAM uplink correspond uniquely 2122 to the DSL line on the DSLAM. The Access-Aggregation-Circuit-ID- 2123 Binary TLV MAY be used to carry the VPI and VCI. The first value 2124 field of the TLV MUST carry the VCI, while the second value field 2125 MUST carry the VPI. 2127 Each identifier MUST be placed in the low-order bits of its 2128 respective 32-bit field, with the higher-order bits set to zero. 2129 The ordering of the bits of the identifer MUST be the same as when 2130 the identifier is transmitted on the wire to identify an Ethernet 2131 frame or ATM cell. 2133 The Access-Aggregation-Circuit-ID-Binary is illustrated in 2134 Figure 13. 2136 Length: 4 or 8 bytes 2138 Value: one or two 32-bit binary fields. 2140 0 1 2 3 2141 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 2142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2143 | TLV Type = 0x0006 | Length = 4 or 8 | 2144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2145 | Single VLAN Identifier, inner VLAN identifier, or VCI | 2146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2147 | Outer VLAN identifier or VPI | 2148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2150 Figure 13: The Access-Aggregation-Circuit-ID-Binary TLV 2152 5.1.2.4. Access-Aggregation-Circuit-ID-ASCII TLV 2154 Type: 0x0003 2156 Description: This TLV transmits the ASCII equivalent of the Access- 2157 Aggregation-Circuit-ID-Binary TLV. As mentioned in the previous 2158 section, the AN control application will use a format similar to 2159 that specified in Section 3.9.3 of [TR-101] for the format of the 2160 "circuit-id". 2162 As an extension to the present document, the Access Node could 2163 convey to the NAS the characteristics (e.g., bandwidth) of the 2164 uplink on the Access Node. This TLV or the binary equivalent 2165 defined above then serves the purpose of uniquely identifying the 2166 uplink whose characteristics are being defined. The present 2167 document does not specify the TLVs needed to convey the uplink 2168 characteristics. 2170 Length: up to 63 bytes 2172 Value: ASCII string 2174 6. ANCP Based DSL Topology Discovery 2176 Section 3.1 of [RFC5851] describes the requirements for the DSL 2177 Topology Discovery capability. 2179 6.1. Control Context (Informative) 2181 The AN control application in the DSLAM requests ANCP to send a DSL- 2182 specific Port Up message to the NAS under the following 2183 circumstances: 2185 o when a new adjacency with the NAS is established, for each DSL 2186 loop that is synchronized at that time; 2188 o subsequent to that, whenever a DSL loop resynchronizes; and 2190 o whenever the AN control application wishes to signal that a line 2191 attribute has changed. 2193 The AN control application in the DSLAM requests ANCP to send a DSL- 2194 specific Port Down message to the NAS under the following 2195 circumstances: 2197 o when a new adjacency with the NAS is established, for each DSL 2198 loop that is provisioned but not synchronized at that time; 2200 o whenever a DSL loop that is equipped in an AN but administratively 2201 disabled is signalled as "IDLE"; and 2203 o subsequent to that, whenever a DSL loop loses synchronization. 2205 The AN control application passes information to identify the DSL 2206 loop to ANCP to include in the Port Up or Port Down message, along 2207 with information relating to DSL loop attributes. 2209 In the case of bonded copper loops to the customer premise (as per 2210 DSL multi-pair bonding described by [G.988.1] and [G.988.2]), the AN 2211 control application requests that ANCP send DSL-specific Port Up and 2212 Port Down messages for the aggregate "DSL bonded circuit" 2213 (represented as a single logical port) as well as the individual DSL 2214 loops of which it is comprised. The information relating to DSL line 2215 attributes that is passed by the AN control application is aggregate 2216 information. 2218 ANCP generates the DSL-specific Port Up or Port Down message and 2219 transfers it to the NAS. ANCP on the NAS side passes an indication 2220 to the NAS control application that a DSL Port Up or Port Down 2221 message has been received along with the information contained in the 2222 message. 2224 The NAS control application updates its view of the DSL loop state, 2225 performs any required accounting operations, and uses any included 2226 line attributes to adjust the operation of its queueing/scheduling 2227 mechanisms as they apply to data passing to and from that DSL loop. 2229 Figure 14 summarizes the interaction. 2231 1. Home Access NAS 2232 Gateway Node 2234 -----------> --------------------------> 2235 DSL Port Up (Event message) 2236 Signal (default line parameters) 2238 2. Home Access NAS 2239 Gateway Node 2241 -----------> --------------------------> 2242 DSL Port Up (Event message) 2243 Resynch (updated line parameters) 2245 3. Home Access NAS 2246 Gateway Node 2248 -----------> --------------------------> 2249 Loss of Port Down (Event message) 2250 DSL Signal (selected line parameters) 2252 Figure 14: ANCP Message Flow For DSL Topology Discovery 2254 6.2. Protocol Requirements 2256 The DSL topology discovery capability is assigned capability type 2257 0x0001. No capability data is associated with this capability. 2259 6.2.1. Protocol Requirements On the AN Side 2261 The AN-side ANCP agent MUST be able to create DSL-specific Port Up 2262 and Port Down messages according to the format specified in 2263 Section 6.3. 2265 The AN-side ANCP agent MUST conform to the normative requirements of 2266 Section 5.1.2. 2268 The AN-side ANCP agent MUST follow the AN-side procedures associated 2269 with DSL-specific Port Up and Port Down messages as they are 2270 specified in Section 6.4. 2272 6.2.2. Protocol Requirements On the NAS Side 2274 The NAS-side ANCP agent MUST be able to receive and validate DSL- 2275 specific Port Up and Port Down messages according to the format 2276 specified in Section 6.3. 2278 The NAS-side ANCP agent MUST conform to the normative requirements of 2279 Section 5.1.2. 2281 The NAS-side ANCP agent MUST follow the NAS-side procedures 2282 associated with DSL-specific Port Up and Port Down messages as they 2283 are specified in Section 6.4. 2285 6.3. ANCP Port UP and Port DOWN Event Message Descriptions 2287 The format of the ANCP Port UP and Port DOWN Event messages is shown 2288 in Figure 15. 2290 0 1 2 3 2291 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 2292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2293 | TCP/IP Encapsulating Header (Section 3.2) | 2294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2295 | ANCP General Message Header | 2296 + (Section 3.6.1) + 2297 | | 2298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2299 | | 2300 ~ Unused (20 bytes) ~ 2301 | | 2302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2303 |x|x|x|x|x|x|x|x| Message Type | Tech Type | Reserved | 2304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2305 | # of TLVs | Extension Block length (bytes)| 2306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2307 | | 2308 ~ Access line identifying TLV(s) ~ 2309 | | 2310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2311 | DSL-Line-Attributes TLV | 2312 ~ (MANDATORY in Port Up, OPTIONAL in Port Down) ~ 2313 | | 2314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2316 NOTE: TLVs MAY be in a different order from what is shown in this 2317 figure. 2319 Figure 15: Format Of the ANCP Port Up and Port Down Event Messages 2320 For DSL Topology Discovery 2322 See Section 3.6.1 for a description of the ANCP general message 2323 header. The Message Type field MUST be set to 80 for Port Up, 81 for 2324 Port Down. The 12 bit Result Code field MUST be set to 0. The 4 bit 2325 Result field MUST be set to 0 (signifying Ignore). The 24-bit 2326 Transaction Identifier field MUST be set to 0. Other fields in the 2327 general header MUST be set as described in Section 3.6. 2329 The five word Unused field is a historical leftover. The handling of 2330 unused/reserved fields is described in Section 3.4. 2332 The remaining message fields belong to the "extension block", and are 2333 described as follows: 2335 Extension Flags: The flag bits denoted by 'x' are currently 2336 unspecified and reserved. 2338 Message Type: Message Type has the same value as in the general 2339 header (i.e., 80 or 81). 2341 Tech Type: MUST be set to 0x05 (DSL). 2343 # of TLVs: the number of TLVs that follow, not counting TLVs 2344 encapsulated within other TLVs. 2346 Extension Block Length: the total length of the TLVs carried in the 2347 extension block in bytes, including any padding within individual 2348 TLVs. 2350 TLVs: one or more TLVs to identify a DSL line and zero or more TLVs 2351 to define its characteristics. 2353 6.4. Procedures 2355 6.4.1. Procedures On the AN Side 2357 The AN-side ANCP agent creates and transmits a DSL-specific Port Up 2358 or Port Down message when requested by the AN control application and 2359 presented with the information needed to build a valid message. It 2360 is RECOMMENDED that the Access Node use a dampening mechanism per DSL 2361 loop to control the rate at which state changes are communicated to 2362 the NAS. 2364 At the top level, the extension block within a DSL-specific Port Up 2365 or Port Down message MUST include TLVs from Section 5.1.2 to identify 2366 the DSL loop. 2368 TLVs presenting DSL line attributes (i.e., the TLVs specified in 2369 Section 6.5) MUST be encapsulated within the DSL-Line-Attributes TLV. 2370 When the DSL-Line-Attributes TLV is present in a message, it MUST 2371 contain at least one such TLV and will generally contain more than 2372 one. In the Port Up message, the DSL-Line-Attributes TLV MUST be 2373 present. In the Port Down message, the DSL-Line-Attributes TLV MAY 2374 be present. 2376 6.4.2. Procedures On the NAS Side 2378 The NAS-side ANCP agent MUST be prepared to receive Port Up and Port 2379 Down messages for a given DSL loop or logical port at any time after 2380 negotiation of an adjacency has been completed. It is possible for 2381 two Port Up messages in succession to be received for the same DSL 2382 loop without an intervening Port Down message, and vice versa. 2384 The NAS-side ANCP agent SHOULD validate each message against the 2385 specifications given in Section 6.3 and the TLV specifications given 2386 in Section 5.1.2 and Section 6.5. If it finds an error it MAY 2387 generate a Generic Response message containing an appropriate Result 2388 Code value. If it does so, the message MUST contain copies of all of 2389 the identifier TLVs from Section 5.1.2 that were present in the Port 2390 Up or Port Down message. The message SHOULD also contain a Status- 2391 Info TLV which in turn contains other information appropriate to the 2392 message header Result Code value as described in Section 3.6.1.4. 2394 If the received message passes validation, the NAS-side ANCP agent 2395 extracts the information from the TLVs contained in the message and 2396 presents that information along with an indication of reported event 2397 type to the NAS control application. If validation of individual 2398 TLVs fails but the message as a whole can be processed, the NAS-side 2399 ANCP agent "may" pass the valid message contents to the NAS control 2400 application. 2402 6.5. TLVs For DSL Line Attributes 2404 As specified above, the DSL-Line-Attributes TLV is inserted into the 2405 Port Up or Port Down message at the top level. The remaining TLVs 2406 defined below are encapsulated within the DSL-Line-Attributes TLV. 2408 6.5.1. DSL-Line-Attributes TLV 2410 Type: 0x0004 2412 Description: This TLV encapsulates attribute values for a DSL line 2413 serving a subscriber. 2415 Length: variable (up to 1024 bytes) 2417 Value: one or more encapsulated TLVs corresponding to DSL line 2418 attributes. The DSL-Line-Attributes TLV MUST contain at least one 2419 TLV when it is present in a Port Up or Port Down message. The 2420 actual contents are determined by the AN control application. 2422 6.5.2. DSL-Type TLV 2424 Type: 0x0091 2426 Description: Indicates the type of transmission system in use. 2428 Length: 4 bytes 2429 Value: 32 bit unsigned integer 2431 ADSL1 = 1 2433 ADSL2 = 2 2435 ADSL2+ = 3 2437 VDSL1 = 4 2439 VDSL2 = 5 2441 SDSL = 6 2443 OTHER = 0 2445 6.5.3. Actual-Net-Data-Rate-Upstream TLV 2447 Type: 0x0081 2449 Description: Actual upstream net data rate on a DSL line. 2451 Length: 4 bytes 2453 Value: Rate in Kbits/s as a 32 bit unsigned integer 2455 6.5.4. Actual-Net-Data-Rate-Downstream TLV 2457 Type: 0x0082 2459 Description: Actual downstream net data rate on a DSL line. 2461 Length: 4 bytes 2463 Value: Rate in Kbits/s as a 32 bit unsigned integer 2465 6.5.5. Minimum-Net-Data-Rate-Upstream TLV 2467 Type: 0x0083 2469 Description: Minimum upstream net data rate desired by the operator. 2471 Length: 4 bytes 2473 Value: Rate in Kbits/s as a 32 bit unsigned integer 2475 6.5.6. Minimum-Net-Data-Rate-Downstream TLV 2477 Type: 0x0084 2479 Description: Minimum downstream net data rate desired by the 2480 operator. 2482 Length: 4 bytes 2484 Value: Rate in Kbits/s as a 32 bit unsigned integer 2486 6.5.7. Attainable-Net-Data-Rate-Upstream TLV 2488 Type: 0x0085 2490 Description: Maximum net upstream rate that can be attained on the 2491 DSL line. 2493 Length: 4 bytes 2495 Value: Rate in Kbits/s as a 32 bit unsigned integer 2497 6.5.8. Attainable-Net-Data-Rate-Downstream TLV 2499 Type: 0x0086 2501 Description: Maximum net downstream rate that can be attained on the 2502 DSL line. 2504 Length: 4 bytes 2506 Value: Rate in Kbits/s as a 32 bit unsigned integer 2508 6.5.9. Maximum-Net-Data-Rate-Upstream TLV 2510 Type: 0x0087 2512 Description: Maximum net upstream data rate desired by the operator. 2514 Length: 4 bytes 2516 Value: Rate in Kbits/s as a 32 bit unsigned integer 2518 6.5.10. Maximum-Net-Data-Rate-Downstream TLV 2519 Type: 0x0088 2521 Description: Maximum net downstream data rate desired by the 2522 operator. 2524 Length: 4 bytes 2526 Value: Rate in Kbits/s as a 32 bit unsigned integer 2528 6.5.11. Minimum-Net-Low-Power-Data-Rate-Upstream TLV 2530 Type: 0x0089 2532 Description: Minimum net upstream data rate desired by the operator 2533 in low power state. 2535 Length: 4 bytes 2537 Value: Rate in Kbits/s as a 32 bit unsigned integer 2539 6.5.12. Minimum-Net-Low-Power-Data-Rate-Downstream TLV 2541 Type: 0x008A 2543 Description: Minimum net downstream data rate desired by the 2544 operator in low power state. 2546 Length: 4 bytes 2548 Value: Rate in Kbits/s as a 32 bit unsigned integer 2550 6.5.13. Maximum-Interleaving-Delay-Upstream TLV 2552 Type: 0x008B 2554 Description: maximum one way interleaving delay. 2556 Length: 4 bytes 2558 Value: Time in ms as a 32 bit unsigned integer 2560 6.5.14. Actual-Interleaving-Delay-Upstream TLV 2562 Type: 0x008C 2563 Description: Value corresponding to the interleaver setting. 2565 Length: 4 bytes 2567 Value: Time in ms as a 32 bit unsigned integer 2569 6.5.15. Maximum-Interleaving-Delay-Downstream TLV 2571 Type: 0x008D 2573 Description: maximum one way interleaving delay. 2575 Length: 4 bytes 2577 Value: Time in ms as a 32 bit unsigned integer 2579 6.5.16. Actual-Interleaving-Delay-Downstream 2581 Type: 0x008E 2583 Description: Value corresponding to the interleaver setting. 2585 Length: 4 bytes 2587 Value: Time in ms as a 32 bit unsigned integer 2589 6.5.17. DSL-Line-State TLV 2591 Type: 0x008F 2593 Description: The state of the DSL line. 2595 Length: 4 bytes 2597 Value: 32 bit unsigned integer 2599 SHOWTIME = 1 2601 IDLE = 2 2603 SILENT = 3 2605 6.5.18. Access-Loop-Encapsulation TLV 2606 Type: 0x0090 2608 Description: The data link protocol and, optionally, the 2609 encapsulation overhead on the access loop. When this TLV is 2610 present, at least the data link protocol MUST be indicated. The 2611 encapsulation overhead MAY be indicated. The Access Node MAY 2612 choose to not convey the encapsulation on the access loop by 2613 specifying values of 0 (NA) for the two encapsulation fields. 2615 Length: 3 bytes 2617 Value: The three bytes (most to least significant) and valid set of 2618 values for each byte are defined as follows: 2620 Byte 1: Data Link 2622 ATM AAL5 = 0 2624 ETHERNET = 1 2626 Byte 2: Encapsulation 1 2628 NA = 0 2630 Untagged Ethernet = 1 2632 Single-tagged Ethernet = 2 2634 Double-tagged Ethernet = 3 2636 Byte 3: Encapsulation 2 2638 NA = 0 2640 PPPoA LLC = 1 2642 PPPoA NULL = 2 2644 IPoA LLC = 3 2646 IPoA NuLL = 4 2648 Ethernet over AAL5 LLC with FCS = 5 2650 Ethernet over AAL5 LLC without FCS = 6 2652 Ethernet over AAL5 NULL with FCS = 7 2653 Ethernet over AAL5 NULL without FCS = 8 2655 The Access-Loop-Encapsulation TLV is illustrated in Figure 16. 2657 0 1 2 3 2658 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 2659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2660 | TLV Type = 0x0090 | Length = 3 | 2661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2662 | Data link | Encaps 1 | Encaps 2 | Padding (=0) | 2663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2665 Figure 16: The Access-Loop-Encapsulation TLV 2667 7. ANCP based DSL Line Configuration 2669 The use case for ANCP-based DSL Line Configuration is described in 2670 Section 3.2 of [RFC5851]. 2672 7.1. Control Context (Informative) 2674 Triggered by topology information reporting a new DSL line or 2675 triggered by a subsequent user session establishment (via PPP or 2676 DHCP), RADIUS/AAA sends service parameters to the NAS control 2677 application for configuration on the access line. The NAS control 2678 application passes the request on to the NAS-side agent, which sends 2679 the information to the AN by means of a Port Management (line 2680 configuration) message. The AN-side agent passes this information up 2681 to the AN control application, which applies it to the line. 2682 Figure 17 summarizes the interaction. 2684 Home Access NAS RADIUS/AAA 2685 Gateway Node Policy Server 2687 -----------> ---------------> 2688 DSL Port Up message) 2689 Signal (line parameters) 2691 --------------------------------> --------------> 2692 PPP/DHCP Session Authentication & 2693 authorization 2695 <---------------- 2696 Port Management message 2697 (line configuration) 2699 Figure 17: Message Flow - ANCP Mapping For Initial Line Configuration 2700 The NAS could update the line configuration as a result of a 2701 subscriber service change (e.g. triggered by the policy server). 2702 Figure 18 summarizes the interaction. 2704 User Home Access NAS 2705 Gateway Node 2707 --------------------------> 2708 PPP/DHCP Session 2710 -------------------------------------------------------> Web portal, 2711 Service on demand OSS, etc. 2712 | 2713 <-------------- RADIUS/AAA 2714 Change of Policy Server 2715 authorization 2717 <------------ 2718 Port Management 2719 message 2720 (new profile) 2722 Figure 18: Message flow - ANCP Mapping For Updated Line Configuration 2724 7.2. Protocol Requirements 2726 The DSL line configuration capability is assigned capability type 2727 0x0002. No capability data is associated with this capability. 2729 7.2.1. Protocol Requirements On the NAS Side 2731 The NAS-side ANCP agent MUST be able to create DSL-specific Port 2732 Management (line configuration) messages according to the format 2733 specified in Section 7.3. 2735 The NAS-side ANCP agent MUST conform to the normative requirements of 2736 Section 5.1.2. 2738 The NAS-side ANCP agent MUST follow the NAS-side procedures 2739 associated with DSL-specific Port Management (line configuration) 2740 messages as they are specified in Section 7.4. 2742 7.2.2. Protocol Requirements On the AN Side 2744 The AN-side ANCP agent MUST conform to the normative requirements of 2745 Section 5.1.2. 2747 The AN-side ANCP agent MUST be able to receive and validate DSL- 2748 specific Port Management (line configuration) messages according to 2749 the format specified in Section 7.3. 2751 The AN-side ANCP agent MUST follow the AN-side procedures associated 2752 with DSL-specific Port Management (line configuration) messages as 2753 specified in Section 7.4. 2755 7.3. ANCP Port Management (Line Configuration) Message Format 2757 The ANCP Port Management message for DSL line configuration has the 2758 format shown in Figure 19. 2760 0 1 2 3 2761 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 2762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2763 | TCP/IP Encapsulating Header (Section 3.2) | 2764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2765 | ANCP General Message Header | 2766 + (Section 3.6.1) + 2767 | | 2768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2769 | | 2770 ~ Unused (12 bytes) ~ 2771 | | 2772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2773 | Unused (2 bytes) | Function=8 | X-Function=0 | 2774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2775 | Unused (4 bytes) | 2776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2777 |x|x|x|x|x|x|x|x| Message Type | Reserved | 2778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2779 | # of TLVs | Extension Block length (bytes) | 2780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2781 | | 2782 ~ Access line identifying TLV(s) ~ 2783 | | 2784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2785 | | 2786 ~ Line configuration TLV(s) ~ 2787 | | 2788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2790 NOTE: TLVs MAY be in a different order from what is shown in this 2791 figure. 2793 Figure 19: Port Management Message For DSL Line Configuration 2795 See Section 3.6 for a description of the ANCP general message header. 2797 The Message Type field MUST be set to 32. The 12 bit Result Code 2798 field MUST be set to 0x0. The 4 bit Result field MUST be set to 2799 either 1 (NAck) or 2 (AckAll), as determined by policy on the NAS. 2800 The 24-bit Transaction Identifier field MUST be set to a positive 2801 value. Other fields in the general header MUST be set as described 2802 in Section 3.6. 2804 The handling of the various unused/reserved fields is described in 2805 Section 3.4. 2807 The remaining message fields are described as follows: 2809 Function: action to be performed. For line configuration, Function 2810 MUST be set to 8 (Configure Connection Service Data). This action 2811 type requests the Access Node (i.e., DSLAM) to apply service 2812 configuration data contained in the line configuration TLVs to the 2813 DSL line designated by the access line identifying TLVs. 2815 X-Function: qualifies the action set by Function. For DSL line 2816 configuration, this field MUST be set to 0. 2818 Extension Flags: the flag bits denoted by 'x' before the Message 2819 Type field are reserved for future use. 2821 Message Type: Message Type has the same value as in the general 2822 header (i.e., 32). 2824 Reserved (16 bits): reserved for future use. 2826 # of TLVs: the number of TLVs that follow, not counting TLVs 2827 encapsulated within other TLVs. 2829 Extension Block Length: the total length of the TLVs carried in the 2830 extension block in bytes, including any padding within individual 2831 TLVs. 2833 TLVs: two or more TLVs to identify a DSL line and configure its 2834 service data. 2836 Other ANCP capabilities, either specific to DSL or technology- 2837 independent, MAY reuse the Port Management message for service 2838 configuration. If the settings of the fixed fields are compatible 2839 with the settings just described, the same Port Management message 2840 that is used for DSL line configuration MAY be used to carry TLVs 2841 relating to the other capabilities that apply to the same DSL loop. 2843 Use of the Port Management message for configuration MAY also be 2844 generalized to other access technologies, if the respective 2845 capabilities specify use of access line identifiers appropriate to 2846 those technologies in place of the identifiers defined in 2847 Section 5.1.2. 2849 7.4. Procedures 2851 Service configuration MAY be performed on an access line regardless 2852 of its current state. 2854 7.4.1. Procedures On the NAS Side 2856 When requested by the NAS control application and presented with the 2857 necessary information to do so, the NAS-side agent MUST create and 2858 send a Port Management message with the fixed fields set as described 2859 in the previous section. The message MUST contain one or more TLVs 2860 to identify an access line according the requirements of 2861 Section 5.1.2. The NAS MUST include one or more TLVs to configure 2862 line service parameters for that line. Section 7.5 currently 2863 identifies only one such TLV, Service-Profile-Name, but other TLVs 2864 MAY be added by extensions to ANCP. 2866 7.4.2. Procedures On the AN Side 2868 The AN-side ANCP agent MUST be prepared to receive Port Management 2869 (line configuration) messages for a given DSL loop or logical port at 2870 any time after negotiation of an adjacency has been completed. 2872 The AN-side ANCP agent SHOULD validate each message against the 2873 specifications given in Section 7.3 and the TLV specifications given 2874 in Section 5.1.2 and Section 7.5. If it finds an error it MUST 2875 return a Port Management response message which copies the Port 2876 Management request as it was received, but has the Result header 2877 field set to 0x04 (Failure) and the Result Code field set to the 2878 appropriate value. The AN-side agent MAY add a Status-Info TLV 2879 (Section 4.5) to provide further information on the error, 2880 particularly if this is recommended in Section 3.6.1.4 for the given 2881 Result Code value. If it does so, the various length fields and the 2882 # of TLVs field within the message MUST be adjusted accordingly. 2884 If the received message passes validation, the AN-side ANCP agent 2885 "must" extract the information from the TLVs contained in the message 2886 and present that information to the AN control application. In 2887 addition, if the Result header field was set to 0x2 (AckAll) in the 2888 original request, the AN-side agent "must" indicate to the AN control 2889 application that a response is required. When the AN control 2890 application indicates that it has processed the request successfully, 2891 the AN-side agent MUST return a Port Management response message 2892 which duplicates the request except that the Result header field is 2893 set to 0x3 (Success). (The Result Code field, as in the original 2894 request, has value 0.) 2896 7.5. TLVs For DSL Line Configuration 2898 Currently only the following TLV is specified for DSL line 2899 configuration. More TLVs may be defined in a future version of this 2900 specification or in ANCP extensions for individual service attributes 2901 of a DSL line (e.g. rates, interleaving delay, multicast channel 2902 entitlement access-list). 2904 7.5.1. Service-Profile-Name TLV 2906 Type: 0x0005 2908 Description: Reference to a pre-configured profile on the DSLAM that 2909 contains service specific data for the subscriber. 2911 Length: up to 64 bytes 2913 Value: ASCII string containing the profile name (which the NAS 2914 learns from a policy server after a subscriber is authorized). 2916 8. ANCP-Based DSL Remote Line Connectivity Testing 2918 The use case and requirements for ANCP-Based DSL remote line 2919 connectivity testing are specified in Section 3.3 of [RFC5851] 2921 8.1. Control Context (Informative) 2923 The NAS control application initiates a request for remote 2924 connectivity testing for a given access loop. The NAS control 2925 application can provide loop count and timeout test parameters and 2926 opaque data for its own use with the request. The loop count 2927 parameter indicates the number of test messages or cells to be used. 2928 The timeout parameter indicates the longest that the NAS control 2929 application will wait for a result. 2931 The request is passed in a Port Management (OAM) message. If the NAS 2932 control application has supplied test parameters, they are used, 2933 otherwise the AN control application uses default test parameters. 2934 If a loop count parameter provided by the NAS is outside the valid 2935 range, the AN does not execute the test, but returns a result 2936 indicating that the test has failed due to an invalid parameter. If 2937 the test takes longer than the timeout value (default or provided by 2938 the NAS) the AN control application can return a failure result 2939 indicating timeout or else can send no response. The AN control 2940 application can provide a human-readable string describing the test 2941 results, for both failures and successes. If provided, this string 2942 is included in the response. Responses always include the opaque 2943 data, if any, provided by the NAS control application. 2945 Figure 20 summarizes the interaction. 2947 +-------------+ +-----+ +-------+ +----------------+ 2948 |Radius/AAA |----|NAS |-------| DSLAM |-----------| CPE | 2949 |Policy Server| +-----+ +-------+ | (DSL Modem + | 2950 +-------------+ |Routing Gateway)| 2951 +----------------+ 2952 Port Management Message 2953 (Remote Loopback ATM loopback 2954 Trigger Request) OR EFM Loopback 2955 1. ----------------> 2. ---------> 2956 <--------+ 2957 3. <--------------- 2958 Port Management Message 2959 (Remote Loopback Test Response) 2961 Figure 20: Message Flow For ANCP based OAM 2963 8.2. Protocol Requirements 2965 The DSL remote line connectivity testing capability is assigned 2966 capability type 0x0004. No capability data is associated with this 2967 capability. 2969 8.2.1. Protocol Requirements On the NAS Side 2971 The NAS-side ANCP agent MUST be able to create DSL-specific Port 2972 Management (OAM) messages according to the format specified in 2973 Section 8.3. 2975 The NAS-side ANCP agent MUST conform to the normative requirements of 2976 Section 5.1.2. 2978 The NAS-side ANCP agent MUST follow the NAS-side procedures 2979 associated with DSL-specific Port Management (OAM) messages as they 2980 are specified in Section 8.4. 2982 8.2.2. Protocol Requirements On the AN Side 2984 The AN-side ANCP agent MUST conform to the normative requirements of 2985 Section 5.1.2. 2987 The AN-side ANCP agent MUST be able to receive and validate DSL- 2988 specific Port Management (OAM) messages according to the format 2989 specified in Section 8.3. 2991 The AN-side ANCP agent MUST follow the AN-side procedures associated 2992 with DSL-specific Port Management (OAM) messages as specified in 2993 Section 8.4. 2995 8.3. Port Management (OAM) Message Format 2997 The Port Management message for DSL line testing has the same format 2998 as for DSL line configuration (see Section 7.3), with the following 2999 differences: 3001 o The Result field in the request SHOULD be set to AckAll (0x1), to 3002 allow the NAS to receive the information contained in a successful 3003 test response. 3005 o The Function field MUST be set to 9 (Remote Loopback). (The 3006 X-Function field continues to be 0.) 3008 o The appended TLVs in the extension value field include testing- 3009 related TLVs rather than subcriber service information. 3011 The Port Management (OAM) message is illustrated in Figure 21. 3013 0 1 2 3 3014 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 3015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3016 | TCP/IP Encapsulating Header (Section 3.2) | 3017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3018 | ANCP General Message Header | 3019 + (Section 3.6.1) + 3020 | | 3021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3022 | Port (unused) | 3023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3024 | Port Session Number (unused) | 3025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3026 | Event Sequence Number (unused) | 3027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3028 |R|x|x|x|x|x|x|x| Dur. (unused) | Function=9 | X-Function=0 | 3029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3030 | Event Flags (unused) | Flow Control Flags (unused) | 3031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3032 |x|x|x|x|x|x|x|x| Message Type | Reserved | 3033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3034 | # of TLVs | Extension Block length (bytes) | 3035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3036 | | 3037 ~ Access line identifying TLV(s) ~ 3038 | | 3039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3040 | | 3041 ~ Testing-related TLVs ~ 3042 | | 3043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3045 NOTE: TLVs MAY be in a different order from what is shown in this 3046 figure. 3048 Figure 21: Port Management Message For DSL Line Remote Connectivity 3049 Testing 3051 8.4. Procedures 3053 From the point of view of ANCP, it is permissible to attempt line 3054 connectivity testing regardless of the state of the line. However, 3055 testing could fail in some states due to technology limitations. 3057 8.4.1. NAS-Side Procedures 3059 When requested by the NAS control application and presented with the 3060 necessary information to do so, the NAS-side agent creates and sends 3061 a Port Management (OAM) request with the fixed fields set as 3062 described in the previous section. The message MUST contain one or 3063 more TLVs to identify an access line according the requirements of 3064 Section 5.1.2. The NAS MAY include the Opaque-Data TLV and/or the 3065 OAM-Loopback-Test-Parameters TLV (defined in Section 8.5) to 3066 configure the loopback test for that line. 3068 8.4.2. AN-Side Procedures 3070 The AN-side ANCP agent SHOULD validate each message against the 3071 specifications given in Section 8.3 and the TLV specifications given 3072 in Section 5.1.2 and Section 8.5. If it finds an error it MUST 3073 return a Port Management response message which copies the Port 3074 Management request as it was received, but has the Result header 3075 field set to 0x04 (Failure) and the Result Code field set to the 3076 appropriate value. Result Code value 0x509 as described below MAY 3077 apply, as well as the other Result Code values documented in 3078 Section 3.6.1.4. Result Code value 0x509 SHOULD be used if the OAM- 3079 Loopback-Test-Parameters TLV is present with an invalid value of the 3080 Count field. The AN-side agent MAY add a Status-Info TLV 3081 (Section 4.5) to provide further information on the error, 3082 particularly if this is recommended in Section 3.6.1.4 for the given 3083 Result Code value. If it does so, the various length fields and the 3084 # of TLVs field within the message MUST be adjusted accordingly. 3086 If the received message passes validation, the AN-side ANCP agent 3087 extracts the information from the TLVs contained in the message and 3088 presents that information to the AN control application. It MUST NOT 3089 generate an immediate response to the request, but MUST instead wait 3090 for the AN control application to indicate that the response should 3091 be sent. 3093 When requested by the AN control application and presented with the 3094 necessary information to do so, the AN-side agent creates and sends a 3095 Port Management (OAM) response to the original request. The Result 3096 field MUST be set to Success (0x3) or Failure (0x4), and the Result 3097 Code field SHOULD be set to one of the following values, as indicated 3098 by the AN control application. 3100 0x500: Specified access line does not exist. See the documentation 3101 of Result Code 0x500 in Section 3.6.1.4 for more information. The 3102 Result header field MUST be set to Failure (0x4). 3104 0x501: Loopback test timed out. The Result header field MUST be set 3105 to Failure (0x4). 3107 0x503: DSL line status showtime 3109 0x504: DSL line status idle 3111 0x505: DSL line status silent 3113 0x506: DSL line status training 3115 0x507: DSL line integrity error 3117 0x508: DSLAM resource not available. The Result header field MUST 3118 be set to Failure (0x04). 3120 0x509: Invalid test parameter. The Result header field MUST be set 3121 to Failure (0x4). 3123 All other fields of the request including the TLVs MUST be copied 3124 into the response unchanged, except that in a successful response the 3125 OAM-Loopback-Test-Parameters TLV MUST NOT appear. If the AN control 3126 application has provided the necessary information, the AN-side agent 3127 MUST also include an instance of the OAM-Loopback-Test-Response- 3128 String TLV in the response. 3130 8.5. TLVs For the DSL Line Remote Connectivity Testing Capability 3132 The following TLVs have been defined for use with the DSL line 3133 testing capability. 3135 8.5.1. OAM-Loopback-Test-Parameters TLV 3137 Type: 0x0007 3139 Description: Parameters intended to override the default values for 3140 this loopback test. 3142 Length: 2 bytes 3144 Value: two unsigned 1 byte fields described below (listed in order 3145 of most to least significant). 3147 Byte 1: Count. Number of loopback cells/messages that should 3148 be generated on the local loop as part of the loopback test. 3149 The Count value SHOULD be greater than 0 and less than or equal 3150 to 32. 3152 Byte 2: Timeout. Upper bound on the time in seconds that the 3153 NAS will wait for a response from the DSLAM. The value 0 MAY 3154 be used to indicate that the DSLAM MUST use a locally 3155 determined value for the timeout. 3157 The OAM-Loopback-Test-Parameters TLV is illustrated in Figure 22 3159 0 1 2 3 3160 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 3161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3162 | TLV Type = 0x0007 | Length = 2 | 3163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3164 | Count | Timeout | Padding (=0) | 3165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3167 Figure 22: The OAM-Loopback-Test-Parameters TLV 3169 8.5.2. Opaque-Data TLV 3171 Type: 0x0008 3173 Description: An 8 byte opaque field used by the NAS control 3174 application for its own purposes (e.g., response correlation.) 3175 The procedures in Section 8.4.2 ensure that if it is present in 3176 the request it is copied unchanged to the response. 3178 Length: 8 bytes 3180 Value: Two 32 bit unsigned integers. 3182 8.5.3. OAM-Loopback-Test-Response-String TLV 3184 Type: 0x0009 3186 Description: Suitably formatted string containing useful details 3187 about the test that the NAS will display for the operator, exactly 3188 as received from the DSLAM (no manipulation or interpretation by 3189 the NAS). 3191 Length: up to 128 bytes 3193 Value: UTF-8 encoded string of text. 3195 9. IANA Considerations 3197 IANA NOTE: please replace "RFCXXXX" with the number of this 3198 specification. 3200 9.1. Summary 3202 This section requests the following IANA actions: 3204 o establishment of the following new ANCP registries: 3206 ANCP Message Types; 3208 ANCP Result Codes; 3210 ANCP Port Management Functions; 3212 ANCP Technology Types; 3214 ANCP Command Codes; 3216 ANCP TLV Types; 3218 ANCP Capabilities. 3220 o establishment of a new joint GSMP/ANCP version registry; 3222 o addition of ANCP as another user of TCP port 6068 in the port 3223 number registry at http://www.iana.org/assignments/port-numbers. 3224 The current user is GSMP. 3226 All of these actions are described in detail below except for the 3227 port registration, for which the final point above should provide 3228 sufficient information. 3230 9.2. IANA Actions 3232 9.2.1. ANCP Message Type Registry 3234 IANA is requested to create a new registry, Access Network Control 3235 Protocol (ANCP) Message Types. Additions to that registry are 3236 permitted by Standards Action, as defined by [RFC5226]. The values 3237 for Message Type MAY range from 0 to 255, but new Message Types 3238 SHOULD be assigned values sequentially from 90 onwards (noting that 3239 91 and 93 are already assigned). The initial contents of the ANCP 3240 Message Types registry are as follows: 3242 +--------------+--------------------+-----------+ 3243 | Message Type | Message Name | Reference | 3244 +--------------+--------------------+-----------+ 3245 | 10 | Adjacency Protocol | RFCXXXX | 3246 | 32 | Port Management | RFCXXXX | 3247 | 80 | Port Up | RFCXXXX | 3248 | 81 | Port Down | RFCXXXX | 3249 | 85 | Adjacency Update | RFCXXXX | 3250 | 91 | Generic Response | RFCXXXX | 3251 | 93 | Provisioning | RFCXXXX | 3252 +--------------+--------------------+-----------+ 3254 9.2.2. ANCP Result Code Registry 3256 IANA is requested to create a new registry, Access Network Control 3257 Protocol (ANCP) Result Codes. The documentation of new Result Codes 3258 MUST include the following information: 3260 o Result Code value TBD (as assigned by IANA); 3262 o One-line description; 3264 o Where condition detected: (control application or ANCP agent); 3266 o Further description (if any); 3268 o Required additional information in the response message; 3270 o Target (control application or ANCP agent at the peer that sent 3271 the original request); 3273 o Action RECOMMENDED for the receiving ANCP agent 3275 The values for Result Code are expressed in hexadecimal, and MAY 3276 range from 0x0 to 0xFFFFFF. The range 0x0 to 0xFFF is reserved for 3277 allocation by the criterion of IETF Review, as defined by [RFC5226]. 3278 IANA SHOULD allocate new Result Code values from this range 3279 sequentially beginning at 0x100. The range 0x1000 onwards is 3280 allocated by the criterion of Specification Required, as defined by 3281 [RFC5226]. IANA SHOULD allocate new Result Code values from this 3282 range sequentially beginning at 0x1000. The initial contents of the 3283 ANCP Message Types registry are as follows: 3285 +------------+------------------------------------------+-----------+ 3286 | Result | One-line description | Reference | 3287 | Code | | | 3288 +------------+------------------------------------------+-----------+ 3289 | 0x0 | No result | RFCXXXX | 3290 | 0x2 | Invalid request message | RFCXXXX | 3291 | 0x6 | One or more of the specified ports are | RFCXXXX | 3292 | | down | | 3293 | 0x13 | Out of resources | RFCXXXX | 3294 | 0x51 | Request message type not implemented | RFCXXXX | 3295 | 0x53 | Malformed message | RFCXXXX | 3296 | 0x54 | Mandatory TLV missing | RFCXXXX | 3297 | 0x55 | Invalid TLV contents | RFCXXXX | 3298 | 0x500 | One or more of the specified ports do | RFCXXXX | 3299 | | not exist | | 3300 | 0x501 | Loopback test timed out (0x501) | RFCXXXX | 3301 | 0x502 | Reserved (0x502) | RFCXXXX | 3302 | 0x503 | DSL line status showtime (0x503) | RFCXXXX | 3303 | 0x504 | DSL line status idle (0x504) | RFCXXXX | 3304 | 0x505 | DSL line status silent (0x505) | RFCXXXX | 3305 | 0x506 | DSL line status training (0x506) | RFCXXXX | 3306 | 0x507 | DSL line integrity error (0x507) | RFCXXXX | 3307 | 0x508 | DSLAM resource not available (0x508) | RFCXXXX | 3308 | 0x509 | Invalid test parameter (0x509) | RFCXXXX | 3309 +------------+------------------------------------------+-----------+ 3311 9.2.3. ANCP Port Management Function Registry 3313 IANA is requested to create a new Access Network Control Protocol 3314 (ANCP) Port Management Function registry, with the following initial 3315 entries. Additions to this registry will be by Standards Action, as 3316 defined by [RFC5226]. Values may range from 0 to 255. IANA SHOULD 3317 assign values sequentially beginning with 1, taking account of the 3318 values already assigned below. 3320 NOTE: future extensions of ANCP may need to establish sub- 3321 registries of permitted X-Function values for specific values of 3322 Function. 3324 +----------------+-----------------------------------+-----------+ 3325 | Function Value | Function Name | Reference | 3326 +----------------+-----------------------------------+-----------+ 3327 | 0 | Reserved | RFCXXXX | 3328 | 8 | Configure Connection Service Data | RFCXXXX | 3329 | 9 | Remote Loopback | RFCXXXX | 3330 +----------------+-----------------------------------+-----------+ 3332 9.2.4. ANCP Technology Type Registry 3334 IANA is requested to create a new Access Network Control Protocol 3335 (ANCP) Technology Type registry, with additions by Expert Review, as 3336 defined by [RFC5226]. The Technology Type MUST designate a distinct 3337 access transport technology. Values may range from 0 to 255. IANA 3338 SHOULD assign new values sequentially beginning at 2, taking into 3339 account of the values already assigned below. The initial entries 3340 are as follows: 3342 +-----------------+--------------------------+-----------+ 3343 | Tech Type Value | Tech Type Name | Reference | 3344 +-----------------+--------------------------+-----------+ 3345 | 0 | Not technology dependent | RFCXXXX | 3346 | 1 | PON | RFCXXXX | 3347 | 5 | DSL | RFCXXXX | 3348 | 255 | Reserved | RFCXXXX | 3349 +-----------------+--------------------------+-----------+ 3351 9.2.5. ANCP Command Code Registry 3353 IANA is requested to create a new Access Network Control Protocol 3354 (ANCP) Command Code registry, with additions by Standards Action, as 3355 defined by [RFC5226]. Values may range from 0 to 255. IANA SHOULD 3356 assign new values sequentially beginning with 1. The initial entry 3357 is as follows: 3359 +--------------------+-----------------------------+-----------+ 3360 | Command Code Value | Command Code Directive Name | Reference | 3361 +--------------------+-----------------------------+-----------+ 3362 | 0 | Reserved | RFCXXXX | 3363 +--------------------+-----------------------------+-----------+ 3365 9.2.6. ANCP TLV Type Registry 3367 IANA is requested to create a new Access Network Control Protocol 3368 (ANCP) TLV Type registry. Values are expressed in hexadecimal and 3369 may range from 0x0000 to 0xFFFF. Additions in the range 0x0000 to 3370 0x1FFF are by IETF Review, as defined by [RFC5226]. IANA SHOULD 3371 assign new values in this range sequentially beginning at 0x100 and 3372 taking account of the assignments already made below. Additions in 3373 the range 0x2000 to 0xFFFF are by Specification Required, again as 3374 defined by [RFC5226]. IANA SHOULD assign new values in this range 3375 sequentially beginning at 0x2000. In both cases, the documentation 3376 of the TLV MUST provide: 3378 o a TLV name following the convention used for the initial entries 3379 (capitalized words separated by hyphens); 3381 o a brief description of the intended use; 3383 o a precise description of the contents of each fixed field, 3384 including its length, type, and units (if applicable); 3386 o identification of any mandatory encapsulated TLVs; 3388 o an indication of whether optional TLVs may be encapsulated, with 3389 whatever information is available on their identity (could range 3390 from a general class of information to specific TLV names, 3391 depending on the nature of the TLV being defined. 3393 The initial entries are as follows: 3395 +----------+--------------------------------------------+-----------+ 3396 | Type | TLV Name | Reference | 3397 | Code | | | 3398 +----------+--------------------------------------------+-----------+ 3399 | 0x0000 | Reserved | RFCXXXX | 3400 | 0x0001 | Access-Loop-Circuit-ID | RFCXXXX | 3401 | 0x0002 | Access-Loop-Remote-Id | RFCXXXX | 3402 | 0x0003 | Access-Aggregation-Circuit-ID-ASCII | RFCXXXX | 3403 | 0x0004 | DSL-Line-Attributes | RFCXXXX | 3404 | 0x0005 | Service-Profile-Name | RFCXXXX | 3405 | 0x0006 | Access-Aggregation-Circuit-ID-Binary | RFCXXXX | 3406 | 0x0007 | OAM-Loopback-Test-Parameters | RFCXXXX | 3407 | 0x0008 | Opaque-Data | RFCXXXX | 3408 | 0x0009 | OAM-Loopback-Test-Response-String | RFCXXXX | 3409 | 0x0011 | Command | RFCXXXX | 3410 | 0x0081 | Actual-Net-Data-Upstream | RFCXXXX | 3411 | 0x0082 | Actual-Net-Data-Rate-Downstream | RFCXXXX | 3412 | 0x0083 | Minimum-Net-Data-Rate-Upstream | RFCXXXX | 3413 | 0x0084 | Minimum-Net-Data-Rate-Downstream | RFCXXXX | 3414 | 0x0085 | Attainable-Net-Data-Rate-Upstream | RFCXXXX | 3415 | 0x0086 | Attainable-Net-Data-Rate-Downstream | RFCXXXX | 3416 | 0x0087 | Maximum-Net-Data-Rate-Upstream | RFCXXXX | 3417 | 0x0088 | Maximum-Net-Data-Rate-Downstream | RFCXXXX | 3418 | 0x0089 | Minimum-Net-Low-Power-Data-Rate-Upstream | RFCXXXX | 3419 | 0x008A | Minimum-Net-Low-Power-Data-Rate-Downstream | RFCXXXX | 3420 | 0x008B | Maximum-Interleaving-Delay-Upstream | RFCXXXX | 3421 | 0x008C | Actual-Interleaving-Delay-Upstream | RFCXXXX | 3422 | 0x008D | Maximum-Interleaving-Delay-Downstream | RFCXXXX | 3423 | 0x008E | Actual-Interleaving-Delay-Downstream | RFCXXXX | 3424 | 0x008F | DSL-Line-State | RFCXXXX | 3425 | 0x0090 | Access-Loop-Encapsulation | RFCXXXX | 3426 | 0x0091 | DSL-Type | RFCXXXX | 3427 | 0x0106 | Status-Info | RFCXXXX | 3428 | 0x1000 | Target (single access line variant) | RFCXXXX | 3429 | 0x1001 - | Reserved for Target variants | RFCXXXX | 3430 | 0x1020 | | | 3431 +----------+--------------------------------------------+-----------+ 3433 9.2.7. ANCP Capability Type Registry 3435 IANA is requested to create a new Access Network Control Protocol 3436 (ANCP) Capability Type registry, with additions by Standards Action 3437 as defined by [RFC5226]. Values may range from 0 to 255. IANA 3438 SHOULD assign values sequentially beginning at 5. The specification 3439 for a given capability MUST indicate the Technology Type value with 3440 which it is associated. The specification MUST further indicate 3441 whether the capability is associated with any capability data. 3442 Normally a capability is expected to be defined in the same document 3443 that specifies the implementation of that capability in protocol 3444 terms. The initial entries in the ANCP capability registry are as 3445 follows: 3447 +-------+------------------------+--------+-------------+-----------+ 3448 | Value | Capability Type Name | Tech | Capability | Reference | 3449 | | | Type | Data? | | 3450 +-------+------------------------+--------+-------------+-----------+ 3451 | 0 | Reserved | | | RFCXXXX | 3452 | 1 | DSL Topology Discovery | 5 | No | RFCXXXX | 3453 | 2 | DSL Line Configuration | 5 | No | RFCXXXX | 3454 | 3 | Reserved | | | RFCXXXX | 3455 | 4 | DSL Line Testing | 5 | No | RFCXXXX | 3456 +-------+------------------------+--------+-------------+-----------+ 3458 9.2.8. Joint GSMP / ANCP Version Registry 3460 IANA is requested to create a new joint GSMP / ANCP Version registry. 3461 Additions to this registry are by Standards Action as defined by 3462 [RFC5226]. Values may range from 0 to 255. Values for the General 3463 Switch Management Protocol (GSMP) MUST be assigned sequentially 3464 beginning with 4 for the next version. Values for the Access Network 3465 Control Protocol (ANCP) MUST be assigned sequentially beginning with 3466 50 for the present version. The initial entries are as follows: 3468 +---------+----------------+-----------+ 3469 | Version | Description | Reference | 3470 +---------+----------------+-----------+ 3471 | 1 | GSMP Version 1 | RFC1987 | 3472 | 2 | GSMP Version 2 | RFC2297 | 3473 | 3 | GSMP Version 3 | RFC3292 | 3474 | 50 | ANCP Version 1 | RFCXXXX | 3475 +---------+----------------+-----------+ 3477 10. Security Considerations 3479 Security of the ANCP protocol is discussed in [RFC5713]. A number of 3480 security requirements on ANCP are stated in Section 8 of that 3481 document. Those applicable to ANCP itself are copied to the present 3482 document: 3484 o The protocol solution MUST offer authentication of the AN to the 3485 NAS. 3487 o The protocol solution MUST offer authentication of the NAS to the 3488 AN. 3490 o The protocol solution MUST allow authorization to take place at 3491 the NAS and the AN. 3493 o The protocol solution MUST offer replay protection. 3495 o The protocol solution MUST provide data-origin authentication. 3497 o The protocol solution MUST be robust against denial-of-service 3498 (DoS) attacks. In this context, the protocol solution MUST 3499 consider a specific mechanism for the DoS that the user might 3500 create by sending many IGMP messages. 3502 o The protocol solution SHOULD offer confidentiality protection. 3504 o The protocol solution SHOULD ensure that operations in default 3505 configuration guarantees a low number of AN/NAS protocol 3506 interactions. 3508 Most of these requirements relate to secure transport of ANCP. 3509 Robustness against denial-of-service attacks partly depends on 3510 transport and partly on protocol design. Ensuring a low number of 3511 AN/NAS protocol interactions in default mode is purely a matter of 3512 protocol design. 3514 For secure transport, either the combination of IPsec with IKEv2 3515 (references below) or the use of TLS [RFC5246] will meet the 3516 requirements listed above. However, the use of TLS has been 3517 rejected. The deciding point is a detail of protocol design that was 3518 unavailable when [RFC5713] was written. The ANCP adjacency is a 3519 major point of vulnerability for denial-of-service attacks. If the 3520 adjacency can be shut down, either the AN clears its state pending 3521 reestablishment of the adjacency, or the possibility of mismatches 3522 between the AN's and NAS's view of state on the AN is opened up. Two 3523 ways to cause an adjacency to be taken down are to modify messages so 3524 that the ANCP agents conclude that they are no longer synchronized, 3525 or to attack the underlying TCP session. TLS will protect message 3526 contents, but not the TCP connection. One has to use either IPsec or 3527 the TCP authentication option [RFC5925] for that. Hence the 3528 conclusion that ANCP MUST run over IPsec with IKEv2 for 3529 authentication and key management. 3531 In greater detail: the ANCP stack MUST include IPsec [RFC4301] 3532 running in transport mode, since the AN and NAS are the endpoints of 3533 the path. The Encapsulating Security Payload (ESP) [RFC4303] MUST be 3534 used, in order to satisfy the requirement for data confidentiality. 3535 ESP MUST be configured for the combination of confidentiality, 3536 integrity, anti-replay capability. The traffic flow confidentiality 3537 service of ESP is unnecessary and, in fact, unworkable in the case of 3538 ANCP. 3540 IKEv2 [RFC5996] is also REQUIRED, to meet the requirements for mutual 3541 authentication and authorization. Since the NAS and AN MAY be in 3542 different trust domains, the use of certificates for mutual 3543 authentication could be the most practical approach. However, this 3544 is up to the operator(s) concerned. 3546 The AN MUST play the role of initiator of the IKEv2 conversation. 3548 11. Acknowledgements 3550 The authors would like to thank everyone who provided comments or 3551 inputs to this document. Swami Subramanian was an early member of 3552 the authors' team. The ANCP Working Group is grateful to Roberta 3553 Maglione, who served as design team member and primary editor of this 3554 document for two years before stepping down. The authors acknowledge 3555 the inputs provided by Wojciech Dec, Peter Arberg, Josef Froehler, 3556 Derek Harkness, Kim Hyldgaard, Sandy Ng, Robert Peschi, and Michel 3557 Platnic, and the further comments provided by Mykyta Yevstifeyev, 3558 Brian Carter, Ben Campbell, Alexey Melnikov, Adrian Farrel, Robert 3559 Sparks, Peter St. Andre, Sean Turner, and Dan Romascanu. 3561 12. References 3563 12.1. Normative References 3565 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3566 Requirement Levels", BCP 14, RFC 2119, March 1997. 3568 [RFC3292] Doria, A., Hellstrand, F., Sundell, K., and T. Worster, 3569 "General Switch Management Protocol (GSMP) V3", RFC 3292, 3570 June 2002. 3572 [RFC3293] Worster, T., Doria, A., and J. Buerkle, "General Switch 3573 Management Protocol (GSMP) Packet Encapsulations for 3574 Asynchronous Transfer Mode (ATM), Ethernet and 3575 Transmission Control Protocol (TCP)", RFC 3293, June 2002. 3577 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 3578 10646", STD 63, RFC 3629, November 2003. 3580 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 3581 Internet Protocol", RFC 4301, December 2005. 3583 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 3584 RFC 4303, December 2005. 3586 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 3587 Languages", BCP 47, RFC 5646, September 2009. 3589 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 3590 "Internet Key Exchange Protocol Version 2 (IKEv2)", 3591 RFC 5996, September 2010. 3593 12.2. Informative References 3595 [G.988.1] "ITU-T recommendation G.998.1, ATM-based multi-pair 3596 bonding", 2005. 3598 [G.988.2] "ITU-T recommendation G.998.2, Ethernet-based multi-pair 3599 bonding,", 2005. 3601 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 3602 RFC 2131, March 1997. 3604 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 3605 RFC 3046, January 2001. 3607 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 3608 and M. Carney, "Dynamic Host Configuration Protocol for 3609 IPv6 (DHCPv6)", RFC 3315, July 2003. 3611 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 3612 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, 3613 August 2006. 3615 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3616 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3617 May 2008. 3619 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3620 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 3622 [RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security 3623 Threats and Security Requirements for the Access Node 3624 Control Protocol (ANCP)", RFC 5713, January 2010. 3626 [RFC5851] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. 3627 Wadhwa, "Framework and Requirements for an Access Node 3628 Control Mechanism in Broadband Multi-Service Networks", 3629 RFC 5851, May 2010. 3631 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 3632 Authentication Option", RFC 5925, June 2010. 3634 [TR-058] Elias, M. and S. Ooghe, "DSL Forum TR-058, Multi-Service 3635 Architecture & Framework Requirements", September 2003. 3637 [TR-059] Anschutz, T., "DSL Forum TR-059, DSL Evolution - 3638 Architecture Requirements for the Support of QoS-Enabled 3639 IP Services", September 2003. 3641 [TR-092] DSL Forum (now the Broadband Forum), "DSL Forum TR-092, 3642 Broadband Remote access server requirements document", 3643 2005. 3645 [TR-101] Cohen et al, "Architecture & Transport: "Migration to 3646 Ethernet Based DSL Aggregation", DSL Forum TR-101", 2005. 3648 [TR-147] Voight et al, "Layer 2 Control Mechanism For Broadband 3649 Multi-Service Architectures", 2008. 3651 [US_ASCII] 3652 American National Standards Institute, "Coded Character 3653 Set - 7-bit American Standard Code for Information 3654 Interchange", ANSI X.34, 1986. 3656 Authors' Addresses 3658 Sanjay Wadhwa 3659 Alcatel-Lucent 3661 Phone: 3662 Fax: 3663 Email: sanjay.wadhwa@alcatel-lucent.com 3664 Jerome Moisand 3665 Juniper Networks 3666 10 Technology Park Drive 3667 Westford, MA 01886 3668 USA 3670 Phone: 3671 Fax: 3672 Email: jmoisand@juniper.net 3674 Thomas Haag 3675 Deutsche Telekom 3676 Heinrich-Hertz-Strasse 3-7 3677 Darmstadt, 64295 3678 Germany 3680 Phone: +49 6151 628 2088 3681 Fax: 3682 Email: haagt@telekom.de 3684 Norbert Voigt 3685 Nokia Siemens Networks 3686 Siemensallee 1 3687 Greifswald 17489 3688 Germany 3690 Email: norbert.voigt@nsn.com 3692 Tom Taylor (editor) 3693 Huawei Technologies 3694 Ottawa 3695 Canada 3697 Email: tom111.taylor@bell.net