idnits 2.17.1 draft-ietf-ancp-protocol-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([ANCP-FRAMEWORK], [RFC3292]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (February 26, 2010) is 5145 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Wadhwa 3 Internet-Draft J. Moisand 4 Intended status: Standards Track S. Subramanian 5 Expires: August 30, 2010 Juniper Networks 6 T. Haag 7 Deutsche Telekom 8 N. Voigt 9 Siemens 10 R. Maglione 11 Telecom Italia 12 February 26, 2010 14 Protocol for Access Node Control Mechanism in Broadband Networks 15 draft-ietf-ancp-protocol-09 17 Abstract 19 This document describes proposed extensions to the GSMPv3 protocol to 20 allow its use in a broadband environment, as a control plane between 21 Access Nodes (e.g. DSLAM) and Broadband Network Gateways (e.g. 22 NAS). These proposed extensions are required to realize a protocol 23 for "Access Node Control" mechanism as described in [ANCP-FRAMEWORK]. 24 The resulting protocol with the proposed extensions to GSMPv3 25 [RFC3292] is referred to as "Access Node Control Protocol" (ANCP). 26 This document currently focuses on specific use cases of access node 27 control mechanism for topology discovery, line configuration, and OAM 28 as described in ANCP framework document [ANCP-FRAMEWORK]. It is 29 intended to be augmented by additional protocol specification for 30 future use cases considered in scope by the ANCP charter. 32 ANCP framework document [ANCP-FRAMEWORK] describes the ANCP use-cases 33 in detail. Illustrative text for the use-cases is included here to 34 help the protocol implementer understand the greater context of ANCP 35 protocol interactions. 37 Status of this Memo 39 This Internet-Draft is submitted to IETF in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF), its areas, and its working groups. Note that 44 other groups may also distribute working documents as Internet- 45 Drafts. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 The list of current Internet-Drafts can be accessed at 53 http://www.ietf.org/ietf/1id-abstracts.txt. 55 The list of Internet-Draft Shadow Directories can be accessed at 56 http://www.ietf.org/shadow.html. 58 This Internet-Draft will expire on August 30, 2010. 60 Copyright Notice 62 Copyright (c) 2010 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the BSD License. 75 This document may contain material from IETF Documents or IETF 76 Contributions published or made publicly available before November 77 10, 2008. The person(s) controlling the copyright in some of this 78 material may not have granted the IETF Trust the right to allow 79 modifications of such material outside the IETF Standards Process. 80 Without obtaining an adequate license from the person(s) controlling 81 the copyright in such materials, this document may not be modified 82 outside the IETF Standards Process, and derivative works of it may 83 not be created outside the IETF Standards Process, except to format 84 it for publication as an RFC or to translate it into languages other 85 than English. 87 Table of Contents 89 1. Specification Requirements . . . . . . . . . . . . . . . . . . 4 90 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 91 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 92 3. Broadband Access Aggregation . . . . . . . . . . . . . . . . . 6 93 3.1. ATM-based broadband aggregation . . . . . . . . . . . . . 6 94 3.2. Ethernet-based broadband aggregation . . . . . . . . . . . 7 95 4. Access Node Control Protocol . . . . . . . . . . . . . . . . . 7 96 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8 97 4.2. ANCP based Access Topology Discovery . . . . . . . . . . . 8 98 4.2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 8 99 4.2.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 9 100 4.3. ANCP based Line Configuration . . . . . . . . . . . . . . 10 101 4.3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 10 102 4.3.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 11 103 4.4. ANCP based OAM . . . . . . . . . . . . . . . . . . . . . . 13 104 4.4.1. Message Flow . . . . . . . . . . . . . . . . . . . . . 13 105 5. Access Node Control Protocol (ANCP) . . . . . . . . . . . . . 14 106 5.1. ANCP/TCP connection establishment . . . . . . . . . . . . 20 107 5.2. ANCP Connection keepalive . . . . . . . . . . . . . . . . 21 108 5.3. Capability negotiation . . . . . . . . . . . . . . . . . . 22 109 5.4. GSMP Message Extensions for Access Node Control . . . . . 25 110 5.4.1. General Extensions . . . . . . . . . . . . . . . . . . 25 111 5.4.2. Topology Discovery Extensions . . . . . . . . . . . . 27 112 5.4.3. Line Configuration Extensions . . . . . . . . . . . . 37 113 5.4.4. OAM Extensions . . . . . . . . . . . . . . . . . . . . 40 114 5.4.5. Additional GSMP Extensions for future use cases . . . 43 115 5.4.5.1. General well known TLVs . . . . . . . . . . . . . 44 116 5.4.5.1.1. Target TLV . . . . . . . . . . . . . . . . . . 44 117 5.4.5.1.2. Command TLV . . . . . . . . . . . . . . . . . 45 118 5.4.5.1.3. Status-info TLV . . . . . . . . . . . . . . . 47 119 5.4.5.2. Generic Response Message . . . . . . . . . . . . . 48 120 5.5. ATM-specific considerations . . . . . . . . . . . . . . . 50 121 5.6. Ethernet-specific considerations . . . . . . . . . . . . . 50 122 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 123 7. Security Considerations . . . . . . . . . . . . . . . . . . . 56 124 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56 125 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56 126 9.1. Normative References . . . . . . . . . . . . . . . . . . . 56 127 9.2. Informative References . . . . . . . . . . . . . . . . . . 56 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57 130 1. Specification Requirements 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 2. Introduction 138 DSL is a widely deployed access technology for Broadband Access for 139 Next Generation Networks. Several specifications like [TR-059], 140 [TR-058], [TR-092] describe possible architectures for these access 141 networks. In the scope of these specifications are the delivery of 142 voice, video and data services. 144 When deploying value-added services across DSL access networks, 145 special attention regarding quality of service and service control is 146 required, which implies a tighter coordination between network 147 elements in the broadband access network without burdening the OSS 148 layer. 150 This draft defines extensions and modifications to GSMPv3 (specified 151 in [RFC3292]) and certain new mechanisms to realize a control plane 152 between a service-oriented layer 3 edge device (the NAS) and a layer2 153 Access Node (e.g. DSLAM) in order to perform QoS-related, service- 154 related and subscriber-related operations. The control protocol as a 155 result of these extensions and mechanisms is referred to as "Access 156 Node Control Protocol" (ANCP). Although ANCP is based on GSMPv3, it 157 is not interoperable with GSMPv3 defined in [RFC3292]. 159 ANCP uses the option of transporting GSMPv3 over TCP/IP. TCP 160 encapsulation for GSMPv3 is defined in [RFC3293]. GSMPv3 161 encapsulation directly over Ethernet and ATM as defined in [RFC3293] 162 is not considered for ANCP. 164 ANCP uses a subset of GSMPv3 messages to implement currently defined 165 use-cases. These relevant GSMPv3 messages are identified in section 166 Section 5. GSMPv3 procedures with suitable extensions, as used by 167 ANCP, are described in sections Section 5.1, Section 5.2 and 168 Section 5.3. GSMPv3 general extensions and GSMPv3 message specific 169 extensions required by ANCP are described in sub-sections of 170 Section 5.4. In addition to specifying extensions and modifications 171 to relevant GSMP messages applicable to ANCP, this draft also defines 172 the usage of these messages by ANCP. Not all the fields in relevant 173 GSMP messages are used by ANCP. This draft indicates the value that 174 ANCP should set for the fields in these GSMP messages. 176 At the time of writing of this specification some implementations of 177 the ANCP protocol, based on pre-standards drafts are already 178 available. All these early-draft implementations use protocol 179 version/sub-version 3.1; standard ANCP protocol will use version/ 180 sub-version 3.2 [Editor's note: sub-version needs to be changed from 181 1 to 2 upon publication.] Adopting a new sub-version value provides 182 a way to disambiguate the two protocols and allows for supporting 183 running a pre-standard and a standards compliant ANCP implementation 184 on any given ANCP node. The mechanism used to identify the protocol 185 version/sub-version is part of the adjacency negotiation process and 186 it is described in details in Section 5.2. It is important to note 187 that this mechanism does not guarantee backwards compatibility of the 188 ANCP RFC specification to those early-draft implementations. 190 2.1. Terminology 192 o Access Node (AN): Network device, usually located at a service 193 provider central office or street cabinet that terminates access 194 (local) loop connections from subscribers. In case the access 195 loop is a Digital Subscriber Line (DSL), the Access Node provides 196 DSL signal termination, and is referred to as DSL Access 197 Multiplexer (DSLAM). 199 o Network Access Server (NAS): Network element which aggregates 200 subscriber traffic from a number of Access Nodes. The NAS is an 201 injection point for policy management and IP QoS in the access 202 network. IT is also referred to as Broadband Network Gateway 203 (BNG) or Broadband Remote Access Server (BRAS). 205 o Home Gateway (HGW): Network element that connects subscriber 206 devices to the Access Node and the access network. In case of 207 DSL, the Home Gateway is a DSL network termination that could 208 either operate as a layer 2 bridge or as a layer 3 router. In the 209 latter case, such a device is also referred to as a Routing 210 Gateway (RG). 212 o Net Data Rate: portion of the total data rate of the DSL line that 213 can be used to transmit actual user information (e.g. ATM cells 214 of Ethernet frames). It excludes overhead that pertains to the 215 physical transmission mechanism (e.g. trellis coding in case of 216 DSL). This is defined in section 3.39 of ITU-T G.993.2. 218 o DSL line (synch) rate: the total data rate of the DSL line, 219 including the overhead attributable to the physical transmission 220 mechanism. 222 o DSL multi-pair bonding: method for bonding (or aggregating) 223 multiple xDSL lines into a single bi-directional logical link, 224 henceforth referred to in this draft as "DSL bonded circuit". DSL 225 "multi-pair" bonding allows an operator to combine the data rates 226 on two or more copper pairs, and deliver the aggregate data rate 227 to a single customer. ITU-T recommendations G.998.1 and G.998.2 228 respectively describe ATM and Ethernet based multi-pair bonding. 230 3. Broadband Access Aggregation 232 3.1. ATM-based broadband aggregation 234 End to end DSL network consists of network and application service 235 provider networks (NSP and ASP networks), regional/access network, 236 and customer premises network. Figure 1 shows ATM broadband access 237 network components. 239 The Regional/Access Network consists of the Regional Network, Network 240 Access Server, and the Access Network as show in Figure 1. Its 241 primary function is to provide end-to-end transport between the 242 customer premises and the NSP or ASP. The Access Node terminates the 243 DSL signal. It could consist of DSLAM in the central office, or 244 remote DSLAM, or a Remote Access Multiplexer (RAM). Access node is 245 the first point in the network where traffic on multiple DSL lines 246 will be aggregated onto a single network. The NAS performs multiple 247 functions in the network. 249 The NAS is the aggregation point for the subscriber traffic. It 250 provides aggregation capabilities (e.g. IP, PPP, ATM) between the 251 Regional/Access Network and the NSP or ASP. These include 252 traditional ATM-based offerings and newer, more native IP-based 253 services. This includes support for Point-to-Point Protocol over ATM 254 (PPPoA) and PPP over Ethernet (PPPoE), as well as direct IP services 255 encapsulated over an appropriate layer 2 transport. 257 Beyond aggregation, NAS is also the injection point for policy 258 management and IP QoS in the Regional/Access Networks. In order to 259 allow IP QoS support over an existing non-IP-aware layer 2 access 260 network without using multiple layer 2 QoS classes, a mechanism based 261 on hierarchical scheduling is used. This mechanism defined in 262 [TR-059], preserves IP QoS over the ATM network between the NAS and 263 the RGs by carefully controlling downstream traffic in the NAS, so 264 that significant queuing and congestion does not occur further down 265 the ATM network. This is achieved by using a diffserv-aware 266 hierarchical scheduler in the NAS that will account for downstream 267 trunk bandwidths and DSL synch rates. 269 [ANCP-FRAMEWORK] provides detailed definition and functions of each 270 network element in the broadband reference architecture. 272 Access Customer 273 <--- Aggregation --> <------- Premises -------> 274 Network Network 276 +------------------+ +--------------------------+ 277 +---------+ +---+ | +-----+ +------+ |-|+-----+ +---+ +---------+ | 278 NSP| | +-|NAS|-| |ATM |-|Access| | ||DSL |-|HGW|-|Subscriber|| 279 ---+ Regional| | +---+ | +-----+ | Node | | ||Modem| +---+ |Devices || 280 |Broadband| | +---+ | +------+ | |+-----+ +----------+| 281 ASP|Network |-+-|NAS| +--------------|---+ +--------------------------+ 282 ---+ | | +---+ | +--------------------------+ 283 | | | +---+ | |+-----+ +---+ +----------+| 284 +---------+ +-|NAS| +-----|| DSL |-|HGW|-|Subscriber|| 285 +---+ ||Modem| +---+ |Devices || 286 |+-----+ +----------+| 287 +--------------------------+ 288 HGW : Home Gateway 289 NAS : Network Access Server 291 Figure 1: ATM Broadband Aggregation Topology 293 3.2. Ethernet-based broadband aggregation 295 The Ethernet aggregation network architecture builds on the Ethernet 296 bridging/switching concepts defined in IEEE 802. The Ethernet 297 aggregation network provides traffic aggregation, class of service 298 distinction, and customer separation and traceability. VLAN tagging 299 defined in IEEE 802.1Q and being enhanced by IEEE 802.1ad is used as 300 standard virtualization mechanism in the Ethernet aggregation 301 network. The aggregation devices are "provider edge bridges" defined 302 in IEEE 802.ad. Stacked VLAN tags provide one possible way to create 303 equivalent of "virtual paths" and "virtual circuits" in the 304 aggregation network. The "outer" vlan could be used to create a form 305 of "virtual path" between a given DSLAM and a given NAS. And "inner" 306 VLAN tags to create a form of "virtual circuit" on a per DSL line 307 basis. This is 1:1 VLAN allocation model. An alternative model is 308 to bridge sessions from multiple subscribers behind a DSLAM into a 309 single VLAN in the aggregation network. This is N:1 VLAN allocation 310 model. Architectural and topological models of an Ethernet 311 aggregation network in context of DSL aggregation are defined in 312 [TR-101] 314 4. Access Node Control Protocol 315 4.1. Overview 317 A dedicated control protocol between NAS and access nodes can 318 facilitate "NAS managed" tight QOS control in the access network, 319 simplified OSS infrastructure for service management, optimized 320 multicast replication to enable video services over DSL, subscriber 321 statistics retrieval on the NAS for accounting purposes, and fault 322 isolation capability on the NAS for the underlying access technology. 323 This dedicated control plane is referred to as "Access Node Control 324 Protocol" (ANCP). This document specifies relevant extensions to 325 GSMPv3 as defined [RFC3292] to realize ANCP. 327 Following sections discuss the use of ANCP for implementing: 329 o Dynamic discovery of access topology by the NAS to provide tight 330 QOS control in the access network. 332 o Pushing to the access-nodes, subscriber and service data retrieved 333 by the NAS from an OSS system (e.g. radius server), to simplify 334 OSS infrastructure for service management. 336 o Optimized, "NAS controlled and managed" multicast replication by 337 access-nodes at L2 layer. 339 o NAS controlled, on-demand access-line test capability (rudimentary 340 end-to-end OAM). 342 In addition to DSL, alternate broadband access technologies (e.g. 343 Metro-Ethernet, Passive Optical Networking, WiMax) will have similar 344 challenges to address, and could benefit from the same approach of a 345 control plane between a NAS and an Access Node (e.g. OLT), providing 346 a unified control and management architecture for multiple access 347 technologies, hence facilitating migration from one to the other 348 and/or parallel deployments. 350 GSMPv3 is an ideal fit for implementing ANCP. It is extensible and 351 can be run over TCP/IP, which makes it possible to run over different 352 access technologies. 354 4.2. ANCP based Access Topology Discovery 356 4.2.1. Goals 358 [TR-059] discusses various queuing/scheduling mechanisms to avoid 359 congestion in the access network while dealing with multiple flows 360 with distinct QoS requirements. Such mechanisms require that the NAS 361 gains knowledge about the topology of the access network, the various 362 links being used and their respective net data rates. Some of the 363 information required is somewhat dynamic in nature (e.g. DSL sync 364 rate, and therefore also the net data rate), hence cannot come from a 365 provisioning and/or inventory management OSS system. Some of the 366 information varies less frequently (e.g. capacity of a DSLAM uplink), 367 but nevertheless needs to be kept strictly in sync between the actual 368 capacity of the uplink and the image the NAS has of it. 370 Following section describes ANCP messages that allow the Access Node 371 (e.g. DSLAM) to communicate to the NAS, access network topology 372 information and any corresponding updates. 374 Some of the parameters that can be communicated from the DSLAM to the 375 NAS include DSL line state, actual upstream and downstream net data 376 rates of a synchronized DSL link, maximum attainable upstream and 377 downstream net data rates, interleaving delay etc. Topology 378 discovery is specifically important in case the net data rate of the 379 DSL line changes over time. The DSL net data rate may be different 380 every time the DSL modem is turned on. Additionally, during the time 381 the DSL modem is active, data rate changes can occur due to 382 environmental conditions (the DSL line can get "out of sync" and can 383 retrain to a lower value). 385 4.2.2. Message Flow 387 When a DSL line initially comes up or resynchronizes to a different 388 rate, the DSLAM generates and transmits a GSMP PORT UP EVENT message 389 to the NAS. The extension field in the message carries the TLVs 390 containing DSL line specific parameters. On a loss of signal on the 391 DSL line, a GSMP PORT DOWN message is generated by the DSLAM to the 392 NAS. In order to provide expected service level, NAS needs to learn 393 the initial attributes of the DSL line before the subscriber can log 394 in and access the provisioned services for the subscriber. Figure 2 395 summarizes the interaction. 397 <----- Port UP(EVENT Message) <----- DSL 398 (default line parameters) Signal 400 1. NAS ------------------ Access ----------- Home ----- Subscriber 401 Node Gateway 403 <----- Port UP (EVENT Message) <----- DSL 404 (updated line parameters) Resynch 405 2. NAS ------------------ Access ----------- Home ------ Subscriber 406 Node Gateway 408 <--- Port DOWN (EVENT Message) <---- DSL 409 Loss of Signal 411 3. NAS ----------------- Access ------------- Home ----- Subscriber 412 Node Gateway 414 Figure 2: Message flow (ANCP mapping) for topology discovery 416 The Event message with PORT UP message type (80) is used for 417 conveying DSL line attributes to the NAS. This message with relevant 418 extensions is defined in section Section 5.4.2. 420 4.3. ANCP based Line Configuration 422 4.3.1. Goals 424 Following dynamic discovery of access topology (identification of DSL 425 line and its attributes) as assisted by the mechanism described in 426 the previous section (topology discovery), the NAS could then query a 427 subscriber management OSS system (e.g. RADIUS server) to retrieve 428 subscriber authorization data (service profiles, aka user 429 entitlement). Most of such service mechanisms are typically enforced 430 by the NAS itself, but there are a few cases where it might be useful 431 to push such service parameter to the DSLAM for local enforcement of 432 a mechanism (e.g. DSL-related) on the corresponding subscriber line. 433 One such example of a service parameter that can be pushed to the 434 DSLAM for local enforcement is DSL "interleaving delay". Longer 435 interleaving delay (and hence stringent error correction) is required 436 for a video service to ensure better video "quality of experience", 437 whereas for a VoIP service or for "shoot first" gaming service, a 438 very short interleaving delay is more appropriate. Another relevant 439 application is downloading per subscriber multicast channel 440 entitlement information in IPTV applications where the DSLAM is 441 performing IGMP snooping or IGMP proxy function. Using ANCP, the NAS 442 could achieve the goal of pushing line configuration to the DSLAM by 443 an interoperable and standardized protocol. 445 If a subscriber wants to choose a different service, it can require 446 an OPEX intensive reconfiguration of the line via a network operator, 447 possibly implying a business-to-business transaction between an ISP 448 and an access provider. Using ANCP for line configuration from the 449 NAS dramatically simplifies the OSS infrastructure for service 450 management, allowing fully centralized subscriber-related service 451 data (e.g. RADIUS server back-end) and avoiding complex cross- 452 organization B2B interactions. 454 The best way to change line parameters would be by using profiles. 455 These profiles (DSL profiles for different services) are pre- 456 configured on the DSLAMs. The NAS can then indicate a reference to 457 the right DSL profile via ANCP. Alternatively, discrete DSL 458 parameters can also be conveyed by the NAS in ANCP. 460 4.3.2. Message Flow 462 Triggered by topology information reporting a new DSL line or 463 triggered by a subsequent user session establishment (PPP or DHCP), 464 the NAS may send line configuration information (e.g. reference to a 465 DSL profile) to the DSLAM using GSMP Port Management messages. The 466 NAS may get such line configuration data from a policy server (e.g. 467 RADIUS). Figure 3 summarizes the interaction. 469 1.DSL Signal 470 <----------- 471 2. Port UP (EVENT Message) 472 (Access Topology Discovery) 473 <---------------- 474 3. PPP/DHCP Session 475 <-------------------------------- 476 4. Authorization 477 & Authentication 478 <------------------- 479 Port Management Message 480 (Line Configuration) 481 5. --------> 482 +----------+ +-----+ +-----+ +-------+ +-----------+ 483 |Radius/AAA|---| NAS |-----| AN |----| Home |----|Subscriber | 484 |Policy | +-----+ +-----+ |Gateway| +-----------+ 485 |Server | +-------+ 486 +----------+ 488 Figure 3: Message flow - ANCP mapping for Initial Line Configuration 490 The NAS may update the line configuration due to a subscriber service 491 change (e.g. triggered by the policy server). Figure 4 summarizes 492 the interaction. 494 1. PPP/DHCP Session 495 <------------------------------------------ 497 +-----------+ 2. Service On Demand 498 | |<----------------------------------------------- 499 | Web portal| 500 | OSS etc | 3.Change of 4.Port Management 501 | | Authorization Message 502 |Radius AAA | --------> (Updated Line 503 | Policy | Config - New Profile) 504 | | -------------> 505 | | +------+ +-------+ +---------+ +----------+ 506 | |----| NAS |-----| AN |---| Home |--|Subscriber| 507 | | +------+ +-------+ | Gateway | +----------+ 508 +-----------+ +---------+ 510 Figure 4: Message flow - ANCP mapping for Updated Line Configuration 512 The format of relevant extensions to port management message is 513 defined in section Section 5.4.3. The line configuration models 514 could be viewed as a form of delegation of authorization from the NAS 515 to the DSLAM. 517 4.4. ANCP based OAM 519 In a mixed Ethernet and ATM access network (including the local 520 loop), it is desirable to provide similar mechanisms for connectivity 521 checks and fault isolation, as those used in an ATM based 522 architecture. This can be achieved using an ANCP based mechanism 523 until end-to-end Ethernet OAM mechanisms are more widely implemented 524 in various network elements. 526 A simple solution based on ANCP can provide NAS with an access-line 527 test capability and to some extent fault isolation. Controlled by a 528 local management interface the NAS can use an ANCP operation to 529 trigger the access-node to perform a loopback test on the local-loop 530 (between the access-node and the CPE). The access-node can respond 531 via another ANCP operation the result of the triggered loopback test. 532 In case of ATM based local-loop the ANCP operation can trigger the 533 access-node to generate ATM (F4/F5) loopback cells on the local loop. 534 In case of Ethernet, the access-node can trigger an Ethernet loopback 535 message(per EFM OAM) on the local-loop. 537 4.4.1. Message Flow 539 "Port Management" message can be used by the NAS to request access 540 node to trigger a "remote loopback" test on the local loop. The 541 result of the loopback test can be asynchronously conveyed by the 542 access node to the NAS in a "Port Management" response message. The 543 format of relevant extensions to port management message is defined 544 in section The format of relevant extensions to port management 545 message is defined in section Section 5.4.4. Figure 5 summarizes the 546 interaction. 548 Port Management Message 549 (Remote Loopback ATM loopback 550 Trigger Request) OR EFM Loopback 551 1. ----------------> 2. ---------> 552 <--------+ 553 +-------------+ +-----+ +-------+ +----------------+ 554 |Radius/AAA |----|NAS |-------| DSLAM |-----------| CPE | 555 |Policy Server| +-----+ +-------+ | (DSL Modem + | 556 +-------------+ |Routing Gateway)| 557 +----------------+ 558 3. <--------------- 559 Port Management Message 560 (Remote Loopback Test Response) 562 Figure 5: Message Flow: ANCP based OAM 564 5. Access Node Control Protocol (ANCP) 566 ANCP uses a subset of GSMPv3 messages described in [RFC3292] to 567 implement currently defined use-cases. GSMPv3 general message 568 format, used by all GSMP messages other than adjacency protocol 569 messages, is defined in section 3.1.1 of GSMPv3 [RFC3292]. ANCP 570 modifies this base GSMPv3 message format. The modified GSMPv3 571 message format is defined as follows: 573 0 1 2 3 574 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 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | Vers | Sub | Message Type | Result| Code | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Partition ID | Transaction Identifier | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 |I| SubMessage Number | Length | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | | 583 ~ Message Payload ~ 584 | | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 Figure 6: Modified GSMPv3 message format 589 The 8-bit version field in the base GSMPv3 message header is split 590 into two 4 bit fields for carrying the version and a sub-version of 591 the GSMP protocol. ANCP uses version 3 and sub-version 1 of the GSMP 592 protocol. An ANCP implementation SHOULD always set the version field 593 to 3, and the sub-version field to 1. The Result field in the 594 message header has been modified to be 4 bits long, and the Code 595 field to be 12 bits long. 597 Version: 599 The version number of the GSMP protocol being used in this 600 session. ANCP uses version 3. 602 Sub-Version: 604 The sub-version number of the GSMP protocol being used in this 605 session. ANCP uses sub-version 1 of the GSMP protocol. [RFC 606 Editor's note: sub-version needs to be changed from 1 to 2 upon 607 publication] 609 Result: 611 The Result field derived from GSMP [RFC3292] has the following 612 codes: 614 Ignore: 616 Res = 0x00 - Ignore this field on receipt and follow the 617 procedures specified for the received message type. 619 Nack: 621 Res = 0x01 - Result code indicating that no response is 622 expected to the message other than in cases of failure 623 caused during the processing of the message contents or that 624 of the contained directive(s). 626 AckAll: 628 Res = 0x02 - Result code indicating that a response to the 629 message is requested in all cases. It is specifically 630 intended to be used in some cases for Request messages only, 631 and is not to be used in Event messages. 633 Success: 635 Res = 0x03 - Set by receiver to indicate successful 636 execution of all directives in the corresponding Request 637 message. 639 Failure: 641 Res = 0x4 - Set by receiver in the Response message if one 642 or more directives in the corresponding Request message 643 fails. 645 Message-Type: 647 The GSMP and ANCP message type. 649 Code: 651 This field gives further information concerning the result in a 652 response message. It is mostly used to pass an error code in a 653 failure response but can also be used to give further information 654 in a success response message or an event message. In a request 655 message, the code field is not used and is set to zero. In an 656 adjacency protocol message, the Code field is used to determine 657 the function of the message. 659 ANCP implementations MAY use any of the Code values specified in 660 the IANA registry "Global Switch Management Protocol version 3 661 (GSMPv3) Failure Response Message Name Space" if they appear 662 applicable. In particular, the values: 664 2 Invalid request message (i.e., a properly formed message which 665 violates the protocol through its timing or direction of 666 transmission) 668 4 One or more of the specified ports do not exist 670 6 One or more of the specified ports are down 672 7 Invalid Partition ID 674 19 Out of resources (e.g. memory exhausted, etc.) 676 30 The limit on the maximum number of point-to- multipoint 677 connections that the switch can support has been reached 679 31 The limit on the maximum number of branches that the specified 680 point-to-multipoint connection can support has been reached 682 may unfortunately apply to ANCP usage, including the case where 683 "Port" is interpreted to mean Target as defined in section 684 Section 5.4.5.1.1 686 Instead of the value: 688 3 The specified request is not implemented on this switch 690 specified by [RFC3292], this specification defines a new value: 692 81 Request message type not implemented 694 This value MAY be sent in a failure response from either the AN or 695 the NAS. This specification also defines the additional values: 697 82 Transaction identifier out of sequence 699 83 Malformed message 701 84 TLV or value not supported by negotiated capability set 703 ANCP extensions defining new code values SHOULD use the range 0x0100 704 through 0x01ff for this purpose. 706 The range of values from 256 to 4095 is reserved for IETF use. 708 Partition ID: 710 This field is a 8 bit number which signifies a partition on the 711 AN. 713 AN and NAS MAY agree on the partition ID using one of the 714 following possible options: 716 1 - The partition ID could be configured on the AN and learnt by 717 NAS in the adjacency message; 719 2 - The partition ID could be statically configured on the NAS as 720 part of configuring the neighbor information. 722 Transaction ID: 724 24-bit field set by the sender of a Request message to associate a 725 Response message with the original Request message. The receiver 726 of a Request message reflects the transaction ID from the Request 727 message in the corresponding Response message. For event 728 messages, the transaction identifier SHOULD be set to zero. The 729 Transaction Identifier is not used, and the field is not present, 730 in the adjacency protocol. 732 I flag: 734 An ANCP implementation SHOULD set "I" and subMessage fields to 1 735 to signify no fragmentation. 737 Length: 739 Length of the GSMP message including its header fields and defined 740 GSMP message body. 742 Additional General Message Information: 744 o Any field in a GSMP message that is unused or defined as 745 "reserved" MUST be set to zero by the sender and ignored by the 746 receiver; 748 o Flags that are undefined will be designated as: x: reserved. 750 Following are the relevant GSMPv3 messages defined in [RFC3292], that 751 are currently used by ANCP. Other than the message types explicitly 752 listed below, no other GSMPv3 messages are used by ANCP currently. 754 o Event Messages 756 * Port UP Message 758 * Port DOWN Message 760 These messages are used by ANCP topology discovery use-case. 762 o Port Management Messages 764 * These messages are used by ANCP "line configuration" use-case 765 and ANCP OAM use-case. 767 o Adjacency Protocol Messages 769 * These messages are used to bring up a protocol adjacency 770 between a NAS and an AN. 772 ANCP modifies and extends few basic GSMPv3 procedures. These 773 modifications and extensions are summarized below, and described in 774 more detail in the succeeding sections. 776 o ANCP provides support for a capability negotiation mechanism 777 between ANCP peers by extending the GSMPv3 adjacency protocol. 778 This mechanism and corresponding adjacency message extensions are 779 defined in section Section 5.3 781 o TCP connection establishment procedure in ANCP deviates slightly 782 from the connection establishment in GSMPv3 as specified in 783 [RFC3293]. This is described in section Section 5.1 785 o ANCP makes GSMPv3 messages extensible and flexible by adding a 786 general "extension block" to the end of the relevant GSMPv3 787 messages. The "extension block" contains a TLV structure to carry 788 information relevant to each ANCP use-case. The format of the 789 "extension block" is defined in section Section 5.4.1.1. 791 o 793 5.1. ANCP/TCP connection establishment 795 ANCP will use TCP for exchanging protocol messages [RFC3293]. defines 796 the GSMP message encapsulation for TCP. The TCP session is initiated 797 from the DSLAM (access node) to the NAS (controller). This is 798 necessary to avoid static provisioning on the NAS for all the DSLAMs 799 that are being served by the NAS. It is easier to configure a given 800 DSLAM with the single IP address of the NAS that serves the DSLAM. 801 This is a deviation from [RFC3293] which indicates that the 802 controller initiates the TCP connection to the switch. 804 When GSMP messages are sent over a TCP connection a four-byte TLV 805 header field is prepended to the GSMP message to provide delineation 806 of GSMP messages within the TCP stream. 808 0 1 2 3 809 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 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | Type (0x88-0C) | Length | 812 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | | 814 ~ GSMP Message ~ 815 | | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 Figure 7: GSMPv3 with TCP/IP Encapsulation message format 820 Type 822 This 2-byte field indicates the type code of the following 823 message. The type code for GSMP messages is 0x88-0C (i.e., the 824 same as GSMP's Ethertype). 826 Length 827 This 2-byte unsigned integer indicates the total length of the 828 GSMP message only. It does not include the 4-byte TLV header. 830 NAS listens for incoming connections from the access nodes. Port 831 6068 is used for TCP connection. Adjacency protocol messages, which 832 are used to synchronize the NAS and access-nodes and maintain 833 handshakes, are sent after the TCP connection is established. ANCP 834 messages other than adjacency protocol messages may be sent only 835 after the adjacency protocol has achieved synchronization. 837 In the case of ATM access, a separate PVC (control channel) capable 838 of transporting IP would be configured between NAS and the DSLAM for 839 ANCP messages. 841 In case of an Ethernet access/aggregation network, a typical practice 842 is to send the Access Node Control Protocol messages over a dedicated 843 Ethernet Virtual LAN (VLAN) using a separate VLAN identifier (VLAN 844 ID). 846 5.2. ANCP Connection keepalive 848 GSMPv3 defines an adjacency protocol. The adjacency protocol is used 849 to synchronize states across the link, to negotiate which version of 850 the GSMP protocol to use, to discover the identity of the entity at 851 the other end of a link, and to detect when it changes. GSMP is a 852 hard state protocol. It is therefore important to detect loss of 853 contact between switch and controller, and to detect any change of 854 identity of switch or controller. No protocol messages other than 855 those of the adjacency protocol may be sent across the link until the 856 adjacency protocol has achieved synchronization. There are no 857 changes to the base GSMP adjacency protocol for implementing ANCP. 859 The NAS will set the M-flag in the SYN message (signifying it is the 860 master). Once the adjacency is established, periodic adjacency 861 messages (type ACK) are exchanged. The default ACK interval as 862 advertised in the adjacency messages is 10 sec for ANCP. It SHOULD 863 be configurable and is an implementation choice. It is recommended 864 that both ends specify the same timer value, in order to achieve this 865 behavior both ends look at the timer values in the received (initial) 866 adjacency message and agree to use the higher of the two values. 867 That is, the node that receives a higher timer value than its own, 868 will reply in its subsequent adjacency messages (such as SYNACK, ACK) 869 with the higher timer value. 871 The GSMP adjacency message defined in [RFC3292] is extended for ANCP 872 and is shown in section 5.3 immediately following this section. The 873 8-bit "version" field in the adjacency protocol messages is modified 874 to carry the version and sub-version of the GSMP protocol for version 875 negotiation. ANCP uses version 3 and sub-version 1 of GSMP protocol. 876 [RFC Editor's note: sub-version needs to be changed from 1 to 2 upon 877 publication.] In the adjacency protocol the version and the sub- 878 version fields are used for version negotiation. The version 879 negotiation is performed before synchronisation is achieved. In a 880 SYN message the version/sub-version fields always contain the highest 881 version understood by the sender. A receiver receiving a SYN message 882 with a version/sub-version higher than understood will ignore that 883 message. A receiver receiving a SYN message with a version/ 884 sub-vresion lower than its own highest version/sub-version, but a 885 version/sub-version that it understands, will reply with a SYNACK 886 with the version/sub-version from the received SYN in its ANCP 887 version/sub-version fields. This defines the version/sub-version of 888 the ANCP protocol to be used while the adjacency protocol remains 889 synchronised. All other messages will use the agreed version in the 890 version/sub-version fields. 892 The semantics and suggested values for Code, "Sender Name", "Receiver 893 Name", "Sender Instance", and "Receiver Instance" fields are as 894 defined in [RFC3292]. The "Sender Port", and "Receiver Port" should 895 be set to 0 by both ends. The pType field should be set to 0. The 896 pFlag should be set to 1. 898 If the adjacency times out on either end, due to not receiving an 899 adjacency message for a duration of (3 * Timer value), where the 900 timer value is specified in the adjacency message, all the state 901 received from the ANCP neighbor should be cleaned up, and the TCP 902 connection should be closed. The NAS would continue to listen for 903 new connection requests. The DSLAM will try to re-establish the TCP 904 connection and both sides will attempt to re-establish the adjacency. 906 The handling defined above will need some modifications when ANCP 907 graceful restart procedures are defined. These procedures will be 908 defined in a separate draft. 910 5.3. Capability negotiation 912 The adjacency message as defined in [RFC3292] is extended to carry 913 "Capability TLVs". Both the NAS and the access node will advertise 914 supported capabilities in the originated adjacency messages. If a 915 received adjacency message indicates absence of support for a 916 capability that is supported by the receiving device, it will turn 917 off the capability locally and will send an updated adjacency message 918 with the capability turned off to match the received capability set. 919 This process will eventually result in both sides agreeing on the 920 minimal set of supported capabilities. The adjacency will not come 921 up unless the capabilities advertised by the controller and the 922 controlled device match. 924 After initial synchronization, if at anytime a capability mismatch is 925 detected, the adjacency will be brought down (RSTACK will be 926 generated by the device detecting the mismatch), and synchronization 927 will be re-attempted. 929 0 1 2 3 930 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 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | Ver | Sub | Message Type | Timer |M| Code | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | Sender Name | 935 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | | | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 938 | Receiver Name | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | Sender Port | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Receiver Port | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | PType | PFlag | Sender Instance | 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | Partition ID | Receiver Instance | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | Tech Type | # of TLVs | Total Length | 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | | 951 ~ Capability TLVs ~ 952 | | 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 Figure 8 957 The format of capability TLV is: 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 | Capability Type | Capability Length | 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 | | 963 ~ ~ 964 ~ Capability Data ~ 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 Figure 9: Capability TLV 969 The Tech Type field type indicates the technology to which the 970 capability extension applies. For access node control in case of DSL 971 networks, new type "DSL" is proposed. The value for this field is 972 0x05. This is the first available value in the range that is not 973 currently allocated. It will need to be reserved with IANA. 975 Capability length is the number of actual bytes contained in the 976 value portion of the TLV. The TLV is padded to a 4-octet alignment. 977 Therefore, a TLV with no data will contain a zero in the length field 978 (if capability data is three octets, the length field will contain a 979 three, but the size of the actual TLV is eight octets). Capability 980 data field can be empty if the capability is just a boolean. In case 981 the capability is a boolean, it is inferred from the presence of the 982 TLV (with no data). 984 Capability data provides the flexibility to advertise more than mere 985 presence or absence of a capability. Capability types can be 986 registered with IANA. Following capabilities are defined for ANCP as 987 applied to DSL access: 989 1. Capability Type : Dynamic-Topology-Discovery = 0x01 991 Length (in bytes) : 0 993 Capability Data : NULL 995 2. Capability Type : Line-Configuration = 0x02 997 Length (in bytes) : 0 999 Capability Data : NULL 1001 3. Capability Type : Transactional-Multicast = 0x03 (controller i.e. 1002 NAS terminates IGMP messages from subscribers, and via l2 control 1003 protocol, signals state to the access-nodes (e.g. DSLAMs) to 1004 enable layer2 replication of multicast streams. In ATM access 1005 network this implies that NAS instructs the access-node to setup 1006 a P2MP cross-connect. The details of this will be covered in a 1007 separate ID. 1009 Length (in bytes) : 0 1011 Capability Data : NULL 1013 4. Capability Type : OAM = 0x04 1015 Length (in bytes) : 0 1017 Capability Data : NULL 1019 5.4. GSMP Message Extensions for Access Node Control 1021 5.4.1. General Extensions 1023 Extensions to GSMP messages for various use-cases of "Access Node 1024 Control" mechanism are defined in sections Section 5.4.2 to 1025 Section 5.4.4. However, sub-sectionSection 5.4.1.1 below defines 1026 extensions to GSMP that have general applicability and section 1027 Section 5.4.5 introduces anothor messaging principle and additional 1028 general purpose TLVs that could be used to develop new use cases in 1029 future. 1031 5.4.1.1. Extension TLV 1033 In order to provide flexibility and extensibility certain GSMP 1034 messages such as "PORT MANAGEMENT" and "EVENT" messages defined in 1035 [RFC3292] have been modified to include an extension block that 1036 follows a TLV structure. Individual messages in the following 1037 sections describe the usage and format of the extension block. 1039 All Extension TLVs will be designated as follow: 1041 0 1 2 3 1042 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 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 |x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length | 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 | | 1047 ~ Extension Value ~ 1048 | | 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 Figure 10: Extension TLV 1053 x: Reserved Flags 1055 These are generally used by specific messages and will be 1056 defined in those messages. 1058 Message Type 1060 An 8-bit field corresponding to the message type where the 1061 extension block is used. 1063 Tech Type 1065 An 8-bit field indicating the applicable technology type value. 1066 The Message Type plus the Tech Value uniquely define a single 1067 Extension Type and can be treated as a single 16 bit extension 1068 type. "Tech Type" value of 0x05 SHOULD be used by ANCP for DSL 1069 technology and 0x01 for PON technology. 1071 0x00 Extension block not in use 1073 0x01 PON 1075 0x05 DSL 1077 0x06 - 0xFE Reserved 1079 0xFF Base Specification Use 1081 Block Length 1083 A 8-bit field indicating the length of the Extension Value 1084 field in bytes. When the Tech Type = 0x00, the length value 1085 MUST be set to 0. 1087 Extension Value 1089 A variable length field that is an integer number of 32 bit 1090 words long. The Extension Value field is interpreted according 1091 to the specific definitions provided by the messages in the 1092 following sections.. 1094 5.4.2. Topology Discovery Extensions 1096 The GSMP Event message with PORT UP message type (80) is used for 1097 conveying DSL line attributes to the NAS. The message SHOULD be 1098 generated when a line first comes UP, or any of the attributes of the 1099 line change e.g. the line re-trains to a different rate or one or 1100 more of the configured line attributes are administratively modified. 1101 Also, when the ANCP session first comes up, the DSLAM SHOULD transmit 1102 a PORT UP message to the NAS for each line that is up. When a DSL 1103 line goes down (idle or silent), the DSLAM SHOULD transmit an Event 1104 message with PORT DOWN message type (81) to the NAS. It is 1105 recommended that the DSLAMs use a dampening mechanism per DSL line to 1106 control the rate of state changes per DSL line, communicated to the 1107 NAS. 1109 Not all the fields in GSMP Event message are applicable to ANCP. The 1110 fields that are not applicable MUST be set to zero by the ANCP sender 1111 and ignored by the ANCP receiver. The fields in the PORT UP and PORT 1112 DOWN messages to be set by the ANCP sender, and corresponding 1113 handling by the ANCP receiver is described below. 1115 The version field MUST be set to 3, and the sub field MUST be set to 1116 1. As defined in [RFC3292], the one byte Message Type field MUST be 1117 set to 80 for PORT UP Event message, and to 81 for PORT DOWN Event 1118 Message. The 12 bit Code field MUST be set to 0. The 4 bit Result 1119 field MUST be set to 0 (signifying Ignore.) If a PORT UP message 1120 with a Result field set to 0 is received by the NAS and the NAS is 1121 able to process the message correctly, the NAS MUST NOT generate any 1122 ANCP message in response to the PORT UP. If the PORT UP message 1123 received cannot be processed correctly by the NAS (e.g. the message 1124 is malformed) the NAS MAY respond with an ANCP Error Message (TBD) 1125 containing the reason of the failure. The 24-bit Transaction 1126 Identifier field MUST be set to 0. The "I" bit and the SubMessage 1127 field MUST be set to 1 to signify no fragmentation. The Length field 1128 is two bytes and MUST contain the length of the message (including 1129 header and the payload) in bytes. 1131 The "Port" field, "Port Session Number" field and "Event Sequence 1132 Number" field are 4 bytes each, and MUST be set to 0 by the ANCP 1133 sender. LABEL field in event messages is defined as a TLV in 1134 [RFC3292]. ANCP does NOT use the Label TLV. In both PORT UP and 1135 PORT DOWN event messages an ANCP sender MUST treat the Label field, 1136 immediately following the "Event Sequence Number" field, as a fixed 8 1137 byte field, and MUST set these 8 bytes to 0. The receiver MUST NOT 1138 interpret the LABEL field as a TLV and MUST ignore the 8 bytes 1139 immediately following the "Event Sequence Number" field. In future 1140 versions of ANCP, if necessary, the un-used fields in GSMP Event 1141 message, which do not have ANCP specific semantics, can be used 1142 partially or completely, by re-naming appropriately, and associating 1143 valid semantics with these fields. 1145 The Tech Type field is extended with new type "DSL". The value for 1146 this field is 0x05. 1148 In case of bonded copper loops to the customer premise (as per DSL 1149 multi-pair bonding described by [G.988.1] and [G.988.2]), the DSLAM 1150 MUST report the aggregate net data rate and other attributes for the 1151 "DSL bonded circuit" (represented as a single logical port) to the 1152 NAS in a PORT UP message. Any change in the aggregate net data rate 1153 of the "DSL bonded circuit" (due to a change in net data rate of 1154 individual constituent DSL lines or due to change in state of the 1155 individual constituent DSL lines) MUST be reported by the DSLAM to 1156 the NAS in a PORT UP message. The DSLAM MUST also report the 1157 "aggregate" state of the "DSL bonded circuit" to the NAS via PORT UP 1158 and PORT DOWN messages. 1160 0 1 2 3 1161 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 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 | Vers | Sub | Message Type | Result| Code | 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 | Partition ID | Transaction Identifier | 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 |I| SubMessage Number | Length | 1168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 | Port | 1170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1171 | Port Session Number | 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 | Event Sequence Number | 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 | | 1176 + Label + 1177 | | 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1179 |x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length | 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 | | 1182 ~ Extension Value ~ 1183 | | 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1186 Figure 11 1188 The format of the "Extension Value" field for Tech Type "DSL" is as 1189 follows : 1191 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 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1193 | # of TLVs | Extension Block length (bytes) | 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 | | 1196 ~ TLVs ~ 1197 ~ ~ 1198 | | 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 Figure 12: Extension Value 1203 The "Extension Value" contains one or more TLVs to identify a DSL 1204 line and define its characteristics. A TLV can consist of multiple 1205 sub-TLVs. First 2 byte of the "Extension Value" contains the number 1206 of TLVs that follow. The next 2 bytes contain the total length of 1207 the TLVs carried in the extension block in bytes (existing "Block 1208 Length" field in the GSMP message is limited to 255 bytes and is not 1209 sufficient). 1211 General format of a TLV is : 1213 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 1214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 | Type | Length | 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 | | 1218 ~ Value ~ 1219 ~ ~ 1220 | | 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1223 Figure 13: General TLV 1225 The value field in each TLV is padded to a 4-octet alignment. The 1226 Length field in each TLV contains the actual number of bytes in the 1227 TLV (not including the padding if present). If a TLV is not 1228 understood by the NAS, it is silently ignored. Currently defined 1229 types start from 0x01. 1231 Following TLVs are currently defined: 1233 1. Type (Access-Loop-Circuit-ID = 0x01): This is a mandatory TLV and 1234 contains an identifier of the subscriber's connection to the 1235 access node (i.e. "local loop"). The "local loop" can be ATM 1236 based or Ethernet based. The "Access Loop Circuit ID" has local 1237 significance at the access node. The exact usage on the NAS is 1238 beyond the scope of this document. The format used for "local 1239 loop" identification in ANCP messages MUST be identical to what 1240 is used by the access nodes in subscriber signaling messages when 1241 the access nodes act as "signaling relay agents" as outlined in 1242 [RFC3046] and [TR-101]. 1244 Length : (up to 63 bytes) 1246 Value : ASCII string 1248 For an ATM based local loop the string consists of slot/port 1249 and VPI/VCI information corresponding to the subscriber's DSL 1250 connection. Default syntax for the string inserted by the 1251 access node as per [TR-101] is: 1253 "Access-Node-Identifier atm slot/port:vpi.vci" 1255 The Access-Node-Identifier uniquely identifies the access node 1256 in the access network. The slot/port and VPI/VCI uniquely 1257 identifies the DSL line on the access node. Also, there is 1258 one to one correspondence between DSL line and the VC between 1259 the access node and the NAS. 1261 For local loop which is Ethernet based (and tagged), the 1262 string consists of slot/port and VLAN tag corresponding to the 1263 subscriber. Default syntax for the string inserted by the 1264 access node as per [TR-101] is: 1266 "Access-Node-Identifier eth slot/port[:vlan-id]" 1268 2. Type (Access-Loop-Remote-Id = 0x02): This is an optional TLV and 1269 contains an identifier to uniquely identify a user on a local 1270 loop on the access node. The exact usage on the NAS is out of 1271 scope of this document. It is desirable that the format used for 1272 the field is similar to what is used by the access nodes in 1273 subscriber signaling messages when the access nodes act as 1274 "signaling relay agents" as outlined in [RFC3046] and [TR-101]. 1276 Length : (up to 63 bytes) 1278 Value : ASCII string 1280 3. Type (Access-Aggregation-Circuit-ID-Binary = 0x06) 1282 Length : (8 bytes) 1284 Value : two 32 bit integers 1286 For ethernet access aggregation, where a per-subscriber 1287 (stacked) VLAN can be applied (1:1 model defined in [TR-101]), 1288 the VLAN stack provides a convenient way to uniquely identify 1289 the DSL line. The outer VLAN is equivalent to virtual path 1290 between a DSLAM and the NAS and inner VLAN is equivalent to a 1291 virtual circuit on a per DSL line basis. In this scenario, 1292 any subscriber data received by the access node and 1293 transmitted out the uplink to the aggregation network will be 1294 tagged with the VLAN stack assigned by the access node 1296 This TLV can carry the VLAN tags assigned by the access node 1297 in the ANCP messages. The VLAN tags can uniquely identify the 1298 DSL line being referred to in the ANCP messages, assuming the 1299 VLAN tags are not in any way translated in the aggregation 1300 network and are unique across physical ports. Each 32 bit 1301 integer (least significant bits) contains a 12 bit VLAN 1302 identifier (which is part of the VLAN tag defined by IEEE 1303 802.1Q). 1305 Also, in case of an ATM aggregation network, where the DSLAM 1306 is directly connected to the NAS (without an intermediate ATM 1307 switch), the two values can contain VPI and VCI on the DSLAM 1308 uplink (and can uniquely identify the DSL line on the DSLAM). 1310 This is optional. 1312 4. Type (Access-Aggregation-Circuit-ID-ASCII = 0x03) 1314 Length : (up to 63 bytes) 1316 Value : ASCII string 1318 This field contains information pertaining to an uplink on the 1319 access node. For Ethernet access aggregation, assuming the 1320 access node assigns VLAN tags (1:1 model), typical format for 1321 the string is: 1323 "Access-Node-Identifier eth slot/port [:inner-vlan- 1324 id][:outer-vlan-id]" 1326 The slot/port corresponds to the ethernet uplink on the access 1327 node towards the NAS. 1329 For an ATM aggregation network, typical format for the string 1330 is: 1332 "Access-Node-Identifier atm slot/port:vpi.vci" 1334 This TLV allows the NAS to associate the information contained 1335 in the ANCP messages to the DSL line on the access node. 1337 If the access node inserts this string in the ANCP messages, 1338 when referring to local loop characteristics (e.g. DSL line 1339 in case of a DSLAM), then it should be able to map the 1340 information contained in the string uniquely to the local loop 1341 (e.g. DSL line). 1343 On the NAS, the information contained in this string can be 1344 used to derive an "aggregation network" facing construct (e.g. 1345 an IP interface) corresponding to the local loop (e.g. DSL 1346 line). The association could be based on "local 1347 configuration" on the NAS. 1349 The access node can also convey to the NAS, the 1350 characteristics (e.g. bandwidth) of the uplink on the access 1351 node. This TLV then serves the purpose of uniquely 1352 identifying the uplink whose characteristics are being 1353 defined. A separate set of sub-TLVs will be defined for the 1354 uplink characteristics (TBD). 1356 This TLV is optional. 1358 5. Type (DSL Line Attributes = 0x04): 1360 Length : variable (up to 1024 bytes) 1362 Value : This is a mandatory TLV and consists of one or more 1363 Sub-TLVs corresponding to DSL line attributes. No sub-TLVs 1364 other than the "DSL type" and "DSL line state" SHOULD be 1365 included in a PORT DOWN message. 1367 The general format of the sub-TLVs is identical to the general 1368 TLV format. The value field in each sub-TLV is padded to a 1369 4-octet alignment. The Length field in each sub-TLV contains 1370 the actual number of bytes in the TLV (not including the 1371 padding if present). Current defined sub-TLV types are start 1372 from 0x81. 1374 Following sub-TLVs are currently defined : 1376 + Type (DSL-Type = 0x91) : Defines the type of transmission 1377 system in use. This is a mandatory TLV. 1379 Length : (4 bytes) 1381 Value : (Transmission system : ADSL1 = 0x01, ADSL2 = 1382 0x02, ADSL2+ = 0x03, VDSL1 = 0x04, VDSL2 = 0x05, SDSL = 1383 0x06, UNKNOWN = 0x07). 1385 + Type (Actual-Net-Data-Upstream = 0x81): Actual upstream net 1386 data rate on a DSL line. This is a mandatory TLV. 1388 Length : (4 bytes) 1390 Value : (Rate in Kb/sec) 1392 + Type (Actual-Net-Data-Rate-Downstream = 0x82) : Actual 1393 downstream net data rate on a DSL line. This is a 1394 mandatory TLV. 1396 Length : (4 bytes) 1398 Value : (Rate in Kb/sec) 1400 + Type (Minimum-Net-Data-Rate-Upstream = 0x83) : Minimum net 1401 data rate desired by the operator. This is optional. 1403 Length : (4 bytes) 1405 Value : (Rate in Kb/sec) 1407 + Type (Minimum-Net-Data-Rate-Downstream = 0x84) : Minimum 1408 net data rate desired by the operator. This is optional. 1410 Length : (4 bytes) 1412 Value : (Rate in Kb/sec) 1414 + Type (Attainable-Net-Data-Rate-Upstream = 0x85) : Maximum 1415 net upstream rate that can be attained on the DSL line. 1416 This is an optional TLV. 1418 Length : (4 bytes) 1420 Value : (Rate in Kb/sec) 1422 + Type (Attainable-Net-Data-Rate-Downstream = 0x86) : Maximum 1423 net downstream rate that can be attained on the DSL line. 1424 This is an optional TLV. 1426 Length : (4 bytes) 1428 Value : (Rate in Kb/sec) 1430 + Type (Maximum-Net-Data-Rate-Upstream = 0x87) : Maximum net 1431 data rate desired by the operator. This is optional. 1433 Length : (4 bytes) 1435 Value : (Rate in Kb/sec) 1437 + Type (Maximum-Net-Data-Rate-Downstream = 0x88) : Maximum 1438 net data rate desired by the operator. This is optional. 1440 Length : (4 bytes) 1441 Value : (Rate in Kb/sec) 1443 + Type (Minimum-Net-Low-Power-Data-Rate-Upstream = 0x89) : 1444 Minimum net data rate desired by the operator in low power 1445 state. This is optional. 1447 Length : (4 bytes) 1449 Value : (Rate in Kb/sec) 1451 + Type (Minimum-Net-Low-Power-Data-Rate-Downstream = 0x8A) : 1452 Minimum net data rate desired by the operator in low power 1453 state. This is optional. 1455 Length : (4 bytes) 1457 Value : (Rate in Kb/sec) 1459 + Type (Maximum-Interleaving-Delay-Upstream = 0x8B) : maximum 1460 one way interleaving delay. This is optional. 1462 Length : (4 bytes) 1464 Value : (Time in msec) 1466 + Type (Actual-Interleaving-Delay-Upstream = 0x8C) : Value 1467 corresponding to the interleaver setting. This is 1468 optional. 1470 Length : (4 bytes) 1472 Value : (Time in msec) 1474 + Type (Maximum-Interleaving-Delay-Downstream = 0x8D) : 1475 maximum one way interleaving delay. This is optional. 1477 Length : (4 bytes) 1479 Value : (Time in msec) 1481 + Type (Actual-Interleaving-Delay-Downstream = 0x8E) : Value 1482 corresponding to the interleaver setting. This is 1483 optional. 1485 Length : (4 bytes) 1486 Value : (Time in msec) 1488 + Type (DSL line state = 0x8F) : The state of the DSL line. 1489 For PORT UP message, at this time, the TLV is optional 1490 (since the message type implicitly conveys the state of the 1491 line). For PORT DOWN, the TLV is mandatory, since it 1492 further communicates the state of the line as IDLE or 1493 SILENT. 1495 Length : (4 bytes) 1497 Value : { SHOWTIME = 0x01, IDLE = 0x02, SILENT = 0x03 } 1499 + Type (Access Loop Encapsulation = 0x90) : The data link 1500 protocol and, optionally the encapsulation overhead on the 1501 access loop. This is an optional TLV. However, when this 1502 TLV is present, the data link protocol MUST minimally be 1503 indicated. The encapsulation overhead can be optionally 1504 indicated. 1506 Length : (3 bytes) 1508 Value : The three bytes (most to least significant) and 1509 valid set of values for each byte are defined below. 1511 Data Link (1 byte): {ATM AAL5 = 0, ETHERNET = 1} 1513 Encaps 1 (1 byte): { 1515 NA = 0, 1517 Untagged Ethernet = 1, 1519 Single-tagged Ethernet = 2} 1521 Encaps 2 (1 byte):{ 1523 NA = 0, 1525 PPPoA LLC = 1 1527 PPPoA NULL = 2, 1529 IPoA LLC = 3, 1530 IPoA NuLL = 4, 1532 Ethernet over AAL5 LLC with FCS = 5, 1534 Ethernet over AAL5 LLC without FCS = 6, 1536 Ethernet over AAL5 NULL with FCS = 7, 1538 Ethernet over AAL5 NULL without FCS = 8} 1540 If this TLV is present, the Data Link protocol MUST be 1541 indicated as defined above. However, the Access Node can 1542 choose to not convey the encapsulation on the access loop 1543 by specifying a value of 0 (NA) for the two encapsulation 1544 fields 1546 5.4.3. Line Configuration Extensions 1548 The Port Management message format defined in [RFC3292] has been 1549 modified to contain an extension block (described above in section 1550 Section 5.4.1.1) at the end of the message. Also, the original two 1551 byte Function field has been modified to contain one byte for the 1552 Function field indicating a specific action to be taken by the 1553 recipient of the message, and one byte for X-Function field, which 1554 could further qualify the action specified in the Function field. 1555 Any Function specific data MUST be carried in the extension block. 1557 Not all the fields in GSMP Port Management message are applicable to 1558 ANCP. The fields that are not applicable MUST be set to zero by the 1559 ANCP sender and ignored by the ANCP receiver. 1561 The NAS uses the extension block in the Port Management messages to 1562 convey service attributes of the DSL lines to the DSLAM. TLVs are 1563 defined for DSL line identification and service data for the DSL 1564 lines. Port number is set to 0 in the message. A new action type 1565 "Configure Connection Service Data" (value 0x8) is defined. The 1566 "Function" field is set to the action type. This action type 1567 indicates to the device being controlled (Access Node i.e. DSLAM) to 1568 apply service configuration data contained in the extension value 1569 (TLVs), to the DSL line (identified by one of the TLVs in the 1570 extension value). For the action type "Configure Connection Service 1571 Data", X-Function field MUST be set to 0. The Tech Type field is 1572 extended with new type "DSL". The value for this field is 0x05. 1574 0 1 2 3 1575 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 1576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1577 | Vers | Sub | Message Type | Result| Code | 1578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1579 | Partition ID | Transaction Identifier | 1580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1581 |I| SubMessage Number | Length | 1582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1583 | Port | 1584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1585 | Port Session Number | 1586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1587 | Event Sequence Number | 1588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 |R|x|x|x|x|x|x|x| Duration | Function | X-Function | 1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1591 | Event Flags | Flow Control Flags | 1592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1593 |x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length | 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 | | 1596 ~ Extension Value ~ 1597 | | 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 Figure 14 1602 The format of the "Extension Value" field is as follows: 1604 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 1605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1606 | # of TLVs | Extension Block length (bytes) | 1607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1608 | | 1609 ~ TLVs ~ 1610 ~ ~ 1611 | | 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1614 Figure 15: Extension Value 1616 The "Extension Value" field contains one or more TLVs containing DSL 1617 line identifier and desired service attributes of the the DSL line. 1618 First 2 byte of the "Extension Value" contains the number of TLVs 1619 that follow. The next 2 bytes contain the total length of the 1620 extension block in bytes (existing "Block Length" field in the GSMP 1621 message is limited to 255 bytes and is not sufficient). 1623 General format of a TLV is: 1625 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 1626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1627 | Type | Length | 1628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1629 | | 1630 ~ Value ~ 1631 ~ ~ 1632 | | 1633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 Figure 16: General TLV 1637 The value field is padded to a 4-octet alignment. The Length field 1638 in each TLV contains the actual number of bytes in the TLV (not 1639 including the padding if present). If a TLV is not understood by the 1640 access-node, it is silently ignored. Depending upon the deployment 1641 scenario, the NAS may specify "Access Loop Circuit-ID" or the "Access 1642 Aggregation Circuit-ID") as defined in section Section 5.4.1. 1643 Following TLVs can appear in this message: 1645 o Type (Access-Loop-Circuit-ID = 0x01) : defined in section 1646 Section 5.4.1 1648 o Type (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in 1649 section Section 5.4.1 1651 o Type (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in 1652 section Section 5.4.1 1654 o Type (Service-Profile-Name = 0x05): Reference to a pre-configured 1655 profile on the DSLAM that contains service specific data for the 1656 subscriber. 1658 Length : (up to 64 bytes) 1660 Value : ASCII string containing the profile name (NAS learns 1661 from a policy server after a subscriber is authorized). 1663 In future, more TLVs MAY be defined for individual service 1664 attributes of a DSL line (e.g. rates, interleaving delay, 1665 multicast channel entitlement access-list etc) 1667 5.4.3.1. Provisioning Message 1669 The Provisioning message is sent by the NAS to the AN to provision 1670 information in the AN. This message can be used to provision global 1671 scope information on the Access Node. 1673 The Message Type for the Provisioning message is 93. 1675 The NAS sending the Provisioning message MUST set the Result field to 1676 0x00. 1678 The NAS MUST populate the ANCP Transaction Identifier field with a 1679 distinct non-zero, linearly incrementing value for each request per 1680 adjacency, as described in Section 5.4.5 . 1682 The ANCP Provisioning message payload MAY contain different TLVs, 1683 like for example Service-Profile-Name TLV. The Service-Profile-Name 1684 TLV MAY appear zero, one or multiple times. 1686 On receipt of the Provisioning message, the AN MUST: 1688 o ignore the Result field 1690 o if the AN can process the message successfully and accept all the 1691 provisioning directives contained in it, the AN MUST NOT send any 1692 response. 1694 5.4.4. OAM Extensions 1696 GSMP "Port Management" message (type 32) SHOULD be used by the NAS to 1697 trigger access node to run a loopback test on the local loop. The 1698 message format is defined in section Section 5.4.2. The version 1699 field SHOULD be set to 3 and sub-version field SHOULD be set to 1. 1700 The remaining fields in the GSMP header have standard semantics. The 1701 function type used in the request message SHOULD be set to "remote 1702 loopback" (type = 0x09). The port, "port session number", "event 1703 sequence number", duration, "event flags", "flow control flags" and 1704 code fields SHOULD all be set to 0. The result field SHOULD be set 1705 to "AckAll" to indicate requirement for the access node to send a 1706 success or failure response. The transaction ID SHOULD contain a 1707 sequence number inserted by the NAS in each request that it 1708 generates. 1710 Not all the fields in GSMP Port Management message are applicable to 1711 ANCP. The fields that are not applicable MUST be set to zero by the 1712 ANCP sender and ignored by the ANCP receiver. 1714 The extension field format is also defined above in section 1715 Section 5.4.2. The extension value field can contain one or more 1716 TLVs including the access-line identifier on the DSLAM and OAM test 1717 characteristics desired by the NAS. 1719 The TLV format is defined above in section Section 5.4.2. The value 1720 field is padded to a 4-octet alignment. The Length field in each TLV 1721 contains the actual number of bytes in the TLV (not including the 1722 padding if present). If a TLV is not understood by the NAS, it is 1723 silently ignored. Depending upon the deployment scenario, the NAS 1724 may specify "Access Loop Circuit-ID" or the "Access Aggregation 1725 Circuit-ID") as defined in section Section 5.4.1. Following TLVs can 1726 appear in this message: 1728 o Type (Access-Loop-Circuit-ID = 0x01) : defined in section 1729 Section 5.4.1 1731 o Type (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in 1732 section Section 5.4.1 1734 o Type (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in 1735 section Section 5.4.1 1737 o Type (OAM-Loopback-Test-Parameters = 0x07): Parameters related to 1738 loopback test. This is an optional TLV. If this TLV is not 1739 present in the request message, the DSLAM SHOULD use locally 1740 determined default values for the test parameters. 1742 Length : (4 bytes) 1744 Value : two 1 byte numbers described below (listed in order of 1745 most to least significant). Thus, the 4 bytes consist of 1 1746 byte of Count, followed by 1 byte of Timeout, followed by two 1747 pad bytes of zero. 1749 + Count (1 byte) : Number of loopback cells/messages that 1750 should be generated on the local loop as part of the 1751 loopback test. The NAS SHOULD restrict the "count" to be 1752 greater than 0 and less than or equal to 32. The DSLAM 1753 SHOULD discard the request for a loopback test, if the 1754 received test parameters contain an out of range value for 1755 the "count" field. The DSLAM MAY optionally send a failure 1756 response to the NAS with the code "invalid test parameter". 1758 + Timeout (1 byte) : Upper bound on the time in seconds that 1759 the NAS would wait for a response from the DSLAM. If the 1760 total time taken by the DSLAM to complete a test with 1761 requested parameters, exceeds the specified "timeout" value, 1762 it can choose to omit the generation of a response to the 1763 NAS. DSLAM SHOULD use a locally determined value for the 1764 "timeout", if the received value of the "timeout" parameter 1765 is 0. 1767 o Type (Opaque-Data = 0x08) : This is an optional TLV. If present 1768 in the request message, the DSLAM SHOULD reflect it back in the 1769 response unmodified 1771 Length : (8 bytes) 1773 Value : Two 32 bit integers inserted by the NAS (not to be 1774 interpreted by the DSLAM, but just reflected back in the 1775 response). 1777 The access node generates a success or failure response when it deems 1778 the loopback test to be complete. "Port Management" message (type 1779 32) is used. The result field SHOULD be set to success or failure. 1780 The function type SHOULD be set to 0x09. The transaction ID SHOULD 1781 be copied from the sequence number contained in the corresponding 1782 request. The other parameters not explicitly defined here SHOULD be 1783 set as specified in the request message above. The code field SHOULD 1784 be set to a value in the range 0x500 to 0x5ff (to be reserved with 1785 IANA) to indicate the status of the executed test. The valid values 1786 defined are (can be extended in future): 1788 0x500 : Specified access line does not exist 1790 0x501 : Loopback test timed out 1792 0x502 : Reserved 1794 0x503 : DSL line status showtime 1796 0x504 : DSL line status idle 1798 0x505 : DSL line status silent 1800 0x506 : DSL line status training 1802 0x507 : DSL line integrity error 1804 0x508 : DSLAM resource not available 1806 0x509 : Invalid test parameter 1808 The Extension value can contain one or more TLVs including the TLV to 1809 identify the access line on which the test was performed, and details 1810 from executing the test. The access line identifier SHOULD be 1811 identical to what was contained in the request. The relevant TLVs 1812 are: 1814 o Type (Access-Loop-Circuit-ID = 0x01) : defined in section 1815 Section 5.4.1 1817 o Type (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in 1818 section Section 5.4.1 1820 o Type (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in 1821 section Section 5.4.1 1823 o Type (Opaque-Data = 0x08) : Data inserted by the NAS in the 1824 request reflected back by the DSLAM. 1826 Length : (up to 8 bytes) 1828 Value : Two 32 bit integers as received in the request (opaque 1829 to the DSLAM). 1831 o Type (OAM-Loopback-Test-Response-String = 0x09) 1833 Length : (up to 128 bytes) 1835 Value : Suitably formatted ASCII string containing useful 1836 details about the test that the NAS will display for the 1837 operator, exactly as received from the DSLAM (no manipulation/ 1838 interpretation by the NAS). This is an optional TLV, but it is 1839 strongly recommended, that in case of ATM based local loop, the 1840 DSLAM at the very least indicates via this TLV, the total 1841 loopback cells generated and the total loopback cells 1842 successfully received as part of executing the requested 1843 loopback test. 1845 5.4.5. Additional GSMP Extensions for future use cases 1847 GSMP protocol defined in [RFC3292] allows for two messaging 1848 principles in case of Request/Response interaction: 1850 o The same message type used for both request message and response 1851 message where result field and code field settings are used to 1852 differentiate between request and response messages; 1854 o Two different message types for request message and response 1855 messages. 1857 First message principle has been adopted for use cases defined in 1858 sections Section 5.4.2 to Section 5.4.4, the purpose of this section 1859 is to specify the second type of approach in order to allow the use 1860 of this message principle for the development of future use cases. 1862 In the new message paradigm different message types are used as ANCP 1863 Request Message and ANCP Response Message: the format of a generic 1864 ANCP message starts with the common GSMP header as in the case of the 1865 existing ANCP implementation, but the Result field is set to Ignore 1866 in order to instruct the receipt to ignore this field and follow the 1867 procedures specified for the received message type. The Transaction 1868 Identifier field is used to distinguish between request messages and 1869 to associate a response message to a request. Applications that 1870 require such response correlation MUST set the Transaction Identifier 1871 to a value in the range (1, 2^24 - 1). When used in this manner, the 1872 Transaction Identifier sequencing MUST be maintained independently 1873 for each ANCP adjacency and per message type. Furthermore, it SHOULD 1874 be incremented linearly for each new message of the given type, 1875 cycling back to 1 after running the full range. Message types not 1876 requiring response message correlation SHOULD set the Transaction Id 1877 field to 0x0. In the event of an ANCP transport protocol failure, 1878 all pending ANCP messages destined to the disconnected recipient can 1879 be discarded until the transport is re- established following which 1880 the Transaction Identifier is re- initialized. 1882 The value of the Transaction Identifier in a Response message MUST be 1883 set to that of the respective Request message. This allows the 1884 Requester to correlate the Response to the original Request. The 1885 Transaction Identifier is not used in ANCP adjacency messages. Also, 1886 other ANCP applications not requiring it SHOULD set the Transaction 1887 Identifier to 0x0 in their messages. 1889 All TLVs within the ANCP message have to be 32 bit aligned, and when 1890 necessary padded with 0s to the 32 bit boundary. The padding is not 1891 reflected in the message length field. 1893 5.4.5.1. General well known TLVs 1895 This section contains the definitions of three general well known 1896 TLVs. These TLVs are intended to be re-usable across different 1897 messages. 1899 5.4.5.1.1. Target TLV 1901 The Target TLV (0x1000 - 0x01020) is intended to be a general well 1902 known TLV allowing the representation of different types of objects. 1903 Its use is not restricted to any specific Message Type. 1905 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 1906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1907 | TLV Type = Target | Target-TLV Length | 1908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1909 | | 1910 ~ Target Info ~ 1911 | | 1912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1914 Target TLV: 1916 TLV (0x1000 - 0x1020) indicating the type of target being 1917 addressed. Target TVL 0x1000 indicates a single Access- 1918 Port. 1920 Target TLV Length: 1922 Length in bytes of Target Info. Excludes TLV header 1924 Target Info: 1926 Target information as defined for each the given target. 1927 The field can consist of sub-TLVs. 1929 In its simplest form, when targeting a single access line the Target- 1930 TLV will be set to a value of (0x1000), and carry in its payload one 1931 or more sub-TLVs identifying the target. The following example 1932 illustrates the message format for a single port identified by an 1933 Access-Loop-Circuit-ID TLV (0x0001) that could be derived from a 1934 Port-UP message: 1936 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 1937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1938 | TLV Type = Target | Target-TLV Length | 1939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1940 | Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length | 1941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1942 | | 1943 ~ Access Loop Circuit ID ~ 1944 | | 1945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1947 5.4.5.1.2. Command TLV 1949 The Command TLV (0x11) is intended to be a general well known TLV 1950 allowing the encapsulation of one or more command directives in a TLV 1951 oriented message. The semantics of the command are allowed to be 1952 specified for each message type, ie different message types that 1953 choose to carry the Command TLV are expected to define the meaning of 1954 the content of the payload, which could be re-used from those already 1955 defined elsewhere if appropriate. 1957 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 1958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1959 | TLV Type = Command | Command-TLV Length | 1960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1961 | | 1962 ~ Command Info ~ 1963 | | 1964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1965 | Additional sub-TLV Type | Additional sub-TLV Length | 1966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1967 | | 1968 ~ Additional sub-TLV data ~ 1969 | | 1970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1972 Command TLV: 1974 TLV (0x11) indicating the contents to be one or more 1975 command directives. 1977 Command TLV Length: 1979 Combined length in bytes of the data in Command Info and 1980 sub-TLV. Excludes the Command TLV header 1982 Commad-Info: 1984 Command information as defined for each message type. The 1985 field can consist of sub-TLVs. 1987 Additional sub-TLV: 1989 Additional sub-TLVs can be present in a command TLV. Any 1990 such sub-TLVs must directly follow each command. 1992 Additional sub-TLV Length: 1994 Number of actual bytes contained in the value portion of 1995 each additional sub-TLV 1997 5.4.5.1.3. Status-info TLV 1999 The Status-info-TLV is intended to be a general well known TLV used 2000 to convey the status code regarding commands and/or requests. The 2001 format of the Status-info-TLV (0x0106) is shown below. 2003 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 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2005 | TLV Type = Status-info | Status TLV Length | 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2007 | Reserved | Msg Type | Error Message Length | 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2009 | Error Message (aligned to 4 bytes length) | 2010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2011 | sub-TLVs... | 2012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2014 Status-info TLV: 2016 TLV (0x106) conveying the status or error response of a 2017 command 2019 Status TLV Length: 2021 Specifies the length in bytes of the Status Info TLV 2022 payload. Excludes the TLV header 2024 Reserved: 2026 This field MUST be set to all zeroes by the sender and 2027 ignored by the receiver. 2029 Msg Type: 2031 The message type value of the message the Status-info TLV 2032 is reporting on 2034 Error Message Length: 2036 It contains the length of an optional error message or 0 if 2037 none. 2039 Error message: 2041 It contains a human-readable description of the error being 2042 reported by the Status-info field. 2044 TLVs: 2046 This field is of indeterminate length, and contains zero or 2047 more of the TLVs associated with the Status-info TLV. The 2048 following TLVs are RECOMMENDED to be provided if the 2049 indicated Code values are given in the header of the 2050 message containing the Status-info TLV: 2052 Code value 4 or 5: the Target or other TLV identifying the 2053 unknown or unavailable port. 2055 Code value 84: the TLV that is unsupported or contains the 2056 unsupported value. 2058 5.4.5.2. Generic Response Message 2060 This section defines the Generic Response message. The Generic 2061 Response message may be specified as the appropriate response to a 2062 message defined in an extension to ANCP, instead of a more specific 2063 response message. As a general guideline, specification of the 2064 Generic Response message as a response is appropriate where no data 2065 needs to be returned to the peer other than a result (success or 2066 failure), plus, in the case of a failure, a code indicating the 2067 reason for failure and a limited amount of diagnostic data. 2068 Depending on the particular use case, the Generic Response message 2069 MAY be sent by either the NAS or the AN. 2071 The AN or NAS MAY send a Generic Response message indicating a 2072 failure condition independently of a specific request before closing 2073 the adjacency as a consequence of that failure condition. In this 2074 case, the sender MUST set the Transaction Identifier field in the 2075 header and the Message Type field within the Status-info TLV to 2076 zeroes. The receiver MAY record the information contained in the 2077 Status-info TLV for management use. 2079 The format of the Generic Response message is shown in Figure 17 2080 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 2081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2082 | Type (0x88-0C) | Length | 2083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2084 | Vers | Sub |MessageType=91 |Result | Code | 2085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2086 | Partition ID | Transaction Identifier | 2087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2088 |I| SubMessage Number | Length | 2089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2090 | Status-info-TLV=0x106 | Status-TLV-Length | 2091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2092 | Reserved | Msg type | Error Message Length | 2093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2094 | Error Message (padded to 4) if Length > 0 | 2095 +---------------------------------------------------------------+ 2096 | sub-TLVs... | 2097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2099 Figure 17: Structure of the Generic Response Message 2101 Message Type: 2103 The message type value for the Generic Response message is 0x91. 2105 Result: 2107 The value of the Result field for the Generic Response message 2108 MUST be either Success (0x03) or Failure (0x04). 2110 Code: 2112 The Code field MUST have value zero if Result is set to Success 2113 (0x03). It MUST have an appropriate non-zero value if Result is 2114 set to Failure (0x04). As discussed in section 5, extensions to 2115 ANCP MAY define new Code values for use in failure responses for 2116 specific request message types. 2118 Partition ID: 2120 As specified in section Section 5. 2122 Transaction Identifier: 2124 The Transaction Identifier MUST be copied from the request to 2125 which the Generic Response message is responding. 2127 I, Sub-message Number, Length: 2129 As specified in Section 5. 2131 Status-info TLV: 2133 MAY be present in a success response, to provide a warning as 2134 defined for a specific request message type. MUST be present in a 2135 failure response. The Message Type field value is copied from the 2136 header of the request message. The Error Message field contains 2137 human-readable diagnostic text. The description of the response 2138 for a particular request message type MAY specify further sub-TLVs 2139 to be included in Status-info, either generally or for specific 2140 failure Code values. 2142 5.5. ATM-specific considerations 2144 The topology discovery and line configuration involve the DSL line 2145 attributes. For ATM based access networks, the DSL line on the DSLAM 2146 is identified by the port and PVP/PVC corresponding to the 2147 subscriber. The DSLAMs are connected to the NAS via an ATM access 2148 aggregation network. Since, the DSLAM (access-node) is not directly 2149 connected to the NAS, the NAS needs a mechanism to learn the DSL line 2150 identifier (more generally referred to as "Access Loop Circuit-ID") 2151 corresponding to a subscriber. The "Access loop circuit-ID" has no 2152 local significance on the NAS. The ANCP messages for topology 2153 discovery and line configuration carry opaque "Access loop 2154 Circuit-ID" which has only local significance on the DSLAMs. 2156 The access loop circuit identifier can be carried as an ASCII string 2157 in the ANCP messages. This allows ANCP to be decoupled from the 2158 specifics of the underlying access technology being controlled. On 2159 the other hand, this requires a NAS mechanism by which such 2160 identifier can be correlated to the context of an "aggregation 2161 network" facing IP interface (corresponding to the subscriber) on the 2162 NAS. This would typically require local configuration of such IP 2163 interfaces, or of the underlying ATM interfaces. 2165 5.6. Ethernet-specific considerations 2167 One possible way of approaching the use of Ethernet technology in the 2168 access aggregation network is to recreate the equivalent of Virtual 2169 Paths (VPs) and Virtual Circuits (VCs) by using stacked Virtual LAN 2170 tags. As an example, one could use an "outer" VLAN to create a form 2171 of "virtual path" between a given DSLAM and a given NAS. And then 2172 use "inner" VLAN tags to create a form of "virtual circuit" on a per 2173 DSL line basis. In this case, VLAN tags conveyed in topology 2174 discovery and line configuration messages will allow to uniquely 2175 identify the DSL line in a straightforward manner, assuming the VLAN 2176 tags are not translated in some way by the aggregation network, and 2177 are unique across physical ports. 2179 However, some carriers do not wish to use this "connection oriented" 2180 approach. Therefore, an alternative model is to bridge sessions from 2181 multiple subscribers behind a DSLAM to a single VLAN in the 2182 aggregation network. This is the N:1 model. In this model, or in 2183 the case where user traffic is sent untagged, the access node needs 2184 to insert the exact identity of the DSL line in the topology 2185 discovery and line configuration messages, and then hve a mechanism 2186 by which this can be correlated to the context of an "aggregation 2187 network" facing IP interface (for the subscriber) on the NAS. This 2188 can either be based on local configuration on the NAS, or on the fact 2189 that such DSLAM (access node) typically inserts the "Access Loop 2190 Circuit ID" in subscriber signaling messages relayed to the NAS (i.e. 2191 DHCP or PPPoE discovery messages). 2193 Section Section 5.4.1 defines "Access Loop Circuit ID". 2195 6. IANA Considerations 2197 This document defines the following additions to the GSMPv3 Message 2198 Type Name Space registry: 2200 +--------------+--------+---------------+ 2201 | Message | Number | Source | 2202 +--------------+--------+---------------+ 2203 | Provisioning | 93 | This document | 2204 +--------------+--------+---------------+ 2206 This document defines the following modification to the General 2207 Switch Management Protocol version 3 (GSMPv3) Result Type Name Space 2208 registry: 2210 +--------------+------------------------+---------------+ 2211 | Result Value | Result Type Name | Reference | 2212 +--------------+------------------------+---------------+ 2213 | 0 | Ignore (from Reserved) | This document | 2214 +--------------+------------------------+---------------+ 2216 This document defines the following addition to the GSMPv3 Message 2217 Function Name Space registry [editor's note GMSPv3 did not define a 2218 Name Space for Function even if RFC3292 defines values for function 2219 field]: 2221 +----------------+-----------------+---------------+ 2222 | Function Value | Function Name | Reference | 2223 +----------------+-----------------+---------------+ 2224 | 0x09 | Remote loopback | This document | 2225 +----------------+-----------------+---------------+ 2227 The GSMPv3 Failure Response Message Name Space is extended from the 2228 GSMPv3 limit of 255 to a new upper limit of 4095 and this document 2229 adds the following values to the GSMPv3 Failure Response Message Name 2230 Space registry: 2232 +-------------------+-----------------------------------+-----------+ 2233 | Failure Response | Failure Response Message Name | Reference | 2234 | Message Value | | | 2235 +-------------------+-----------------------------------+-----------+ 2236 | 81d | Request message type not | This | 2237 | | implemented (0x51) | document | 2238 | 82d | Transaction identifier out of | This | 2239 | | sequence (0x52) | document | 2240 | 83d | Malformed message (0x53) | This | 2241 | | | document | 2242 | 84d | TLV or value not supported by | This | 2243 | | negotiated capability set (0x54) | document | 2244 | 85d | Invalid value in TLV (0x55) | This | 2245 | | | document | 2246 | From 256d to 499d | Reserved for IETF use (0x0100 - | This | 2247 | | 0x1F3) | document | 2248 | 1280d | Specified access line does not | This | 2249 | | exist (0x500) | document | 2250 | 1281d | Loopback test timed out (0x501) | This | 2251 | | | document | 2252 | 1282d | Reserved (0x502) | This | 2253 | | | document | 2254 | 1283 | DSL line status showtime (0x503) | This | 2255 | | | document | 2256 | 1284 | DSL line status idle (0x504) | This | 2257 | | | document | 2258 | 1285 | DSL line status silent (0x505) | This | 2259 | | | document | 2260 | 1286 | DSL line status training (0x506) | This | 2261 | | | document | 2262 | 1287 | DSL line integrity error (0x507) | This | 2263 | | | document | 2264 | 1288 | DSLAM resource not available | This | 2265 | | (0x508) | document | 2266 | 1289 | Invalid test parameter (0x509) | This | 2267 | | | document | 2268 | From 509d to | Reserved for IETF use (0x1FD - | This | 2269 | 4095d | 0XFFF) | document | 2270 +-------------------+-----------------------------------+-----------+ 2272 This document reserves the values 256 to 499 and 509 to 4095 within 2273 the GSMPv3 Failure Response Message Name Space registry for use by 2274 extensions to the Access Node Control Protocol (ANCP). 2276 This document defines a new ANCP Version Space registry. The initial 2277 entry is as follows: 2279 +--------------------+-------------------+---------------+ 2280 | ANCP Version Value | ANCP Version Name | Reference | 2281 +--------------------+-------------------+---------------+ 2282 | 3 | ANCP Version | This document | 2283 +--------------------+-------------------+---------------+ 2285 This document defines a new ANCP Sub-Version Space registry. The 2286 initial entry is as follows: 2288 +------------------------+-----------------------+---------------+ 2289 | ANCP Sub-Version Value | ANCP Sub-Version Name | Reference | 2290 +------------------------+-----------------------+---------------+ 2291 | 1 [*] | ANCP Sub-Version | This document | 2292 +------------------------+-----------------------+---------------+ 2294 [*] Editor's note: sub-version needs to be changed from 1 to 2 upon 2295 publication 2297 This document defines a new ANCP Tech Type Name Space registry. The 2298 initial entries are as follows: 2300 +-----------------+----------------------------+---------------+ 2301 | Tech Type Value | Tech Type Name | Reference | 2302 +-----------------+----------------------------+---------------+ 2303 | 0x00 | Extension block not in use | This document | 2304 | 0x01 | PON | This document | 2305 | 0x05 | DSL | This document | 2306 | 0x06 - 0xFE | Reserved | This document | 2307 | 0xFF | Base Specification Use | This document | 2308 +-----------------+----------------------------+---------------+ 2310 This document defines a new ANCP Command Code registry. The initial 2311 entries are as follows: 2313 +-----------------------------+--------------------+---------------+ 2314 | Command Code Directive Name | Command Code Value | Reference | 2315 +-----------------------------+--------------------+---------------+ 2316 | Reserved | 0x00 | This document | 2317 +-----------------------------+--------------------+---------------+ 2319 This document defines a new ANCP TLV Type registry. The initial 2320 entries are as follows: 2322 +--------------------------------------+--------------+-------------+ 2323 | TLV Name | Type Code | Reference | 2324 +--------------------------------------+--------------+-------------+ 2325 | Access-Loop-Circuit-ID | 0x01 | This | 2326 | | | document | 2327 | Access-Loop-Remote-Id | 0x02 | This | 2328 | | | document | 2329 | Access-Aggregation-Circuit-ID-ASCII | 0x03 | This | 2330 | | | document | 2331 | DSL Line Attributes | 0x04 | This | 2332 | | | document | 2333 | Service-Profile-Name | 0x05 | This | 2334 | | | document | 2335 | Access-Aggregation-Circuit-ID-Binary | 0x06 | This | 2336 | | | document | 2337 | OAM-Loopback-Test-Parameters | 0x07 | This | 2338 | | | document | 2339 | Opaque-Data | 0x08 | This | 2340 | | | document | 2341 | OAM-Loopback-Test-Response-String | 0x09 | This | 2342 | | | document | 2343 | Reserved | 0x0a-0x0f | This | 2344 | | | document | 2345 | Target | 0x1000 - | This | 2346 | | 0X1020 | document | 2347 | Command | 0x11 | This | 2348 | | | document | 2349 | Status-info | 0x0106 | This | 2350 | | | document | 2351 +--------------------------------------+--------------+-------------+ 2353 This document defines a new ANCP Capability registry. The initial 2354 entries are as follows: 2356 +----------------------------+----------------------+---------------+ 2357 | Capability Type Name | Capability Type Code | Reference | 2358 +----------------------------+----------------------+---------------+ 2359 | Dynamic-Topology-Discovery | 0x01 | This document | 2360 | Line-Configuration | 0x02 | This document | 2361 | Transactional-Multicast | 0x03 | This document | 2362 | OAM | 0x04 | This document | 2363 +----------------------------+----------------------+---------------+ 2365 This document defines a new ANCP sub-TLV Type registry. The initial 2366 entries are as follows: 2368 +--------------------------------------------+--------+-------------+ 2369 | sub-TLV Name | Type | Reference | 2370 | | Code | | 2371 +--------------------------------------------+--------+-------------+ 2372 | Actual-Net-Data-Upstream | 0x81 | This | 2373 | | | document | 2374 | Actual-Net-Data-Rate-Downstream | 0x82 | This | 2375 | | | document | 2376 | Minimum-Net-Data-Rate-Upstream | 0x83 | This | 2377 | | | document | 2378 | Minimum-Net-Data-Rate-Downstream | 0x84 | This | 2379 | | | document | 2380 | Attainable-Net-Data-Rate-Upstream | 0x85 | This | 2381 | | | document | 2382 | Attainable-Net-Data-Rate-Downstream | 0x86 | This | 2383 | | | document | 2384 | Maximum-Net-Data-Rate-Upstream | 0x87 | This | 2385 | | | document | 2386 | Maximum-Net-Data-Rate-Downstream | 0x88 | This | 2387 | | | document | 2388 | Minimum-Net-Low-Power-Data-Rate-Upstream | 0x89 | This | 2389 | | | document | 2390 | Minimum-Net-Low-Power-Data-Rate-Downstream | 0x8A | This | 2391 | | | document | 2392 | Maximum-Interleaving-Delay-Upstream | 0x8B | This | 2393 | | | document | 2394 | Actual-Interleaving-Delay-Upstream | 0x8C | This | 2395 | | | document | 2396 | Maximum-Interleaving-Delay-Downstream | 0x8D | This | 2397 | | | document | 2398 | Actual-Interleaving-Delay-Downstream | 0x8E | This | 2399 | | | document | 2400 | DSL line state | 0x8F | This | 2401 | | | document | 2402 | Access Loop Encapsulation | 0x90 | This | 2403 | | | document | 2404 | DSL-Type | 0x91 | This | 2405 | | | document | 2406 +--------------------------------------------+--------+-------------+ 2408 7. Security Considerations 2410 Security of the ANCP protocol is discussed in [RFC5713] 2412 8. Acknowledgements 2414 The authors would like to thank everyone that has provided comments 2415 or inputs to this document. In particular, the authors acknowledge 2416 the inputs provided by Wojciech Dec, Peter Arberg, Josef Froehler, 2417 Derek Harkness, Kim Hyldgaard, Sandy Ng, Robert Peschi, Michel 2418 Platnic and Tom Taylor. 2420 9. References 2422 9.1. Normative References 2424 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2425 Requirement Levels", BCP 14, RFC 2119, March 1997. 2427 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 2428 RFC 3046, January 2001. 2430 [RFC3292] Doria, A., Hellstrand, F., Sundell, K., and T. Worster, 2431 "General Switch Management Protocol (GSMP) V3", RFC 3292, 2432 June 2002. 2434 [RFC3293] Worster, T., Doria, A., and J. Buerkle, "General Switch 2435 Management Protocol (GSMP) Packet Encapsulations for 2436 Asynchronous Transfer Mode (ATM), Ethernet and 2437 Transmission Control Protocol (TCP)", RFC 3293, June 2002. 2439 9.2. Informative References 2441 [ANCP-FRAMEWORK] 2442 Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. 2443 Wadhwa, "Framework and Requirements for an Access Node 2444 Control Mechanism in Broadband Multi-Service Networks", 2445 draft-ietf-ancp-framework-13.txt, work in progress, 2446 February 2010. 2448 [G.988.1] "ITU-T recommendation G.998.1, ATM-based multi-pair 2449 bonding", 2005. 2451 [G.988.2] "ITU-T recommendation G.998.2, Ethernet-based multi-pair 2452 bonding,", 2005. 2454 [RFC5713] Moustafa , H., Tschofenig, H., and S. De Cnodder, 2455 "Security Threats and Security Requirements for the Access 2456 Node Control Protocol (ANCP)", January 2010. 2458 [TR-058] Elias, M. and S. Ooghe, "DSL Forum TR-058, Multi-Service 2459 Architecture & Framework Requirements", September 2003. 2461 [TR-059] Anschutz, T., "DSL Forum TR-059, DSL Evolution - 2462 Architecture Requirements for the Support of QoS-Enabled 2463 IP Services", September 2003. 2465 [TR-092] "DSL Forum TR-092, Broadband Remote access server 2466 requirements document", 2005. 2468 [TR-101] Cohen et al, "Architecture & Transport: "Migration to 2469 Ethernet Based DSL Aggregation", DSL Forum TR-101", 2005. 2471 Authors' Addresses 2473 Sanjay Wadhwa 2474 Juniper Networks 2475 10 Technology Park Drive 2476 Westford, MA 01886 2477 USA 2479 Phone: 2480 Fax: 2481 Email: swadhwa@juniper.net 2483 Jerome Moisand 2484 Juniper Networks 2485 10 Technology Park Drive 2486 Westford, MA 01886 2487 USA 2489 Phone: 2490 Fax: 2491 Email: jmoisand@juniper.net 2492 Swami Subramanian 2493 Juniper Networks 2494 10 Technology Park Drive 2495 Westford, MA 01886 2496 USA 2498 Phone: 2499 Fax: 2500 Email: ssubramanian@juniper.net 2502 Thomas Haag 2503 Deutsche Telekom 2504 Heinrich-Hertz-Strasse 3-7 2505 Darmstadt, 64295 2506 Germany 2508 Phone: +49 6151 628 2088 2509 Fax: 2510 Email: haagt@telekom.de 2512 Norber Voigt 2513 Siemens 2515 Phone: 2516 Fax: 2517 Email: norbert.voigt@siemens.com 2519 Roberta Maglione 2520 Telecom Italia 2521 via Reiss Romoli 274 2522 Torino 2523 Italy 2525 Phone: 2526 Email: roberta.maglione@telecomitalia.it