idnits 2.17.1 draft-ooghe-ancp-framework-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 957. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 934. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 941. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 947. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2006) is 6556 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: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Ooghe 3 Internet-Draft Alcatel 4 Expires: November 2, 2006 N. Voigt 5 Siemens 6 M. Platnic 7 ECI Telecom 8 T. Haag 9 T-Systems 10 S. Wadhwa 11 Juniper Networks 12 May 2006 14 Framework and Requirements for an Access Node Control Mechanism in 15 Broadband Multi-Service Networks 16 draft-ooghe-ancp-framework-00.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on November 2, 2006. 43 Copyright Notice 45 Copyright (C) The Internet Society (2006). 47 Abstract 48 The purpose of this document is to define a framework for an Access 49 Node Control Mechanism between a Network Access Server (NAS) and an 50 Access Node (e.g. a Digital Subscriber Line Access Multiplexer 51 (DSLAM)) in a multi-service reference architecture in order to 52 perform QoS-related, service-related and Subscriber-related 53 operations. The Access Node Control Mechanism will ensure that the 54 transmission of the information does not need to go through distinct 55 element managers but rather using a direct device-device 56 communication. This allows for performing access link related 57 operations within those network elements, while avoiding impact on 58 the existing OSS systems. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 5 64 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 65 2. General Architecture Aspects . . . . . . . . . . . . . . . . . 6 66 2.1. Concept of an Access Node Control Mechanism . . . . . . . 6 67 2.2. Reference Architecture . . . . . . . . . . . . . . . . . . 7 68 2.2.1. Home Gateway . . . . . . . . . . . . . . . . . . . . . 7 69 2.2.2. Access Loop . . . . . . . . . . . . . . . . . . . . . 8 70 2.2.3. Access Node . . . . . . . . . . . . . . . . . . . . . 8 71 2.2.4. Access Node uplink . . . . . . . . . . . . . . . . . . 8 72 2.2.5. Aggregation Network . . . . . . . . . . . . . . . . . 8 73 2.2.6. Network Access Server . . . . . . . . . . . . . . . . 9 74 2.2.7. Regional Network . . . . . . . . . . . . . . . . . . . 9 75 2.3. Access Node Control Mechanism Transport methods . . . . . 9 76 2.4. Operation and Management . . . . . . . . . . . . . . . . . 10 77 2.4.1. Port Addressing Scheme . . . . . . . . . . . . . . . . 11 78 3. Use Cases for Access Node Control Mechanism . . . . . . . . . 12 79 3.1. Dynamic Access Loop Attributes . . . . . . . . . . . . . . 12 80 3.2. Access Loop Configuration . . . . . . . . . . . . . . . . 13 81 3.3. Remote Connectivity Test . . . . . . . . . . . . . . . . . 14 82 3.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 15 83 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 4.1. ANCP Functional Requirements . . . . . . . . . . . . . . . 16 85 4.2. Protocol Design Requirements . . . . . . . . . . . . . . . 17 86 4.3. ANCP transport requirements . . . . . . . . . . . . . . . 17 87 4.4. Access Node Requirements . . . . . . . . . . . . . . . . . 18 88 4.4.1. Access Node Architecture . . . . . . . . . . . . . . . 18 89 4.4.2. Access Node Control Connection attributes . . . . . . 18 90 4.4.3. Capability Negotiation . . . . . . . . . . . . . . . . 19 91 4.4.4. Adjacency Requirements . . . . . . . . . . . . . . . . 19 92 4.4.5. Access Node Identification . . . . . . . . . . . . . . 20 93 4.4.6. Message Handling . . . . . . . . . . . . . . . . . . . 20 94 4.4.7. Access Node Parameter Control . . . . . . . . . . . . 20 95 5. Policy Server Interaction . . . . . . . . . . . . . . . . . . 21 96 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 97 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 98 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 99 8.1. Normative References . . . . . . . . . . . . . . . . . . . 24 100 8.2. Informative References . . . . . . . . . . . . . . . . . . 24 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 102 Intellectual Property and Copyright Statements . . . . . . . . . . 27 104 1. Introduction 106 Digital Subscriber Line (DSL) technology is widely deployed for 107 Broadband Access for Next Generation Networks. Several documents 108 like DSL Forum TR-058 [TR-058], DSL Forum TR-059 [TR-059] and DSL 109 Forum TR-101 [TR-101] describe possible architectures for these 110 access networks. In the scope of these specifications is the 111 delivery of voice, video and data services. The framework defined by 112 this document is targeted at DSL-based access (either by means of 113 ATM/DSL or as Ethernet/DSL). 115 Traditional architectures require permanent virtual circuit(s) per 116 Subscriber. Such virtual circuit is configured on layer 2 and 117 terminated at the first layer 3 device (e.g. Broadband Remote Access 118 Server (BRAS)). Beside the data plane, the models define the 119 architectures for element, network and service management. But due 120 to organizational boundaries between departments operating the local 121 loop, departments operating the ATM network, and departments 122 operating the IP network interworking at the management plane is not 123 always possible. Besides, management networks are usually not 124 designed to transmit management data between the different entities 125 in real time. 127 When deploying value-added services across DSL access networks, 128 special attention regarding quality of service and service control is 129 required, which implies a tighter coordination between Network Nodes 130 (e.g. Access Nodes and NAS), without burdening the OSS layer with 131 unpractical expectations. 133 Therefore, there is a need for an Access Node Control Mechanism 134 between a Network Access Server (NAS) and an Access Node (e.g. a 135 Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi- 136 service reference architecture in order to perform QoS-related, 137 service-related and Subscriber-related operations. The Access Node 138 Control Mechanism will ensure that the transmission of the 139 information does not need to go through distinct element managers but 140 rather using a direct device-device communication. This allows for 141 performing access link related operations within those network 142 elements, while avoiding impact on the existing OSS systems. 144 This document provides a framework for such an Access Node Control 145 Mechanism and identifies a number of use cases for which this 146 mechanism can be justified. Next, it presents a number of 147 requirements for the Access Node Control Protocol (ANCP) and the 148 network elements that need to support it. 150 1.1. Requirements notation 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [RFC2119]. 156 1.2. Definitions 158 o Access Node (AN): Network device, usually located at a service 159 provider central office or street cabinet, that terminates Access 160 Loop connections from Subscribers. In case the Access Loop is a 161 Digital Subscriber Line (DSL), this is often referred to as a DSL 162 Access Multiplexer (DSLAM). 164 o Network Access Server (NAS): Network device which aggregates 165 multiplexed Subscriber traffic from a number of Access Nodes. The 166 NAS plays a central role in per-subscriber policy enforcement and 167 QoS. Often referred to as an Broadband Network Gateway (BNG) or 168 Broadband Remote Access Server (BRAS). A detailed definition of 169 the NAS is given in [RFC2881]. 171 2. General Architecture Aspects 173 In this section first the concept of the Access Node Control 174 Mechanism is described. Then, the reference architecture is 175 described where the Access Node Control Mechanism is introduced. 177 2.1. Concept of an Access Node Control Mechanism 179 The high-level communication framework for an Access Node Control 180 Mechanism is defined in Figure 1. The Access Node Control Mechanism 181 defines a general-purpose method for multiple network scenarios with 182 an extensible communication scheme, addressing the different use 183 cases that are described throughout this document. 185 +--------+ 186 | Policy | 187 | Server | 188 +--------+ 189 | 190 | 191 +-----+ +-----+ +--------+ +-----+ +----------+ 192 | CPE |---| HGW |---| | | | | | 193 +-----+ +-----+ | Access | +---------+ | | | Regional | 194 | Node |---| Aggreg. |---| NAS |---| Network | 195 +-----+ +-----+ | | | Node | | | | | 196 | CPE |---| HGW |---| | +---------+ | | | | 197 +-----+ +-----+ +--------+ +-----+ +----------+ 198 Information Reports 199 --------------------------> 200 Control Requests 201 <-------------------------- 202 Control Responses 203 --------------------------> 205 Access Node Control Mechanism 206 <-------------------------> 207 PPP, DHCP, IP 208 <---------><-------------------------------------> 210 Figure 1 212 From a functional perspective, a number of functions can be 213 identified: 215 o A controller function: this function is used to either send out 216 requests for information to be used by the network element where 217 the controller function resides, or to trigger a certain behavior 218 in the network element where the reporting and/or enforcement 219 function resides; 221 o A reporting and/or enforcement function: the reporting function is 222 used to convey status information to the controller function that 223 requires the information for executing local functions. An 224 example of this is the transmission of an Access Loop data rate 225 from an Access Node to a Network Access Server (NAS) tasked with 226 shaping traffic to that rate. The enforcement function can be 227 contacted by the controller function to trigger a local action. 228 An example of this is the initiation of a port testing mechanism 229 on an Access Node. 231 The use cases in this document are described in an abstract way, 232 independent from any actual protocol mapping. The actual protocol 233 specification is out of scope of this document, but there are certain 234 characteristics of the protocol required such as to simplify 235 specification, implementation, debugging & troubleshooting, but also 236 to be easily extensible in order to support additional use cases. 238 2.2. Reference Architecture 240 The reference architecture used in this document can be based on ATM 241 or Ethernet access/aggregation. Specifically: 243 o In case of a legacy ATM aggregation network that is to be used for 244 the introduction of new QoS-enabled IP services, the architecture 245 builds on the reference architecture specified in DSL Forum [TR- 246 059]; 248 o In case of an Ethernet aggregation network that supports new QoS- 249 enabled IP services (including Ethernet multicast replication), 250 the architecture builds on the reference architecture specified in 251 DSL Forum [TR-101]. 253 Given the industry's move towards Ethernet as the new access and 254 aggregation technology for triple play services, the primary focus 255 throughout this document is on a TR-101 architecture. However the 256 concepts are equally applicable to an ATM architecture based on TR- 257 059. 259 2.2.1. Home Gateway 261 The Home Gateway (HGW) connects the different Customer Premises 262 Equipment (CPE) to the Access Node and the access network. In case 263 of DSL, the HGW is a DSL Network Termination (NT) that could either 264 operate as a layer 2 bridge or as a layer 3 router. In the latter 265 case, such a device is also referred to as a Routing Gateway (RG). 267 2.2.2. Access Loop 269 The Access Loop ensures physical connectivity between the Network 270 Interface Device (NID) at the customer premises, and the Access Node. 271 Legacy protocol encapsulations use multi-protocol encapsulation over 272 AAL5, defined in RFC2364. This covers PPP over Ethernet (PPPoE, 273 defined in RFC2516), bridged IP (IPoE) and routed IP (IPoA, defined 274 in RFC2225). Next to this, PPPoA as defined in RFC2364 can be used. 275 Future scenarios include cases where the Access Loop supports direct 276 Ethernet encapsulation (e.g. when using VDSL). 278 2.2.3. Access Node 280 The Access Node (AN) is a network device, usually located at a 281 service provider central office or street cabinet, that terminates 282 Access Loop connections from Subscribers. In case the Access Loop is 283 a Digital Subscriber Line (DSL), this is often referred to as a DSL 284 Access Multiplexer (DSLAM). The AN may support one or more Access 285 Loop technologies and allow them to inter-work with a common 286 aggregation network technology. 288 Besides the Access Loop termination the AN can also aggregate traffic 289 from other Access Nodes using ATM or Ethernet. 291 The framework defined by this document is targeted at DSL-based 292 access (either by means of ATM/DSL or as Ethernet/DSL). The 293 framework shall be open to non-DSL technologies, like Passive Optical 294 Networks (PON) and IEEE 802.16 (WiMAX), but the details of this are 295 outside the scope of this document. 297 The reporting and/or enforcement function defined in Section 2.1 298 typically resides in an Access Node. 300 2.2.4. Access Node uplink 302 The fundamental requirements for the Access Node uplink are to 303 provide traffic aggregation, Class of Service distinction and 304 customer separation and traceability. This can be achieved using an 305 ATM or an Ethernet based technology. 307 2.2.5. Aggregation Network 309 The aggregation network provides traffic aggregation towards the NAS. 310 The aggregation technology can be based on ATM (in case of a TR-059 311 architecture) or Ethernet (in case of a TR-101 architecture). 313 2.2.6. Network Access Server 315 The NAS is a network device which aggregates multiplexed Subscriber 316 traffic from a number of Access Nodes. The NAS plays a central role 317 in per-subscriber policy enforcement and QoS. It is often referred 318 to as a Broadband Network Gateway (BNG) or Broadband Remote Access 319 Server (BRAS). A detailed definition of the NAS is given in RFC2881. 321 The NAS interfaces to the aggregation network by means of standard 322 ATM or Ethernet interfaces, and towards the regional broadband 323 network by means of transport interfaces for Ethernet frames (e.g. 324 GigE, Ethernet over SONET). The NAS functionality correpsonds to the 325 BNG functionality described in DSL Forum TR-101. In addition to 326 this, the NAS supports the Access Node Control functionality defined 327 for the respective use cases throughout this document. 329 The controller function defined in Section 2.1 typically resides in a 330 NAS. 332 2.2.7. Regional Network 334 The Regional Network connects one or more NAS and associated Access 335 Networks to Network Service Providers (NSPs) and Application Service 336 Providers (ASPs). The NSP authenticates access and provides and 337 manages the IP address to Subscribers. It is responsible for overall 338 service assurance and includes Internet Service Providers (ISPs). 339 The ASP provides application services to the application Subscriber 340 (gaming, video, content on demand, IP telephony etc.). 342 The Regional Network supports aggregation of traffic from multiple 343 Access Networks and hands off larger geographic locations to NSPs and 344 ASPs - relieving a potential requirement for them to build 345 infrastructure to attach more directly to the various Access 346 Networks. 348 2.3. Access Node Control Mechanism Transport methods 350 The connectivity between the Access Node and the NAS may differ 351 depending on the actual layer 2 technology used (ATM or Ethernet). 352 Therefore the identification of unicast & multicast flows/channels 353 will also differ (see also Section 2.4.1). 355 In case of an ATM access/aggregation network, the Access Node Control 356 messages are sent over a dedicated Permanent Virtual Circuit (PVC) 357 configured between the AN and the NAS. These ATM PVCs should be 358 given a high priority (e.g. by using a Constant Bitrate (CBR) 359 connection) so that the ATM cells carrying the Access Node Control 360 messages are not lost in the event of congestion. It is discouraged 361 to route the Access Node Control messages within the VP that also 362 carries the customer connections, if that VP is configured with a 363 best effort QoS class (e.g. Unspecified Bitrate (UBR)). The PVCs of 364 multiple Access Node Control connections can be routed into a Virtual 365 Path (VP) that is given a high priority and runs across the 366 aggregation network. This requires the presence of a VC cross- 367 connect in the aggregation node that terminates the VP. 369 In case of an Ethernet access/aggregation network, the Access Node 370 Control messages are sent over a dedicated Ethernet Virtual LAN 371 (VLAN) using a separate VLAN identifier. Depending on penetration 372 and network design, this can be a simple VLAN for each Access Node 373 or, for higher-grade connections and bundling, one Customer VLAN 374 (C-VLAN) for each Access Node and one Service VLAN (S-VLAN) for all 375 the control connections of every Access Node. These VLANs should be 376 given a high priority (e.g. by using a high Class of Service (CoS) 377 value) so that the Ethernet frames carrying the Access Node Control 378 messages are not lost in the event of congestion. 380 The control connection between NAS and Access Node uses the same 381 physical network- and routing resources as the Subscriber traffic. 382 This means that the connection is an inband connection between the 383 involved network elements. Therefore there is no need for an 384 additional physical interface to establish the control connection. 386 The control plane interactions are transactional in nature and imply 387 a reliable communication channel to share states. Bidirectional 388 operations are needed, as well as dynamic negotiation of capabilities 389 to address transition issues. 391 2.4. Operation and Management 393 When introducing an Access Node Control Mechanism, care is needed to 394 ensure that the existing management mechanisms remain operational as 395 before. 397 Specifically when using the Access Node Control Mechanism for 398 performing a configuration action on a network element, one gets 399 confronted with the challenge of supporting multiple managers for the 400 same network element: both the Element Manager as well as the Access 401 Node Control Mechanism may now perform configuration actions on the 402 same network element. Conflicts therefore need to be avoided. 404 Also, when using the Access Node Control Mechanism for performing a 405 reporting action, there is a possibility to integrate this with a 406 central Policy Management system that keeps track of the different 407 Subscriber related parameters (e.g. Access Loop net data rate). 409 2.4.1. Port Addressing Scheme 411 In deployments using an ATM aggregation network, the ATM PVC on an 412 Access Loop connects the Subscriber to a NAS. Based on such 413 property, in a PPP scenario, the NAS typically includes a NAS-Port-Id 414 (or NAS-Port in some cases) attribute in RADIUS authentication & 415 accounting packets sent to the RADIUS server(s). Such attribute 416 includes the identification of the ATM VC for this Subscriber, which 417 allows in turn identifying the Access Loop. 419 In an Ethernet-based aggregation network, the port addressing scheme 420 is defined in TR-101. Two mechanisms can be used: 422 o A first approach is to use a one-to-one VLAN assignment model for 423 all DSL ports. This allows the Access Loop identification to be 424 directly derived from the VLAN tagging, i.e. S-VLAN ID or pair, of the frames coming from this Access Loop; 427 o A second approach is to use a many-to-one VLAN assignment model 428 and to encode the Access Loop identification in the "Agent Circuit 429 ID" sub-option to be added to a DHCP or PPPoE message. The 430 details of this approach are specified in TR-101. 432 This document reuses the port addressing scheme specified in TR-101. 433 It should be noted however that the use of such a scheme does not 434 imply the actual existence of a PPPoE or DHCP session, nor on the 435 specific interworking function present in the Access Node. In some 436 cases, no PPPoE or DHCP session may be present, while the port 437 addressing would still be desirable. 439 3. Use Cases for Access Node Control Mechanism 441 3.1. Dynamic Access Loop Attributes 443 [TR-059] and [TR-101] discuss various queuing/scheduling mechanisms 444 to avoid congestion in the access network while dealing with multiple 445 flows with distinct QoS requirements. Such mechanisms require that 446 the NAS gains knowledge about the topology of the access network, the 447 various links being used and their respective rates. Some of the 448 information required is somewhat dynamic in nature (e.g. DSL actual 449 data rate, also known as the "DSL sync rate"), hence cannot come from 450 a provisioning and/or inventory management OSS system. Some of the 451 information varies less frequently (e.g. capacity of a DSLAM uplink), 452 but nevertheless needs to be kept strictly in sync between the actual 453 capacity of the uplink and the image the BRAS has of it. 455 OSS systems are rarely able to enforce in a reliable and scalable 456 manner the consistency of such data, notably across organizational 457 boundaries. The Access Port Discovery function allows the NAS to 458 perform these advanced functions without having to depend on an 459 error-prone & possibly complex integration with an OSS system. 461 Communicating Access Loop attributes is specifically important in 462 case the rate of the Access Loop changes overtime. The DSL actual 463 data rate may be different every time the DSL NT is turned on. 464 Additionally, during the time the DSL NT is active, data rate changes 465 can occur due to environmental conditions (the DSL Access Loop can 466 get "out of sync" and can retrain to a lower value, or the DSL Access 467 Loop could use Seamless Rate Adaptation making the actual data rate 468 fluctuate while the line is active). 470 The hierarchy and the rates of the various links to enable the NAS 471 hierarchical scheduling and policing mechanisms are the following: 473 o The identification and speed (data rate) of the DSL Access Loop 474 (also known as the "DSL sync rate") 476 o The identification and speed (data rate) of the Remote 477 Terminal(RT)/Access Node link (when relevant) 479 The NAS can adjust downstream shaping to current Access Loop actual 480 data rate, and more generally re-configure the appropriate nodes of 481 its hierarchical scheduler (support of advanced capabilities 482 according to TR-101). 484 This use case may actually include more information than link 485 identification and corresponding data rates. In case of DSL Access 486 Loops, the following Access Loop characteristics can be sent to the 487 NAS (cf. ITU-T Recommendation G.997.1 [G.997.1]): 489 o DSL Type (e.g. ADSL1, ADSL2, SDSL, VDSL) 491 o Framing mode (e.g. ATM, ITU-T Packet Transfer Mode (PTM), IEEE 492 802.3 Ethernet in the First Mile (EFM)) 494 o DSL port state (e.g. synchronized/showtime, low power, no power/ 495 idle) 497 o Actual net data rate (upstream/downstream) 499 o Maximum achievable/attainable data rate (upstream/downstream) 501 o Minimum data rate configured for the Access Loop (upstream/ 502 downstream) 504 o Maximum data rate configured for the Access Loop (upstream/ 505 downstream) 507 o Minimum data rate in low power state configured for the Access 508 Loop (upstream/downstream) 510 o Maximum achievable interleaving delay (upstream/downstream) 512 o Actual interleaving delay (upstream/downstream) 514 The NAS MUST be able to receive Access Loop characteristics 515 information, and share such information with AAA/policy servers. 517 3.2. Access Loop Configuration 519 Access Loop rates are typically configured in a static way. If a 520 Subscriber wants to change its Access Loop rate, this requires an 521 OPEX intensive reconfiguration of the access port configuration via 522 the network operator, possibly implying a business-to-business 523 transaction between an Internet Service Provider (ISP) and an Access 524 Provider. 526 Using the Access Node Control Mechanism to change the Access Loop 527 rate from the NAS avoids those cross-organization business-to- 528 business interactions and allows to centralize Subscriber-related 529 service data in e.g. a policy server. More generally, several Access 530 Loop parameters (e.g. minimum data rate, interleaving delay) could be 531 changed by means of the Access Node Control Mechanism. 533 Triggered by the communication of the Access Loop attributes 534 described in Section 3.1, the NAS could query a policy server (e.g. 536 RADIUS server) to retrieve Access Loop configuration data. The best 537 way to change Access Loop parameters is by using profiles. These 538 profiles (e.g. DSL profiles for different services) are pre- 539 configured by the Element Manager managing the Access Nodes. The NAS 540 may then use the the Configure Request message to send a reference to 541 the right profile to the Access Node. The NAS may also update the 542 Access Loop configuration due to a Subscriber service change (e.g. 543 triggered by the policy server). 545 The Access Loop Configuration mechanism may also be useful for 546 configuration of parameters that are not specific to the Access Loop 547 technology. Examples include the QoS profile to be used for an 548 Access Loop, or the per-Subscriber multicast channel entitlement 549 information, used for IPTV applications where the Access Node is 550 performing IGMP snooping or IGMP proxy function. The latter is also 551 discussed in Section 3.4. 553 3.3. Remote Connectivity Test 555 Traditionally, ATM circuits are point to point connections between 556 the BRAS and the DSLAM or DSL NT. In order to test the connectivity 557 on layer 2, appropriate OAM functionality is used for operation and 558 troubleshooting. An end-to-end OAM loopback is performed between the 559 edge devices (NAS and HGW) of the broadband access network. 561 When migrating to an Ethernet-based aggregation network (as defined 562 by TR-101), end to end ATM OAM functionality is no longer applicable. 563 Ideally in an Ethernet aggregation network, end-to-end Ethernet OAM 564 as specified in IEEE 802.1ag and ITU-T Recommendation Y.1730/1731 can 565 provide Access Loop connectivity testing and fault isolation. 566 However, most HGWs do not yet support these standard Ethernet OAM 567 procedures. Also, various access technologies exist such as ATM/DSL, 568 Ethernet in the First Mile (EFM) etc. Each of these access 569 technologies have their own link-based OAM mechanisms that have been 570 or are being standardized in different standard bodies. 572 In a mixed Ethernet and ATM access network (including the local 573 loop), it is desirable to keep the same ways to test and troubleshoot 574 connectivity as those used in an ATM based architecture. To reach 575 consistency with the ATM based approach, an Access Node Control 576 Mechanism between NAS and Access Node can be used until end-to-end 577 Ethernet OAM mechanisms are more widely available. 579 Triggered by a local management interface, the NAS can use the Access 580 Node Control Mechanism to initiate an Access Loop test between Access 581 Node and HGW. In case of an ATM based Access Loop the Access Node 582 Control Mechanism can trigger the Access Node to generate ATM (F4/F5) 583 loopback cells on the Access Loop. In case of Ethernet, the Access 584 Node can perform a port synchronization and administrative test for 585 the access loop. The Access Node can send the result of the test to 586 the NAS via a Subscriber Response message. The NAS may then send the 587 result via a local management interface. Thus, the connectivity 588 between the NAS and the HGW can be monitored by a single trigger 589 event. 591 3.4. Multicast 593 With the rise of supporting IPTV services in a resource efficient 594 way, multicast services are getting increasingly important. This 595 especially holds for an Ethernet-based access/aggregation 596 architecture. In such a architecture, the Access Node, aggregation 597 node(s) and the NAS are involved in the multicast replication 598 process, thereby avoiding that serveral copies of the same stream are 599 sent within the network. 601 Typically IGMP is used to control the multicast content replication 602 process within the access/aggregation network. This is achieved by 603 means of IGMP snooping or IGMP proxy in the Access Node, aggregation 604 node(s) and the NAS. However, a Subscriber's policy and 605 configuration for multicast traffic might only be known at the NAS. 606 The Access Node Control Mechanism could be used to exchange the 607 necessary information between the Access Node and the NAS so as to 608 allow the Access Node to perform multicast replication in line with 609 the Subscriber's policy and configuration, and also allow the NAS to 610 follow each Subscriber's multicast group membership. 612 4. Requirements 614 4.1. ANCP Functional Requirements 616 o The ANCP MUST address all use cases described in this document, 617 and be general-purpose and extensible enough to foresee additional 618 use cases (including the use of other Access Nodes than a DSLAM, 619 e.g. a PON Access Node). 621 o The ANCP must be flexible enough to accommodate the various 622 technologies that can be used in an access network and in the 623 Access Node. 625 o The ANCP MUST be an open protocol, either an existing protocol 626 endorsed by an appropriate standard body (e.g. IETF) or a new 627 protocol which will be submitted for standardization to an 628 appropriate standard body. It must be possible for other 629 organizations to define additional protocol information elements. 631 o The ANCP MUST be transaction-oriented, allowing to reliably share 632 states between the NAS and the Access Node, and recover from loss 633 of synchronization (e.g. node or link failure). Transactions MUST 634 be either fully completed, or rolled-back to the previous state. 636 o The ANCP MUST be able to recover from access network connectivity 637 disruption and automatically resynchronize. It MUST also be able 638 to recover from message losses on the access network. 640 o The ANCP MUST allow fast-paced transactions, in the order of 641 magnitude of tens of transactions per second between a given pair 642 (Access Node, NAS). The protocol MUST allow fast completion of a 643 given operation, in the order of magnitude of tens of 644 milliseconds. The protocol MUST be scalable enough to allow a 645 given NAS to control hundreds of Access Nodes. 647 o The ANCP MUST be simple and lightweight enough to allow an 648 implementation on Access Nodes with limited control plane 649 resources (e.g. CPU and memory). 651 o The ANCP MUST ensure the authenticity of the message initiator and 652 the integrity of the messages. The main goal is to protect the 653 systems (Access Nodes and NAS) against attacks. 655 o The ANCP SHOULD minimize sources of configuration mismatch, help 656 automation of the overall operation of the systems involved 657 (Access Nodes and NAS) and be easy to troubleshoot. 659 o The implementation of the ANCP in the NAS and Access Nodes MUST be 660 manageable via an element management interface. This MUST allow 661 to retrieve statistics and alarms (e.g. via SNMP) about the 662 operation of the ANCP, as well as initiate OAM operations and 663 retrieve corresponding results. 665 o A NAS supporting the ANCP MUST correlate layer 2 configuration 666 data with the AAA authorization process and related Subscriber 667 data. 669 4.2. Protocol Design Requirements 671 o The ANCP SHOULD have a "boot" sequence allowing to inform the peer 672 about control capabilities supported by the two peers (Access 673 Node, NAS) and negotiate a common subset. This sequence SHOULD be 674 such that a system supporting the ANCP would automatically 675 recognize when its peer doesn't support it at all. 677 o The ANCP SHOULD include a "keep-alive" mechanism to automatically 678 detect loss of connectivity on the access network or failure of 679 the peer node. 681 o The ANCP SHOULD provide a "shutdown" sequence allowing to inform 682 the peer that the system is gracefully shutting down. 684 o The ANCP SHOULD include a "request/response" transaction-oriented 685 model for the NAS to communicate control decisions or request 686 information from the Access Node. If the response is negative, 687 then the state of the Access Node MUST be unchanged (roll-back). 689 o The ANCP SHOULD include a "report" model for the Access Node to 690 spontaneously communicate to the NAS changes of states. 692 o The ANCP SHOULD support a graceful restart mechanism to enable it 693 to be resilient to network failures between the AN and NAS. 695 o The ANCP MUST be mapped on top of the IP network layer and make 696 use of IPoA or IPoE on ATM or Ethernet, respectively (possibly via 697 a transport layer). 699 4.3. ANCP transport requirements 701 o The Access Node Control Mechanism MUST be defined in a way that is 702 independent of the underlying layer 2 transport technology. 703 Specifically, the Access Node Control Mechanism MUST support 704 transmission over an ATM as well as over an Ethernet aggregation 705 network. 707 o If the layer 2 transport technology is based on ATM, then the 708 encapsulation MUST be according to RFC2684. 710 o The transport protocol used for the Access Node Control messages 711 MUST be reliable and scalable. 713 o A loss of the control connection MUST NOT affect user connectivity 714 and element operation. 716 o If the connection is lost, it MUST NOT lead to undefined states on 717 the network elements. 719 o For maintenance purpose the Access Node Control connection MUST be 720 designed in a way that any malfunction of the connection is 721 automatically detected and reported from the Access Node or NAS to 722 the Element Manager or Network Manager to support the network 723 operator in troubleshooting the network. 725 4.4. Access Node Requirements 727 4.4.1. Access Node Architecture 729 The Access Node Control Mechanism is defined by a dedicated relation 730 between the Access Node (AN) and the NAS. If one service provider 731 has multiple physical NAS devices which represent one logical device 732 (single edge architecture) one DSLAM can be connected to more than 733 one NAS. Therefore the physical DSLAM needs to be split in virtual 734 DSLAMs each having its own Access Node Control controler 736 o An Access Node as physical device can be split in logical 737 partitions. Each partition MAY have its independent NAS. 738 Therefore the Access Node MUST support at least 2 partitions. The 739 Access Node SHOULD support 8 partitions. 741 o One partition is grouped of several DSL ports. Each physical DSL 742 port of an Access Node MUST be assigned uniquely to one partition. 744 o Each AN partition MUST have a separate control connection to a NAS 745 and SHOULD be able to enforce access control on the controllers to 746 only designated partitions being bound to one controller. 748 o The Access Node SHOULD be able to work with redundant controllers. 750 4.4.2. Access Node Control Connection attributes 752 Dependent on network topology the Access Node can be located in 753 street cabinet or central office installation. If an Access Node in 754 street cabinet installation is connected to a NAS all user and Access 755 Node Control data use the same physical link. Usually, remote Access 756 Nodes are aggregated by an aggregation network and connected to the 757 NAS. Certain connection attributes must be supported 759 o The Access Node Control Mechanism SHOULD use the same facilities 760 as the ones used for the data traffic. 762 o The Access Node Control Connection MUST be terminated at the 763 Access Node. 765 o For security purposes, the Access Node Control messages sent over 766 the control connection MUST NOT be sent towards the customer 767 premises 769 o The Access Node MUST NOT support the capability to configure 770 sending Access Node Control messages towards the customer 771 premises. 773 o Control transactions SHOULD be processed in a timely fashion. 775 o Access Node Control messages SHOULD be marked with a high priority 776 (e.g. VBR-rt or CBR for ATM cells, p-bit 6 or 7 for Ethernet 777 packets) in order for the packets not to be dropped in case of 778 congestion. 780 o If ATM interfaces are used VPI as well as VCI value MUST be 781 configurable in the full range. 783 o If Ethernet interfaces are used, C-Tag as well as S-Tag MUST be 784 configurable in the full range. 786 4.4.3. Capability Negotiation 788 o The Access Node MUST provide a capability to indicate which use 789 cases are supported. 791 o In case the Access Node and NAS cannot agree on a common set of 792 capabilities, the Access Node MUST report this failure to network 793 management. 795 4.4.4. Adjacency Requirements 797 o The Access Node MUST be able to support an adjacency protocol used 798 to synchronize states across the link, discover the identity of 799 the entity at the other end of a link, and detect when it changes. 801 o The Access Node SHOULD report adjacency establishment or loss of 802 adjacency with the controller to network management. 804 4.4.5. Access Node Identification 806 o To identify the Access Node and Access Port within a control 807 domain a unique identifier is required. This identifier MUST be 808 in line with the addressing scheme principles specified in section 809 3.9.3 of TR-101. 811 4.4.6. Message Handling 813 o The Access Node SHOULD dampen notifications related to line 814 attributes or line state. 816 o The Access Node SHOULD be able to handle sending/receiving a large 817 burst of messages efficiently (e.g. using mechanisms like "message 818 bundling"). 820 4.4.7. Access Node Parameter Control 822 Naturally the Access Node Control Mechanism is not designed to 823 replace an Element Manager managing the Access Node. There are 824 parameters primarily layer 1 in the Access Node such as the DSL noise 825 margin and DSL Power Spectral Densities (PSD) which are not allowed 826 to be configured by ANCP or any other control connection except the 827 Element Manager. This has to be ensured and protected by the Access 828 Node. It needs to be configured in the Access Node which parameters 829 are allowed (resp. not allowed) to be modified by the Access Node 830 Control Mechanism, how parameters should be modified, stored, or 831 overwritten It needs to be defined the default parameter set the 832 Access Node will come up after recovery. 834 o It MUST be possible to configure which parameters can be modified. 836 5. Policy Server Interaction 838 This document does not consider the specific details of the 839 communication with a policy server (e.g. using RADIUS). 841 6. Security Considerations 843 TBD 845 7. Acknowledgements 847 The authors would like to thank everyone that has provided comments 848 or input to this document. In particular, the authors acknowledge 849 the work done by the contributors to the DSL Forum related activites: 850 Jerome Moisand, Wojciech Dec, Peter Arberg and Ole Helleberg 851 Andersen. 853 8. References 855 8.1. Normative References 857 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 858 Requirement Levels", RFC 2119, March 1997. 860 8.2. Informative References 862 [G.997.1] ITU-T, "Physical layer management for digital subscriber 863 line (DSL) transceivers", ITU-T Rec. G.997.1, Sep 2005. 865 [RFC2881] Mitton, D. and M. Beadles, "Network Access Server 866 Requirements Next Generation (NASREQNG) NAS Model", 867 RFC 2881, Jul 2000. 869 [TR-058] Elias, M. and S. Ooghe, "Multi-Service Architecture & 870 Framework Requirements", DSL Forum TR-058, September 2003. 872 [TR-059] Anschutz, T., "DSL Evolution - Architecture Requirements 873 for the Support of QoS-Enabled IP Services", DSL Forum TR- 874 059, September 2003. 876 [TR-101] Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSL 877 Aggregation", DSL Forum TR-101, May 2006. 879 Authors' Addresses 881 Sven Ooghe 882 Alcatel 883 Francis Wellesplein 1 884 B-2018 Antwerp 885 Belgium 887 Phone: +32 3 240 42 26 888 Email: sven.ooghe@alcatel.be 890 Norbert Voigt 891 Siemens 892 Siemensallee 1 893 17489 Greifswald 894 Germany 896 Phone: +49 3834 555 771 897 Email: norbert.voigt@siemens.com 899 Michel Platnic 900 ECI Telecom 901 30 Hasivim Street 902 49517 Petakh Tikva 903 Israel 905 Phone: + 972 3 926 85 35 906 Email: michel.platnic@ecitele.com 908 Thomas Haag 909 T-Systems 910 Deutsche Telekom Allee 7 911 64295 Darmstadt 912 Germany 914 Phone: +49 6151 937 5347 915 Email: thomas.haag@t-systems.com 916 Sanjay Wadhwa 917 Juniper Networks 918 10 Technology Park Drive 919 Westford, MA 01886 920 US 922 Phone: 923 Email: swadhwa@juniper.net 925 Intellectual Property Statement 927 The IETF takes no position regarding the validity or scope of any 928 Intellectual Property Rights or other rights that might be claimed to 929 pertain to the implementation or use of the technology described in 930 this document or the extent to which any license under such rights 931 might or might not be available; nor does it represent that it has 932 made any independent effort to identify any such rights. Information 933 on the procedures with respect to rights in RFC documents can be 934 found in BCP 78 and BCP 79. 936 Copies of IPR disclosures made to the IETF Secretariat and any 937 assurances of licenses to be made available, or the result of an 938 attempt made to obtain a general license or permission for the use of 939 such proprietary rights by implementers or users of this 940 specification can be obtained from the IETF on-line IPR repository at 941 http://www.ietf.org/ipr. 943 The IETF invites any interested party to bring to its attention any 944 copyrights, patents or patent applications, or other proprietary 945 rights that may cover technology that may be required to implement 946 this standard. Please address the information to the IETF at 947 ietf-ipr@ietf.org. 949 Disclaimer of Validity 951 This document and the information contained herein are provided on an 952 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 953 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 954 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 955 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 956 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 957 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 959 Copyright Statement 961 Copyright (C) The Internet Society (2006). This document is subject 962 to the rights, licenses and restrictions contained in BCP 78, and 963 except as set forth therein, the authors retain all their rights. 965 Acknowledgment 967 Funding for the RFC Editor function is currently provided by the 968 Internet Society.