idnits 2.17.1 draft-ietf-ancp-framework-04.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, updated by RFC 4748 on line 1677. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1688. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1695. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1701. 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 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 IETF Trust 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 (November 15, 2007) is 6004 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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-Lucent 4 Intended status: Informational N. Voigt 5 Expires: May 18, 2008 Nokia Siemens Networks 6 M. Platnic 7 ECI Telecom 8 T. Haag 9 T-Systems 10 S. Wadhwa 11 Juniper Networks 12 November 15, 2007 14 Framework and Requirements for an Access Node Control Mechanism in 15 Broadband Multi-Service Networks 16 draft-ietf-ancp-framework-04.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 May 18, 2008. 43 Copyright Notice 45 Copyright (C) The IETF Trust (2007). 47 Abstract 49 The purpose of this document is to define a framework for an Access 50 Node Control Mechanism between a Network Access Server (NAS) and an 51 Access Node (e.g. a Digital Subscriber Line Access Multiplexer 52 (DSLAM)) in a multi-service reference architecture in order to 53 perform QoS-related, service-related and Subscriber-related 54 operations. The Access Node Control Mechanism will ensure that the 55 transmission of the information does not need to go through distinct 56 element managers but rather using a direct device-device 57 communication. This allows for performing access link related 58 operations within those network elements, while avoiding impact on 59 the existing OSS systems. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 65 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 66 2. General Architecture Aspects . . . . . . . . . . . . . . . . . 7 67 2.1. Concept of an Access Node Control Mechanism . . . . . . . 7 68 2.2. Reference Architecture . . . . . . . . . . . . . . . . . . 8 69 2.2.1. Home Gateway . . . . . . . . . . . . . . . . . . . . . 8 70 2.2.2. Access Loop . . . . . . . . . . . . . . . . . . . . . 9 71 2.2.3. Access Node . . . . . . . . . . . . . . . . . . . . . 9 72 2.2.4. Access Node Uplink . . . . . . . . . . . . . . . . . . 9 73 2.2.5. Aggregation Network . . . . . . . . . . . . . . . . . 10 74 2.2.6. Network Access Server . . . . . . . . . . . . . . . . 10 75 2.2.7. Regional Network . . . . . . . . . . . . . . . . . . . 10 76 2.3. Access Node Control Mechanism Transport Methods . . . . . 10 77 2.4. Operation and Management . . . . . . . . . . . . . . . . . 11 78 2.4.1. Circuit Addressing Scheme . . . . . . . . . . . . . . 12 79 3. Use Cases for Access Node Control Mechanism . . . . . . . . . 13 80 3.1. Access Topology Discovery . . . . . . . . . . . . . . . . 13 81 3.2. Access Loop Configuration . . . . . . . . . . . . . . . . 15 82 3.3. Remote Connectivity Test . . . . . . . . . . . . . . . . . 16 83 3.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 17 84 3.4.1. Multicast Conditional Access . . . . . . . . . . . . . 17 85 3.4.2. Multicast Admission Control . . . . . . . . . . . . . 20 86 3.4.3. Multicast Accounting . . . . . . . . . . . . . . . . . 21 87 3.4.4. Multicast Termination . . . . . . . . . . . . . . . . 22 88 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 23 89 4.1. ANCP Functional Requirements . . . . . . . . . . . . . . . 23 90 4.2. ANCP Multicast Requirements . . . . . . . . . . . . . . . 24 91 4.3. ANCP Security Requirements . . . . . . . . . . . . . . . . 25 92 4.4. Protocol Design Requirements . . . . . . . . . . . . . . . 25 93 4.5. Access Node Control Adjacency Requirements . . . . . . . . 25 94 4.6. ANCP Transport Requirements . . . . . . . . . . . . . . . 26 95 4.7. Access Node Requirements . . . . . . . . . . . . . . . . . 26 96 4.7.1. General Architecture . . . . . . . . . . . . . . . . . 26 97 4.7.2. Control Channel Attributes . . . . . . . . . . . . . . 27 98 4.7.3. Capability Negotiation Failure . . . . . . . . . . . . 27 99 4.7.4. Adjacency Status Reporting . . . . . . . . . . . . . . 28 100 4.7.5. Identification . . . . . . . . . . . . . . . . . . . . 28 101 4.7.6. Multicast . . . . . . . . . . . . . . . . . . . . . . 28 102 4.7.7. Message Handling . . . . . . . . . . . . . . . . . . . 29 103 4.7.8. Parameter Control . . . . . . . . . . . . . . . . . . 29 104 4.7.9. Security . . . . . . . . . . . . . . . . . . . . . . . 29 105 4.8. Network Access Server Requirements . . . . . . . . . . . . 29 106 4.8.1. General Architecture . . . . . . . . . . . . . . . . . 29 107 4.8.2. Control Channel Attributes . . . . . . . . . . . . . . 31 108 4.8.3. Capability Negotiation Failure . . . . . . . . . . . . 31 109 4.8.4. Adjacency Status Reporting . . . . . . . . . . . . . . 32 110 4.8.5. Identification . . . . . . . . . . . . . . . . . . . . 32 111 4.8.6. Multicast . . . . . . . . . . . . . . . . . . . . . . 32 112 4.8.7. Message Handling . . . . . . . . . . . . . . . . . . . 33 113 4.8.8. Wholesale Model . . . . . . . . . . . . . . . . . . . 33 114 4.8.9. Security . . . . . . . . . . . . . . . . . . . . . . . 33 115 5. Policy Server Interaction . . . . . . . . . . . . . . . . . . 34 116 6. Management Related Requirements . . . . . . . . . . . . . . . 35 117 7. Security Considerations . . . . . . . . . . . . . . . . . . . 36 118 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 119 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 120 9.1. Normative References . . . . . . . . . . . . . . . . . . . 38 121 9.2. Informative References . . . . . . . . . . . . . . . . . . 38 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 123 Intellectual Property and Copyright Statements . . . . . . . . . . 41 125 1. Introduction 127 Digital Subscriber Line (DSL) technology is widely deployed for 128 Broadband Access for Next Generation Networks. Several documents 129 like DSL Forum TR-058 [TR-058], DSL Forum TR-059 [TR-059] and DSL 130 Forum TR-101 [TR-101] describe possible architectures for these 131 access networks. The scope of these specifications consists of the 132 delivery of voice, video and data services. The framework defined by 133 this document is targeted at DSL-based access (either by means of 134 ATM/DSL or as Ethernet/DSL). 136 Traditional architectures require Permanent Virtual Circuit(s) per 137 Subscriber. Such virtual circuit is configured on layer 2 and 138 terminated at the first layer 3 device (e.g. Broadband Remote Access 139 Server (BRAS)). Beside the data plane, the models define the 140 architectures for element, network and service management. 141 Interworking at the management plane is not always possible because 142 of the organizational boundaries between departments operating the 143 local loop, departments operating the ATM network and departments 144 operating the IP network. Besides, management networks are usually 145 not designed to transmit management data between the different 146 entities in real time. 148 When deploying value-added services across DSL access networks, 149 special attention regarding quality of service and service control is 150 required, which implies a tighter coordination between Network Nodes 151 (e.g. Access Nodes and NAS), without burdening the OSS layer with 152 unpractical expectations. 154 Therefore, there is a need for an Access Node Control Mechanism 155 between a Network Access Server (NAS) and an Access Node (e.g. a 156 Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi- 157 service reference architecture in order to perform QoS-related, 158 service-related and Subscriber-related operations. The Access Node 159 Control Mechanism will ensure that the transmission of the 160 information does not need to go through distinct element managers but 161 rather using a direct device-device communication. This allows for 162 performing access link related operations within those network 163 elements, while avoiding impact on the existing OSS systems. 165 This document provides a framework for such an Access Node Control 166 Mechanism and identifies a number of use cases for which this 167 mechanism can be justified. Next, it presents a number of 168 requirements for the Access Node Control Protocol (ANCP) and the 169 network elements that need to support it. 171 The requirements spelled out in this document are based on the work 172 that is performed by the DSL Forum ([WT-147]). 174 1.1. Requirements Notation 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in [RFC2119]. 180 1.2. Definitions 182 o Access Node (AN): Network device, usually located at a service 183 provider central office or street cabinet, that terminates Access 184 Loop connections from Subscribers. In case the Access Loop is a 185 Digital Subscriber Line (DSL), this is often referred to as a DSL 186 Access Multiplexer (DSLAM). 188 o Network Access Server (NAS): Network device which aggregates 189 multiplexed Subscriber traffic from a number of Access Nodes. The 190 NAS plays a central role in per-subscriber policy enforcement and 191 QoS. Often referred to as a Broadband Network Gateway (BNG) or 192 Broadband Remote Access Server (BRAS). A detailed definition of 193 the NAS is given in [RFC2881]. 195 o Net Data Rate: defined by ITU-T G.993.2, section 3.39, i.e. the 196 portion of the total data rate that can be used to transmit user 197 information (e.g. ATM cells or Ethernet frames). It excludes 198 overhead that pertains to the physical transmission mechanism 199 (e.g. trellis coding in case of DSL). 201 o Line Rate: the total data rate including overhead. 203 o Access Node Control Mechanism: a method for multiple network 204 scenarios with an extensible communication scheme that conveys 205 status and control information between one or more ANs and one or 206 more NASs without using intermediate element managers. 208 o Control Channel: a bidirectional IP communication interface 209 between the controller function (in the NAS) and the reporting/ 210 enforcement function (in the AN). It is assumed that this 211 interface is configured (rather than discovered) on the AN and the 212 NAS. 214 o Access Node Control Adjacency: the relationship between an Access 215 Node and a NAS for the purpose of exchanging Access Node Control 216 Protocol messages. The adjacency may either be up or down, 217 depending on the result of the Access Node Control Adjacency 218 protocol operation. 220 o Multicast Flow: multicast Any Source Multicast (ASM) group or 221 multicast Source Specific Multicast (SSM) (S,G) channel. An 222 application channel (such as a TV channel) is mapped onto a 223 Multicast Flow. 225 o Join: signaling from the user equipment that it wishes to start 226 receiving a new multicast flow. In ASM, it is referred to as a 227 "Join". In SSM [RFC4607], it is referred to as a "subscribe". In 228 IGMPv2, "joins" are indicated through an "IGMPv2 membership 229 report". In IGMPv3 [RFC3376], "join" are indicated through 230 "membership report" using different Filter-Mode-Change (ASM) and 231 Source-List-Change Records. 233 o Leave: signaling from the user equipment that it wishes to stop 234 receiving a multicast flow. With IGMPv2 this is conveyed inside 235 the "Leave Group" message while in IGMPv3, "leave" is indicated 236 through "IGMPv3 membership report" message using different Filter- 237 Mode-Change (ASM) and Source-List-Change Records. 239 2. General Architecture Aspects 241 In this section first the concept of the Access Node Control 242 Mechanism is described. Then, the reference architecture is 243 described where the Access Node Control Mechanism is introduced. 245 2.1. Concept of an Access Node Control Mechanism 247 The high-level communication framework for an Access Node Control 248 Mechanism is defined in Figure 1. The Access Node Control Mechanism 249 defines a quasi-realtime, general-purpose method for multiple network 250 scenarios with an extensible communication scheme, addressing the 251 different use cases that are described throughout this document. 253 +--------+ 254 | Policy | 255 | Server | 256 +--------+ 257 | 258 | 259 +-----+ +-----+ +--------+ +-----+ +----------+ 260 | CPE |---| HGW |---| | | | | | 261 +-----+ +-----+ | Access | +---------+ | | | Regional | 262 | Node |---| Aggreg. |---| NAS |---| Network | 263 +-----+ +-----+ | | | Node | | | | | 264 | CPE |---| HGW |---| | +---------+ | | | | 265 +-----+ +-----+ +--------+ +-----+ +----------+ 266 Information Report / Admission Request 267 --------------------------> 268 Admission Response / Control Request 269 <-------------------------- 270 Control Response 271 --------------------------> 273 Access Node Control Mechanism 274 <-------------------------> 275 PPP, DHCP, IP 276 <---------><-------------------------------------> 278 Figure 1 280 From a functional perspective, a number of functions can be 281 identified: 283 o A controller function: this function is used to receive status 284 information or admission requests from the reporting function. It 285 is also used to trigger a certain behavior in the network element 286 where the reporting and/or enforcement function resides; 288 o A reporting and/or enforcement function: the reporting function is 289 used to convey status information to the controller function that 290 requires the information for executing local functions. An 291 example of this is the transmission of an Access Loop data rate 292 from an Access Node to a Network Access Server (NAS) tasked with 293 shaping traffic to that rate. The enforcement function can be 294 contacted by the controller function to enforce a specific policy 295 or trigger a local action. An example of this is the initiation 296 of a port testing mechanism on an Access Node. Another example is 297 enforcing whether a multicast join is to be honored or denied. 299 The messages shown in Figure 1 show the conceptual message flow. The 300 actual use of these flows, and the times or frequencies when these 301 messages are generated depends on the actual use case, which are 302 described in Section 3. 304 The use cases in this document are described in an abstract way, 305 independent from any actual protocol mapping. The actual protocol 306 specification is out of scope of this document, but there are certain 307 characteristics of the protocol required such as to simplify 308 specification, implementation, debugging & troubleshooting, but also 309 to be easily extensible in order to support additional use cases. 311 2.2. Reference Architecture 313 The reference architecture used in this document can be based on ATM 314 or Ethernet access/aggregation. Specifically: 316 o In case of a legacy ATM aggregation network that is to be used for 317 the introduction of new QoS-enabled IP services, the architecture 318 builds on the reference architecture specified in DSL Forum 319 [TR-059]; 321 o In case of an Ethernet aggregation network that supports new QoS- 322 enabled IP services (including Ethernet multicast replication), 323 the architecture builds on the reference architecture specified in 324 DSL Forum [TR-101]. 326 Given the industry's move towards Ethernet as the new access and 327 aggregation technology for triple play services, the primary focus 328 throughout this document is on a TR-101 architecture. However the 329 concepts are equally applicable to an ATM architecture based on TR- 330 059. 332 2.2.1. Home Gateway 334 The Home Gateway (HGW) connects the different Customer Premises 335 Equipment (CPE) to the Access Node and the access network. In case 336 of DSL, the HGW is a DSL Network Termination (NT) that could either 337 operate as a layer 2 bridge or as a layer 3 router. In the latter 338 case, such a device is also referred to as a Routing Gateway (RG). 340 2.2.2. Access Loop 342 The Access Loop ensures physical connectivity between the HGW at the 343 customer premises, and the Access Node. In case of DSL, the Access 344 Loop physical layer could be e.g. ADSL, ADSL2+, VDSL, VDSL2 or 345 SHDSL. In order to increase bandwidth, it is also possible that 346 multiple DSL links are grouped together to form a single virtual 347 link; this process is called "DSL bonding". The protocol 348 encapsulation on the Access Loop could be based on multi-protocol 349 encapsulation over AAL5, defined in RFC2684. This covers PPP over 350 Ethernet (PPPoE, defined in RFC2516), bridged IP (IPoE) and routed IP 351 (IPoA, defined in RFC2225). Next to this, PPPoA as defined in 352 RFC2364 can be used. Future scenarios include cases where the Access 353 Loop supports direct Ethernet encapsulation (e.g. when using VDSL or 354 VDSL2). 356 2.2.3. Access Node 358 The Access Node (AN) is a network device, usually located at a 359 service provider central office or street cabinet, that terminates 360 Access Loop connections from Subscribers. In case the Access Loop is 361 a Digital Subscriber Line (DSL), this is often referred to as a DSL 362 Access Multiplexer (DSLAM). The AN may support one or more Access 363 Loop technologies and allow them to inter-work with a common 364 aggregation network technology. 366 Besides the Access Loop termination the AN can also aggregate traffic 367 from other Access Nodes using ATM or Ethernet. 369 The framework defined by this document is targeted at DSL-based 370 access (either by means of ATM/DSL or as Ethernet/DSL). The 371 framework shall be open to non-DSL technologies, like Passive Optical 372 Networks (PON) and IEEE 802.16 (WiMAX), but the details of this are 373 outside the scope of this document. 375 The reporting and/or enforcement function defined in Section 2.1 376 typically resides in an Access Node. 378 2.2.4. Access Node Uplink 380 The fundamental requirements for the Access Node uplink are to 381 provide traffic aggregation, Class of Service distinction and 382 customer separation and traceability. This can be achieved using an 383 ATM or an Ethernet based technology. 385 2.2.5. Aggregation Network 387 The aggregation network provides traffic aggregation towards the NAS. 388 The aggregation technology can be based on ATM (in case of a TR-059 389 architecture) or Ethernet (in case of a TR-101 architecture). 391 2.2.6. Network Access Server 393 The NAS is a network device which aggregates multiplexed Subscriber 394 traffic from a number of Access Nodes. The NAS plays a central role 395 in per-subscriber policy enforcement and QoS. It is often referred 396 to as a Broadband Network Gateway (BNG) or Broadband Remote Access 397 Server (BRAS). A detailed definition of the NAS is given in RFC2881. 399 The NAS interfaces to the aggregation network by means of standard 400 ATM or Ethernet interfaces, and towards the Regional Network by means 401 of transport interfaces for Ethernet frames (e.g. GigE, Ethernet 402 over SONET). The NAS functionality correpsonds to the BNG 403 functionality described in DSL Forum TR-101. In addition to this, 404 the NAS supports the Access Node Control functionality defined for 405 the respective use cases throughout this document. 407 The controller function defined in Section 2.1 typically resides in a 408 NAS. 410 2.2.7. Regional Network 412 The Regional Network connects one or more NAS and associated Access 413 Networks to Network Service Providers (NSPs) and Application Service 414 Providers (ASPs). The NSP authenticates access and provides and 415 manages the IP address to Subscribers. It is responsible for overall 416 service assurance and includes Internet Service Providers (ISPs). 417 The ASP provides application services to the application Subscriber 418 (gaming, video, content on demand, IP telephony etc.). 420 The Regional Network supports aggregation of traffic from multiple 421 Access Networks and hands off larger geographic locations to NSPs and 422 ASPs - relieving a potential requirement for them to build 423 infrastructure to attach more directly to the various Access 424 Networks. 426 2.3. Access Node Control Mechanism Transport Methods 428 The connectivity between the Access Node and the NAS may differ 429 depending on the actual layer 2 technology used (ATM or Ethernet). 430 Therefore the identification of unicast & multicast flows/channels 431 will also differ (see also Section 2.4.1). 433 In case of an ATM access/aggregation network, a typical practice is 434 to send the Access Node Control Protocol messages over a dedicated 435 Permanent Virtual Circuit (PVC) configured between the AN and the 436 NAS. These ATM PVCs would then be given a high priority so that the 437 ATM cells carrying the Access Node Control Protocol messages are not 438 lost in the event of congestion. It is discouraged to route the 439 Access Node Control Protocol messages within the VP that also carries 440 the customer connections, if that VP is configured with a best effort 441 QoS class (e.g. Unspecified Bitrate (UBR)). The PVCs of multiple 442 Access Node Control Adjacencies can be aggregated into a Virtual Path 443 (VP) that is given a high priority and runs across the aggregation 444 network. This requires the presence of a VC cross-connect in the 445 aggregation node that terminates the VP. 447 In case of an Ethernet access/aggregation network, a typical practice 448 is to send the Access Node Control Protocol messages over a dedicated 449 Ethernet Virtual LAN (VLAN) using a separate VLAN identifier (VLAN 450 ID). This can be achieved using a different VLAN ID for each Access 451 Node, or, in networks with many Access Nodes and high degree of 452 aggregation, one Customer VLAN (C-VLAN) per Access Node and one 453 Service VLAN (S-VLAN) for the Access Node Control Adjacencies of all 454 Access Nodes. The traffic should be given a high priority (e.g. by 455 using a high Class of Service (CoS) value) so that the Ethernet 456 frames carrying the Access Node Control Protocol messages are not 457 lost in the event of congestion. 459 In both cases, the Control Channel between NAS and Access Node could 460 use the same physical network- and routing resources as the 461 Subscriber traffic. This means that the connection is an inband 462 connection between the involved network elements. Therefore there is 463 no need for an additional physical interface to establish the Control 464 Channel. 466 Note that these methods for transporting Access Node Control Protocol 467 messages are typical examples; they do not rule out other methods 468 that achieve the same behavior. 470 The Access Node Control Adjacency interactions must be reliable. In 471 addition to this, some of the use cases described in Section 3 472 require the interactions to be performed in a transactional fashion, 473 i.e. using a "request/response" mechanism. In case the response is 474 negative, the state of the peer must then be rolled back to the state 475 prior to the transaction. 477 2.4. Operation and Management 479 When introducing an Access Node Control Mechanism, care is needed to 480 ensure that the existing management mechanisms remain operational as 481 before. 483 Specifically when using the Access Node Control Mechanism for 484 performing a configuration action on a network element, one gets 485 confronted with the challenge of supporting multiple managers for the 486 same network element: both the Element Manager as well as the Access 487 Node Control Mechanism may now perform configuration actions on the 488 same network element. Conflicts therefore need to be avoided. 490 Also, there is a possibility to integrate this with a Policy Server 491 (e.g. RADIUS server) that keeps track of the different Subscriber 492 related parameters. 494 2.4.1. Circuit Addressing Scheme 496 In deployments using an ATM aggregation network, the ATM PVC on an 497 Access Loop connects the Subscriber to a NAS. Based on this 498 property, the NAS typically includes a NAS-Port-Id, NAS-Port or 499 Calling-Station-Id attribute in RADIUS authentication & accounting 500 packets sent to the RADIUS server(s). Such attribute includes the 501 identification of the ATM VC for this Subscriber, which allows in 502 turn identifying the Access Loop. 504 In an Ethernet-based aggregation network, a new addressing scheme is 505 defined in TR-101. Two mechanisms can be used: 507 o A first approach is to use a one-to-one VLAN assignment model for 508 all Access Ports (e.g. a DSL port) and circuits on an Access Port 509 (e.g. an ATM PVC on an ADSL port). This enables directly deriving 510 the port and circuit identification from the VLAN tagging 511 information, i.e. S-VLAN ID or pair; 513 o A second approach is to use a many-to-one VLAN assignment model 514 and to encode the Access Port and circuit identification in the 515 "Agent Circuit ID" sub-option to be added to a DHCP or PPPoE 516 message. The details of this approach are specified in TR-101. 518 This document reuses the addressing scheme specified in TR-101. It 519 should be noted however that the use of such a scheme does not imply 520 the actual existence of a PPPoE or DHCP session, nor on the specific 521 interworking function present in the Access Node. In some cases, no 522 PPPoE or DHCP session may be present, while port and circuit 523 addressing would still be desirable. 525 3. Use Cases for Access Node Control Mechanism 527 3.1. Access Topology Discovery 529 [TR-059] and [TR-101] discuss various queuing/scheduling mechanisms 530 to avoid congestion in the access network while dealing with multiple 531 flows with distinct QoS requirements. One technique that can be used 532 on a NAS is known as "Hierarchal Scheduling" (HS). This option is 533 applicable in a single NAS scenario (in which case the NAS manages 534 all the bandwidth available on the Access Loop) or in a dual NAS 535 scenario (in which case the NAS manages some fraction of the Access 536 Loop's bandwidth). The HS must, at a minimum, support 3 levels 537 modelling the NAS port, Access Node uplink, and Access Loop sync 538 rate. The rationale for the support of HS is as follows: 540 o Provide fairness of network resources within a class. 542 o Better utilization of network resources. Drop traffic early at 543 the NAS rather than letting it traverse the aggregation network 544 just to be dropped at the Access Node. 546 o Enable more flexible Class of Service (CoS) behaviors other than 547 only strict priority. 549 o The HS system could be augmented to provide per application 550 admission control. 552 o Allow fully dynamic bandwidth partitioning between the various 553 applications (as opposed to static bandwidth partitioning). 555 o Support "per user weighted scheduling" to allow differentiated 556 SLAs (e.g. business services) within a given traffic class. 558 Such mechanisms require that the NAS gains knowledge about the 559 topology of the access network, the various links being used and 560 their respective rates. Some of the information required is somewhat 561 dynamic in nature (e.g. DSL line rate - hence also the net data 562 rate), hence cannot come from a provisioning and/or inventory 563 management OSS system. Some of the information varies less 564 frequently (e.g. capacity of a DSLAM uplink), but nevertheless needs 565 to be kept strictly in sync between the actual capacity of the uplink 566 and the image the BRAS has of it. 568 OSS systems are rarely able to enforce in a reliable and scalable 569 manner the consistency of such data, notably across organizational 570 boundaries. The Access Topology Discovery function allows the NAS to 571 perform these advanced functions without having to depend on an 572 error-prone & possibly complex integration with an OSS system. 574 Communicating Access Loop attributes is specifically important in 575 case the rate of the Access Loop changes overtime. The DSL actual 576 data rate may be different every time the DSL NT is turned on. In 577 this case, the Access Node sends an Information Report message to the 578 NAS after the DSL line has resynchronized. 580 Additionally, during the time the DSL NT is active, data rate changes 581 can occur due to environmental conditions (the DSL Access Loop can 582 get "out of sync" and can retrain to a lower value, or the DSL Access 583 Loop could use Seamless Rate Adaptation making the actual data rate 584 fluctuate while the line is active). In this case, the Access Node 585 sends an additional Information Report to the NAS each time the 586 Access Loop attributes change above a threshold value. 588 The hierarchy and the rates of the various links to enable the NAS 589 hierarchical scheduling and policing mechanisms are the following: 591 o The identification and speed (data rate) of the DSL Access Loop 592 (i.e. the net data rate) 594 o The identification and speed (data rate) of the Remote 595 Terminal(RT)/Access Node uplink (when relevant) 597 The NAS can adjust downstream shaping to current Access Loop actual 598 data rate, and more generally re-configure the appropriate nodes of 599 its hierarchical scheduler (support of advanced capabilities 600 according to TR-101). 602 This use case may actually include more information than link 603 identification and corresponding data rates. In case of DSL Access 604 Loops, the following Access Loop characteristics can be sent to the 605 NAS (cf. ITU-T Recommendation G.997.1 [G.997.1]): 607 o DSL Type (e.g. ADSL1, ADSL2, SDSL, ADSL2+, VDSL, VDSL2) 609 o Framing mode (e.g. ATM, ITU-T Packet Transfer Mode (PTM), IEEE 610 802.3 Ethernet in the First Mile (EFM)) 612 o DSL port state (e.g. synchronized/showtime, low power, no power/ 613 idle) 615 o Actual net data rate (upstream/downstream) 617 o Maximum achievable/attainable net data rate (upstream/downstream) 619 o Minimum net data rate configured for the Access Loop (upstream/ 620 downstream) 622 o Maximum net data rate configured for the Access Loop (upstream/ 623 downstream) 625 o Minimum net data rate in low power state configured for the Access 626 Loop (upstream/downstream) 628 o Maximum achievable interleaving delay (upstream/downstream) 630 o Actual interleaving delay (upstream/downstream) 632 The NAS MUST be able to receive Access Loop characteristics 633 information, and share such information with AAA/Policy Servers. 635 3.2. Access Loop Configuration 637 Access Loop rates are typically configured in a static way. If a 638 Subscriber wants to change its Access Loop rate, this requires an 639 OPEX intensive reconfiguration of the Access Port configuration via 640 the network operator, possibly implying a business-to-business 641 transaction between an Internet Service Provider (ISP) and an Access 642 Provider. 644 Using the Access Node Control Mechanism to change the Access Loop 645 rate from the NAS avoids those cross-organization business-to- 646 business interactions and allows to centralize Subscriber-related 647 service data in e.g. a Policy Server. More generally, several Access 648 Loop parameters (e.g. minimum data rate, interleaving delay) could be 649 changed by means of the Access Node Control Mechanism. 651 Triggered by the communication of the Access Loop attributes 652 described in Section 3.1, the NAS could query a Policy Server (e.g. 653 RADIUS server) to retrieve Access Loop configuration data. The best 654 way to change Access Loop parameters is by using profiles. These 655 profiles (e.g. DSL profiles for different services) are pre- 656 configured by the Element Manager managing the Access Nodes. The NAS 657 may then use the Configure Request message to send a reference to the 658 right profile to the Access Node. The NAS may also update the Access 659 Loop configuration due to a Subscriber service change (e.g. triggered 660 by the Policy Server). 662 The Access Loop Configuration mechanism may also be useful for 663 configuration of parameters that are not specific to the Access Loop 664 technology. Examples include the QoS profile to be used for an 665 Access Loop, or the per-Subscriber multicast channel entitlement 666 information, used for IPTV applications where the Access Node is 667 performing IGMP snooping or IGMP proxy function. The latter is also 668 discussed in Section 3.4. 670 It may be possible that a Subscriber wants to change its Access Loop 671 rate, and that the operator wants to enforce on the Access Node using 672 ANCP, but that the Access Node Control Adjacency is down. In such a 673 case, the NAS will not be able to request the configuration change on 674 the Access Node. The NAS should then report this failure to the OSS 675 system, which could use application specific signaling to notify the 676 Subscriber of the fact that the change could not be performed at this 677 time. 679 3.3. Remote Connectivity Test 681 Traditionally, ATM circuits are point to point connections between 682 the BRAS and the DSLAM or DSL NT. In order to test the connectivity 683 on layer 2, appropriate OAM functionality is used for operation and 684 troubleshooting. An end-to-end OAM loopback is performed between the 685 edge devices (NAS and HGW) of the broadband access network. 687 When migrating to an Ethernet-based aggregation network (as defined 688 by TR-101), end to end ATM OAM functionality is no longer applicable. 689 Ideally in an Ethernet aggregation network, end-to-end Ethernet OAM 690 as specified in IEEE 802.1ag and ITU-T Recommendation Y.1730/1731 can 691 provide Access Loop connectivity testing and fault isolation. 692 However, most HGWs do not yet support these standard Ethernet OAM 693 procedures. Also, various access technologies exist such as ATM/DSL, 694 Ethernet in the First Mile (EFM) etc. Each of these access 695 technologies have their own link-based OAM mechanisms that have been 696 or are being standardized in different standard bodies. 698 In a mixed Ethernet and ATM access network (including the local 699 loop), it is desirable to keep the same ways to test and troubleshoot 700 connectivity as those used in an ATM based architecture. To reach 701 consistency with the ATM based approach, an Access Node Control 702 Mechanism between NAS and Access Node can be used until end-to-end 703 Ethernet OAM mechanisms are more widely available. 705 Triggered by a local management interface, the NAS can use the Access 706 Node Control Mechanism to initiate an Access Loop test between Access 707 Node and HGW. In case of an ATM based Access Loop the Access Node 708 Control Mechanism can trigger the Access Node to generate ATM (F4/F5) 709 loopback cells on the Access Loop. In case of Ethernet, the Access 710 Node can perform a port synchronization and administrative test for 711 the access loop. The Access Node can send the result of the test to 712 the NAS via a Control Response message. The NAS may then send the 713 result via a local management interface. Thus, the connectivity 714 between the NAS and the HGW can be monitored by a single trigger 715 event. 717 3.4. Multicast 719 With the rise of supporting IPTV services in a resource efficient 720 way, multicast services are getting increasingly important. 722 In case of an ATM access/aggregation network, such as the reference 723 architecture specified in DSL Forum [TR-059], multicast traffic 724 replication is performed in the NAS. In this model, typically IGMP 725 is used to control the multicast replication process towards the 726 subscribers. The NAS terminates and processes IGMP signaling 727 messages sent by the subscribers; towards the Regional Network, the 728 NAS typically uses a multicast routing protocol such as PIM. The ATM 729 Access Nodes and aggregation switches don't perform IGMP processing, 730 nor do they perform multicast traffic replication. As a result, 731 network resources are wasted within the access/aggregation network. 733 To overcome this resource inefficiency, the Access Node, aggregation 734 node(s) and the NAS must all be involved in the multicast replication 735 process. This avoids that several copies of the same stream are sent 736 within the access/aggregation network. In case of an Ethernet-based 737 access/aggregation network, this may, for example, be achieved by 738 means of IGMP snooping or IGMP proxy in the Access Node and 739 aggregation node(s). 741 By introducing IGMP processing in the access/aggregation nodes, the 742 multicast replication process is now divided between the NAS, the 743 aggregation node(s) and Access Nodes. In order to ensure backward 744 compatibility with the ATM-based model, the NAS, aggregation node and 745 Access Node need to behave as a single logical device. This logical 746 device must have exactly the same functionality as the NAS in the ATM 747 access/aggregation network. The Access Node Control Mechanism can be 748 used to make sure that this logical/functional equivalence is 749 achieved by exchanging the necessary information between the Access 750 Node and the NAS. 752 The following subsections describe the different use cases related to 753 multicast. 755 3.4.1. Multicast Conditional Access 757 In a DSL Broadband access scenario Service Providers may want to 758 dynamically control, at the network level, access to some multicast 759 flows on a per user basis. This may be used in order to 760 differentiate among multiple Service Offers or to realize/reinforce 761 conditional access for sensitive content. Note that, in some 762 environments, application layer conditional access by means of 763 Digital Rights Management (DRM) may provide sufficient control, so 764 that Multicast Conditional Access may not be needed. 766 Where Multicast Conditional Access is required, it is possible, in 767 some cases, to provision the necessary conditional access information 768 into the AN so the AN can then perform the conditional access 769 decisions autonomously. For these cases, the NAS can use ANCP to 770 provision the necessary information in the AN so that the AN can 771 decide locally to honor a join or to not honor a join. This can be 772 done with the Control Request and Control Response messages. 774 Provisioning the conditional access information on the AN can be done 775 using a "White list" and/or a "Black list". A White list associated 776 with an Access Port identifies the multicast flows that are allowed 777 to be replicated to that port. A Black list associated with an 778 Access Port identifies the multicast flows that are not allowed to be 779 replicated to that port. 781 Upon receiving a join message on an Access Port, the Access Node will 782 first check if the requested multicast flow is part of a White list 783 or a Black list associated with that Access Port. If it is part of a 784 White list, the AN can autonomously start replicating multicast 785 traffic. If it is part of a Black list, the AN can autonomously 786 discard the message because the request is not authorized. 788 The White List and Black List can contain entries allowing: 790 o an exact match for a (*,G) ASM group (e.g. ); 792 o an exact match for a (S,G) SSM channel (e.g. 793 ); 795 o a mask-based range match for a (*,G) ASM group (e.g. ); 798 o a mask-based range match for a (S,G) SSM channel (e.g. ); 801 The use of a White list and Black list may be applicable, for 802 instance, to regular IPTV services (i.e. Broadcast TV) offered by an 803 Access Provider to broadband (e.g. DSL) subscribers. For this 804 application, the IPTV subscription is typically bound to a specific 805 DSL line, and the multicast flows that are part of the subscription 806 are well-known beforehand. Furthermore, changes to the conditional 807 access information are infrequent, since they are bound to the 808 subscription. Hence the Access Node can be provisioned with the 809 conditional access information related to the IPTV service. 811 In some other cases, it may be desirable to have the conditional 812 access decision being taken by the NAS or a Policy Server. This may 813 be the case when conditional access information changes frequently, 814 or when the multicast groups are not known to a client application in 815 advance. The conditional access control could be tied to a more 816 complex policy/authorization mechanism, e.g. time of day access, or 817 location based access or to invoke a remote authorisation server. 818 For these cases, the AN can use ANCP to query the NAS, that in turn 819 will respond to the AN indicating whether the join is to be honored 820 (and hence replication performed by the AN) or denied. This can be 821 done with the Admission Request and Admission Response messages. 823 Some examples of using NAS querying are the following: 825 o Roaming users: a subscriber that logs in on different wireless 826 hotspots and would like to receive multicast content he is 827 entitled to receive; 829 o A related example is that of mobility or seamless handover; in 830 both cases the burden of (re)configuring access nodes with White 831 lists or Black lists may be too high; 833 o "Over The Top Video Partnerships": Service Providers may choose to 834 partner with Internet video providers to provide video content. 835 In this case, the multicast group mappings may not be known in 836 advance, or may be reused for different content in succession. 838 Querying the NAS before performing a join on the AN may increase 839 channel join and channel change times because of the additional 840 message processing involved in the AN, the NAS and potentially the 841 Policy Server. On the other hand, pre-provisioning per subscriber 842 profiles potentially different for each subscriber may be a 843 configuration burden, may result in large delays when the NAS or AN 844 restarts, or may not be viable when conditional access changes 845 frequently or are to remain under the control of an external 846 administrative entity. 848 In order to account for these operational factors and associated 849 trade-offs, in some cases, the provisioning and querying techniques 850 can be combined. In such a model, the AN sends an Admission Request 851 message to the NAS as a trigger for a particular multicast flow. The 852 NAS would then send back an Admission Response message to the AN, 853 including conditional access information for that multicast flow, as 854 well as for a set of multicast flows sharing the same conditional 855 access rules. The AN can then autonomously honor or deny requests 856 for a given user/port for the set of Multicast flows as indicated in 857 the Admission Response message. 859 3.4.2. Multicast Admission Control 861 The successful delivery of Triple Play Broadband services is quickly 862 becoming a big capacity planning challenge for most of the Service 863 Providers nowadays. Solely increasing available bandwidth is not 864 always practical, cost-economical and/or sufficient to satisfy end 865 user experience given not only the strict requirements of unicast 866 delay sensitive applications like VoIP and Video, but also the fast 867 growth of multicast interactive applications such as 868 videoconferencing, digital TV, digital audio, online movies and 869 networked gaming. These applications are typically characterized by 870 a delay sensitive nature, an extremely loss sensitive nature and 871 intensive bandwidth requirements. They are also typically "non- 872 elastic", which means that they operate at a fixed bandwidth, that 873 cannot be dynamically adjusted to the currently available bandwidth. 875 Therefore a Connection Admission Control (CAC) mechanism covering 876 admission of multicast traffic over the DSL Broadband access is 877 required, in order to avoid oversubscribing the available bandwidth 878 and negatively impacting the end user experience. 880 Considering specifically admission control over the access line, 881 before honoring a user request to join a new multicast flow, the 882 combination of AN and NAS MUST ensure admission control is performed 883 to validate that there is enough "video" bandwidth remaining on the 884 access line to carry the new flow (in addition to all other existing 885 multicast and unicast video traffic). The solution needs to cope 886 with multiple flows per access line and needs to allow access line 887 bandwidth to be dynamically shared across multicast and unicast 888 traffic (irrespective of whether unicast CAC is performed by NAS or 889 by some off-path Policy Server). 891 Thus, supporting CAC for the access line requires some form of 892 synchronization between the entity performing multicast CAC (e.g. the 893 AN) and the entity performing unicast CAC (e.g. the NAS or a Policy 894 Server) and the entity actually enforcing the multicast replication 895 (i.e. the AN). This synchronization can be achieved in a number of 896 ways: 898 o One approach is for the AN to query the NAS so that both unicast 899 and multicast CAC for the access line are performed by the NAS. 900 In this case, the AN can use ANCP to query the NAS, that in turn 901 performs multicast CAC and responds to the AN indicating whether 902 the join is to be honored (and hence replication performed by the 903 AN) or denied. In the process, the NAS may communicate with a 904 Policy Server. Similarly to what has been discussed in the 905 Conditional Access use case, in response to a Admission Request 906 from the AN for admission control of a multicast flow, the NAS may 907 send back an Admission Response message to the AN, including 908 admission control information for that multicast flow, as well as 909 for other a set of multicast flows sharing the same admission 910 control rules. The AN can then autonomously honor or deny 911 requests for a given user/port for the set of Multicast flows as 912 indicated in the Admission Response message. The ANCP 913 requirements to support this approach (where the AN queries the 914 NAS) are specified in this document; 916 o Another approach is the reverse: it consists of the Policy Server 917 querying the AN (either directly, or indirectly via the NAS) so 918 that both unicast and multicast CAC for the access line are 919 performed by the AN. In this case, a subscriber request for a 920 unicast flow (e.g. a Video on Demand session) will trigger a 921 resource request message towards a Policy Server; the latter will 922 then query the AN, that in turn will perform unicast CAC for the 923 access line and respond, indicating whether the unicast request is 924 to be honored or denied. In case the Policy Server queries the AN 925 directly, the approach doesn't require the use of ANCP. It is 926 therefore beyond the scope of this document. 928 3.4.3. Multicast Accounting 930 It may be desirable to perform accurate per-user or per Access Loop 931 time or volume based accounting. In case the AN is performing the 932 traffic replication process, it knows when replication of a multicast 933 flow to a particular Access Port or user start and stops. Multicast 934 accounting can be addressed in two ways: 936 o The AN keeps track of when replication starts or stops, and 937 generates the time and/or volume based accounting information per 938 Access Loop and per multicast flow, before sending it to a central 939 accounting system for logging. Since the AN communicates with 940 this accounting system directly, the approach doesn't require the 941 use of ANCP. It is therefore beyond the scope of this document; 943 o The AN keeps track of when replication starts or stops, and 944 reports this information to the NAS for further processing. In 945 this case, ANCP can be used to send the information from the AN to 946 the NAS. This can be done with the Information Report message. 947 The NAS can then generate the appropriate time and/or volume 948 accounting information per Access Loop and per multicast flow, to 949 be sent to the accounting system. The ANCP requirements to 950 support this approach are specified in this document. 952 3.4.4. Multicast Termination 954 The capability to dynamically stop the replication of a multicast 955 flow can be useful in different scenarios: for example in case of 956 prepaid service, when available credit expires, the Service Provider 957 may want to be able to stop multicast replication on a specified 958 Access Port for a particular user. Another example of applicability 959 for this functionality is a scenario where a Service Provider would 960 like to show a "Content Preview": in this case a multicast content 961 will be delivered just for a fixed amount of time. 963 In both cases an external entity (for example a Policy Server or an 964 external application entity), can instruct the NAS to interrupt the 965 multicast replication of a specified multicast flow to a specified 966 Access Port or user. The NAS can then use ANCP to communicate this 967 decision to the Access Node. This can be done with the Admission 968 Response message. The approach dynamically updates the Black list 969 associated with the specified Access Port. 971 4. Requirements 973 4.1. ANCP Functional Requirements 975 o The ANCP MUST address all use cases described in this document, 976 and be general-purpose and extensible enough to foresee additional 977 use cases (including the use of other Access Nodes than a DSLAM, 978 e.g. a PON Access Node). 980 o The ANCP MUST be flexible enough to accommodate the various 981 technologies that can be used in an access network and in the 982 Access Node. 984 o The Access Node Control interactions MUST be reliable (using 985 either a reliable transport protocol (e.g. TCP) for the Access 986 Node Control Protocol messages, or by designing ANCP to be 987 reliable). 989 o The ANCP MUST support "request/response" transaction-based 990 interactions for the NAS to communicate control decisions to the 991 Access Node, or for the NAS to request information from the Access 992 Node. Transactions MUST be atomic, i.e. they are either fully 993 completed, or rolled-back to the previous state. 995 In case the NAS wants to communicate a bulk of independent control 996 decisions to the Access Node, the transaction (and notion of 997 atomicity) applies to the individual control decisions. This avoids 998 having to roll back all control decisions. Similarly, if the NAS 999 wants to request a bulk of independent information elements from the 1000 Access Node, the notion of transaction applies to the individual 1001 information elements. 1003 o The ANCP MUST allow fast-paced transactions, in order to provide 1004 real time transactions between a NAS and a fully populated Access 1005 Node. 1007 o The ANCP MUST allow fast completion of a given operation, in the 1008 order of magnitude of tens of milliseconds. 1010 o In large scale networks, Access Nodes are provisioned but not 1011 always fully populated. Therefore the ANCP MUST be scalable 1012 enough to allow a given NAS to control thousands of Access Nodes 1013 (e.g. typically 5000 to 10000). 1015 o The ANCP SHOULD minimize sources of configuration mismatch, help 1016 automation of the overall operation of the systems involved 1017 (Access Nodes and NAS) and be easy to troubleshoot. 1019 o The implementation of the ANCP in the NAS and Access Nodes MUST be 1020 manageable via an element management interface. This MUST allow 1021 to retrieve statistics and alarms (e.g. via SNMP) about the 1022 operation of the ANCP, as well as initiate OAM operations and 1023 retrieve corresponding results. 1025 o The ANCP SHOULD support a means to handle sending/receiving a 1026 large burst of messages efficiently (e.g. using "message 1027 bundling"). 1029 4.2. ANCP Multicast Requirements 1031 o The ANCP MUST support providing multicast conditional access 1032 information to Access Ports on an Access Node, using Black lists 1033 and White lists. 1035 o The ANCP MUST support binding a particular Black list and White 1036 List to a given Access Port. 1038 o The ANCP MUST allow the AN to query the NAS to request an 1039 admission decision for replicating a multicast flow to a 1040 particular Access Port. 1042 o The ANCP MUST allow the NAS to send an admission decision to the 1043 AN indicating whether or not a multicast flow may be replicated to 1044 a particular Access Port. 1046 o The ANCP MUST allow the NAS, when replying to an AN request, to 1047 OPTIONALLY convey information on multiple multicast flows sharing 1048 the same conditional access rules. This allows the AN to take 1049 autonomous decisions for these flows later on. 1051 o The ANCP MUST allow the AN to report to a NAS when replication of 1052 a multicast flow on a particular Access Port starts and stops. 1054 o The ANCP MUST allow the NAS to indicate to the AN when multicast 1055 accounting information is required for a multicast flow on a 1056 particular Access Port. 1058 o The ANCP MUST allow the NAS to revoke a decision to replicate a 1059 multicast flow to a particular Access Port, which had been 1060 conveyed earlier to an AN. 1062 o The ANCP MUST support partial updates of the White lists and Black 1063 lists. 1065 4.3. ANCP Security Requirements 1067 The ANCP MUST also support the security requirements as described in 1068 [draft-ietf-ancp-security-threats]. 1070 4.4. Protocol Design Requirements 1072 o The ANCP MUST be simple and lightweight enough to allow an 1073 implementation on Access Nodes with limited control plane 1074 resources (e.g. CPU and memory). 1076 o The ANCP SHOULD provide a "shutdown" sequence allowing to inform 1077 the peer that the system is gracefully shutting down. 1079 o The ANCP SHOULD include a "report" model for the Access Node to 1080 spontaneously communicate to the NAS changes of states. 1082 o The ANCP SHOULD support a graceful restart mechanism to enable it 1083 to be resilient to network failures between the AN and NAS. 1085 o The ANCP MUST provide a means for the AN and the NAS to perform 1086 capability negotiation and negotiate a common subset. 1088 4.5. Access Node Control Adjacency Requirements 1090 o The ANCP MUST support an adjacency protocol in order to 1091 automatically synchronize states between its peers, to agree on 1092 which version of the protocol to use, to discover the identity of 1093 its peers, and detect when they change. 1095 o The Access Node Control Adjacency MUST be designed such that loss 1096 or malfunction of the adjacency can be automatically detected by 1097 its peers. 1099 o The ANCP SHOULD include a "keep-alive" mechanism to automatically 1100 detect adjacency loss. 1102 o A loss of the Access Node Control Adjacency MUST NOT affect 1103 Subscriber connectivity, nor network element operation. 1105 o If the Access Node Control Adjacency is lost, it MUST NOT lead to 1106 undefined states on the network elements. 1108 o The ANCP MUST be able to recover from loss of the Access Node 1109 Control Adjacency (e.g. due to link or node failure) and 1110 automatically resynchronize state upon re-establishing the Access 1111 Node Control Adjacency. 1113 4.6. ANCP Transport Requirements 1115 o The Access Node Control Mechanism MUST be defined in a way that is 1116 independent of the underlying layer 2 transport technology. 1117 Specifically, the Access Node Control Mechanism MUST support 1118 transmission over an ATM as well as over an Ethernet aggregation 1119 network. 1121 o The ANCP MUST be mapped on top of the IP network layer. 1123 o If the layer 2 transport technology is based on ATM, then the 1124 encapsulation MUST be according to RFC2684 routed (IPoA). 1126 o If the layer 2 transport technology is based on Ethernet, then the 1127 encapsulation MUST be according to RFC894 (IPoE). 1129 4.7. Access Node Requirements 1131 This section lists the requirements for an AN that supports the use 1132 cases defined in this document. 1134 4.7.1. General Architecture 1136 The Access Node Control Mechanism is defined by a dedicated relation 1137 between the Access Node (AN) and the NAS. If one service provider 1138 has multiple physical NAS devices which represent one logical device 1139 (single edge architecture), then one AN can be connected to more than 1140 one NAS. Therefore the physical AN needs to be split in virtual ANs 1141 each having its own Access Node Control reporting and/or enforcement 1142 function. 1144 o An Access Node as physical device can be split in logical 1145 partitions. Each partition may have its independent NAS. 1146 Therefore the Access Node must support at least 2 partitions. The 1147 Access Node should support 8 partitions. 1149 o One partition is grouped of several Access Ports. Each Access 1150 Port on an Access Node must be assigned uniquely to one partition. 1152 It is assumed that all circuits (i.e. ATM PVCs or Ethernet VLANs) on 1153 top of the same physical Access Port are associated with the same 1154 partition. In other words, partitioning is performed at the level of 1155 the physical Access Port only. 1157 o Each AN partition must have a separate Access Node Control 1158 Adjacency to a NAS and should be able to enforce access control on 1159 the controllers to only designated partitions being bound to one 1160 controller. 1162 o The Access Node should be able to establish and maintain ANCP 1163 Adjacencies to redundant controllers. 1165 4.7.2. Control Channel Attributes 1167 The Control Channel is a bidirectional IP communication interface 1168 between the controller function (in the NAS) and the reporting/ 1169 enforcement function (in the AN). It is assumed that this interface 1170 is configured (rather than discovered) on the AN and the NAS. 1172 Depending on the network topology, the Access Node can be located in 1173 a street cabinet or in a central office. If an Access Node in a 1174 street cabinet is connected to a NAS, all user traffic and Access 1175 Node Control data can use the same physical link. 1177 o The Control Channel SHOULD use the same facilities as the ones 1178 used for the data traffic. 1180 o The Control Channel MUST be terminated at the Access Node. 1182 o For security purposes, the Access Node Control Protocol messages 1183 sent over the channel MUST NOT be sent towards the customer 1184 premises. 1186 o The Access Node must not support the capability to configure 1187 sending Access Node Control Protocol messages towards the customer 1188 premises. 1190 o The Access Node should process control transactions in a timely 1191 fashion. 1193 o The Access Node should mark Access Node Control Protocol messages 1194 with a high priority (e.g. VBR-rt for ATM cells, p-bit 6 or 7 for 1195 Ethernet packets) in order for the packets not to be dropped in 1196 case of congestion. 1198 o If ATM interfaces are used, VPI as well as VCI value must be 1199 configurable in the full range. 1201 o If Ethernet interfaces are used, C-Tag as well as S-Tag must be 1202 configurable in the full range. 1204 4.7.3. Capability Negotiation Failure 1206 o In case the Access Node and NAS cannot agree on a common set of 1207 capabilities, as part of the ANCP capability negotiation 1208 procedure, the Access Node must report this to network management. 1210 4.7.4. Adjacency Status Reporting 1212 o The Access Node should support generating an alarm to a management 1213 station upon loss or malfunctioning of the Access Node Control 1214 Adjacency with the NAS. 1216 4.7.5. Identification 1218 o To identify the Access Node and Access Port within a control 1219 domain a unique identifier is required. This identifier must be 1220 in line with the addressing scheme principles specified in section 1221 3.9.3 of TR-101. 1223 o To allow for correlation in the NAS, the AN must use the same 1224 Access Circuit Identifier (ACI) format for identifying the AN and 1225 Access Port in Access Node Control Protocol messages, PPPoE and 1226 DHCP messages. 1228 4.7.6. Multicast 1230 o The AN must deny any join to a multicast flow matching the Black 1231 List for the relevant Access Port. 1233 o The AN must accept any join to a multicast flow matching the White 1234 List for the relevant Access Port. 1236 o When a multicast flow matches both in the Black List and the White 1237 List, the AN must use the most specific match. 1239 o Upon receiving a join to a multicast flow which does not match any 1240 entry in the Black List nor in the White List for a specific 1241 Access Port, the AN must support using ANCP to query the NAS to 1242 recieve a response indicating whether that join is to be honored 1243 or denied. 1245 o Upon querying the NAS, the AN should support receiving ANCP 1246 messages from the NAS containing conditional access information of 1247 multiple multicast flows. This allows the AN to take autonomous 1248 decisions for these flows lateron. 1250 o The AN must support using ANCP to send information to the NAS 1251 about when replication starts/stops for the port/multicast flow. 1253 o Upon receiving an Admission Response from the NAS with a 1254 revocation of a previous admission decision, the AN must stop 1255 replication of the corresponding multicast flow to the 1256 corresponding Access Port. 1258 4.7.7. Message Handling 1260 o The Access Node should dampen notifications related to line 1261 attributes or line state. 1263 4.7.8. Parameter Control 1265 Naturally the Access Node Control Mechanism is not designed to 1266 replace an Element Manager managing the Access Node. There are 1267 parameters in the Access Node, such as the DSL noise margin and DSL 1268 Power Spectral Densities (PSD), which are not allowed to be changed 1269 via ANCP or any other control session, but only via the Element 1270 Manager. This has to be ensured and protected by the Access Node. 1272 When using ANCP for Access Loop Configuration, the EMS needs to 1273 configure on the Access Node which parameters may or may not be 1274 modified using the Access Node Control Mechanism. Furthermore, for 1275 those parameters that may be modified using ANCP, the EMS needs to 1276 specify the default values to be used when an Access Node comes up 1277 after recovery. 1279 o When Access Loop Configuration via ANCP is required, the EMS must 1280 configure on the Access Node which parameter set(s) may be 1281 changed/controlled using ANCP. 1283 o Upon receiving an Access Node Control Request message, the Access 1284 Node must not apply changes to the parameter set(s) that have not 1285 been enabled by the EMS. 1287 4.7.9. Security 1289 The ANCP related security threats that could be encountered on the 1290 Access Node are described in [draft-ietf-ancp-security-threats]. 1291 This document develops a threat model for ANCP security, aiming to 1292 decide which security functions are required at the ANCP level. 1293 Additional information is presented in Section 7. 1295 4.8. Network Access Server Requirements 1297 This section lists the requirements for a NAS that supports the use 1298 cases defined in this document. 1300 4.8.1. General Architecture 1302 o The NAS must only communicate to authorized Access Node Control 1303 peers. 1305 o The NAS must support the capability to simultaneously run ANCP 1306 with multiple ANs in a network. 1308 o The NAS must be able to establish an Access Node Control Adjacency 1309 to a particular partition on an AN and control the access loops 1310 belonging to such a partition. 1312 o The NAS must support learning of access loop attributes (e.g. net 1313 data rate), from its peer Access Node partitions via the Access 1314 Node Control Mechanism. 1316 o The NAS must support shaping traffic directed towards a particular 1317 access loop to not exceed the net data rate learnt from the AN via 1318 the Access Node Control Mechanism. 1320 o The NAS should support a reduction or disabling of such shaping 1321 limit, derived from Policy/Radius per-subscriber authorization 1322 data. 1324 o The NAS must support reporting of access loop attributes learned 1325 via the Access Node Control Mechanism to a Radius server using 1326 RADIUS VSAs. 1328 o The NAS must correlate Access Node Control information with the 1329 RADIUS authorization process and related subscriber data. 1331 o The NAS should support shaping traffic directed towards a 1332 particular access loop to include layer-1 and layer-2 1333 encapsulation overhead information received for a specific access 1334 loop from the AN via the Access Node Control Mechanism. 1336 o The NAS should support dynamically configuring and re-configuring 1337 discrete service parameters for access loops that are controlled 1338 by the NAS. The configurable service parameters for access loops 1339 could be driven by local configuration on the NAS or by a Policy 1340 Server. 1342 o The NAS should support triggering an AN via the Access Node 1343 Control Mechanism to execute local OAM procedures on an access 1344 loop that is controlled by the NAS. If the NAS supports this 1345 capability, then the following applies: 1347 * The NAS must identify the access loop on which OAM procedures 1348 need to be executed by specifying an Access Circuit Identifier 1349 (ACI) in the request message to the AN; 1351 * The NAS should support processing and reporting of the remote 1352 OAM results learned via the Access Node Control Mechanism. 1354 * As part of the parameters conveyed within the OAM message to 1355 the AN, the NAS should send the list of test parameters 1356 pertinent to the OAM procedure. The AN will then execute the 1357 OAM procedure on the specified access loop according to the 1358 specified parameters. In case no test parameters are conveyed, 1359 the AN and NAS must use default and/or appropriately computed 1360 values. 1362 * After issuing an OAM request, the NAS will consider the request 1363 to have failed if no response is received after a certain 1364 period of time. The timeout value should be either the one 1365 sent within the OAM message to the AN, or the computed timeout 1366 value when no parameter was sent. 1368 The exact set of test parameters mentioned above depends on the 1369 particular OAM procedure executed on the access loop. An example 1370 of a set of test parameters is the number of loopbacks to be 1371 performed on the access loop and the timeout value for the overall 1372 test. In this case, and assuming an ATM based access loop, the 1373 default value for the timeout parameter would be equal to the 1374 number of F5 loopbacks to be performed, multiplied by the F5 1375 loopback timeout (i.e. 5 seconds per the ITU-T I.610 standard). 1377 o The NAS must treat PPP or DHCP session state independently from 1378 any Access Node Control Adjacency state. The NAS must not bring 1379 down the PPP or DHCP sessions just because the Access Node Control 1380 Adjacency goes down. 1382 o The NAS should internally treat Access Node Control traffic in a 1383 timely and scalable fashion. 1385 o The NAS should support protection of Access Node Control 1386 communication to an Access Node in case of line card failure. 1388 4.8.2. Control Channel Attributes 1390 o The NAS must mark Access Node Control Protocol messages as high 1391 priority (e.g. appropriately set DSCP, Ethernet priority bits or 1392 ATM CLP bit) such that the aggregation network between the NAS and 1393 the AN can prioritize the Access Node Control Protocol messages 1394 over user traffic in case of congestion. 1396 4.8.3. Capability Negotiation Failure 1398 o In case the NAS and Access Node cannot agree on a common set of 1399 capabilities, as part of the ANCP capability negotiation 1400 procedure, the NAS must report this to network management. 1402 o The NAS must only commence Access Node Control information 1403 exchange and state synchronization with the AN when there is a 1404 non-empty common set of capabilities with that AN. 1406 4.8.4. Adjacency Status Reporting 1408 o The NAS must support generating an alarm to a management station 1409 upon loss or malfunctioning of the Access Node Control Adjacency 1410 with the Access Node. 1412 4.8.5. Identification 1414 o The NAS must support correlating Access Node Control Protocol 1415 messages pertaining to a given access loop with subscriber 1416 session(s) over that access loop. This correlation must be 1417 achieved by either: 1419 * Matching an Access Circuit Identifier (ACI) inserted by the AN 1420 in Access Node Control Protocol messages with corresponding ACI 1421 value received in subscriber signaling (e.g. PPPoE and DHCP) 1422 messages as inserted by the AN. The format of ACI is defined 1423 in [TR-101]; 1425 * Matching an ACI inserted by the AN in Access Node Control 1426 Protocol messages with an ACI value locally configured for a 1427 static subscriber on the NAS. 1429 4.8.6. Multicast 1431 o The NAS must support using ANCP to configure multicast conditional 1432 access information to Access Ports on an Access Node, using Black 1433 Lists and White Lists. 1435 o The NAS must support using ANCP to configure the Access Node with 1436 the "maximum number of multicast streams" allowed to be received 1437 concurrently per Access Port. 1439 o Upon receiving a query from the AN for a request to replicate a 1440 multicast flow to a particular Access Port, the NAS must support 1441 using ANCP to reply to the AN indicating whether the request is to 1442 be honored or denied. 1444 o Upon receiving a query from the AN for a request to replicate a 1445 multicast flow to a particular Access Port, the NAS should support 1446 sending an Admission Response message containing conditional 1447 access information of multiple multicast flows. This allows the 1448 AN to take autonomous decisions for these flows lateron. 1450 o The NAS must support using ANCP to indicate to the AN whether or 1451 not multicast accounting information is required for a multicast 1452 flow on a particular Access Port. 1454 o The NAS must support using ANCP to receive information about when 1455 replication starts/stops for a multicast flow on a particular 1456 Access Port. 1458 o When Multicast replication occurs on the AN, the NAS must support 1459 using ANCP to revoke the authorization to replicate a multicast 1460 flow to a particular Access Port. 1462 4.8.7. Message Handling 1464 o The NAS should protect its resources from misbehaved Access Node 1465 Control peers by providing a mechanism to dampen information 1466 related to an Access Node partition. 1468 4.8.8. Wholesale Model 1470 o In case of wholesale access, the network provider's NAS should 1471 support reporting of access loop attributes learned from AN via 1472 the Access Node Control Mechanism (or values derived from such 1473 attributes), to a retail provider's network gateway owning the 1474 corresponding subscriber(s). 1476 o In case of L2TP wholesale, the NAS must support a proxy 1477 architecture that gives different providers conditional access to 1478 dedicated Access Node Control resources on an Access Node. 1480 o The NAS when acting as a LAC must communicate generic access line 1481 related information to the LNS in a timely fashion. 1483 o The NAS when acting as a LAC may asynchronously notify the LNS of 1484 updates to generic access line related information. 1486 4.8.9. Security 1488 The ANCP related security threats that could be encountered on the 1489 NAS are described in [draft-ietf-ancp-security-threats]. This 1490 document develops a threat model for ANCP security, aiming to decide 1491 which security functions are required at the ANCP level. Additional 1492 information is presented in Section 7. 1494 5. Policy Server Interaction 1496 This document does not consider the specific details of the 1497 communication with a Policy Server (e.g. using RADIUS). 1499 6. Management Related Requirements 1501 o It must be possible to configure the following parameters on the 1502 Access Node and the NAS: 1504 * Parameters related to the Control Channel transport method: 1505 these include the VPI/VCI and transport characteristics (e.g. 1506 VBR-rt or CBR) for ATM networks or the C-VLAN ID and S-VLAN ID 1507 and p-bit marking for Ethernet networks; 1509 * Parameters related to the Control Channel itself: these include 1510 the IP address of the IP interface on the Access Node and the 1511 NAS 1513 o When the operational status of the Control Channel is changed 1514 (up>down, down>up) a linkdown/linkup trap should be sent towards 1515 the EMS. This requirement applies to both the AN and the NAS. 1517 o The Access Node must provide the possibility using SNMP to 1518 associate individual DSL lines with specific Access Node Control 1519 Adjacencies. 1521 o The Access Node must notify the EMS of configuration changes made 1522 by the NAS on the AN using ANCP, in a timely manner. 1524 o The Access Node must provide a mechanism that allows the 1525 concurrent access on the same resource from several managers (EMS 1526 via SNMP, NAS via ANCP). Only one manager may perform a change at 1527 a certain time. 1529 o The ANCP may provide a notification mechanism to inform the NAS 1530 about configuration changes done by an EMS, in a timely manner. 1531 This applies only to changes of parameters which are part of the 1532 Use Case Access Loop Configuration. 1534 7. Security Considerations 1536 [draft-ietf-ancp-security-threats] lists the ANCP related security 1537 threats that could be encountered on the Access Node and the NAS. It 1538 develops a threat model for ANCP security, aiming to decide which 1539 security functions are required at the ANCP level. 1541 With Multicast handling as described in this document, ANCP protocol 1542 activity between the AN and the NAS is triggered by join/leave 1543 requests coming from the end-user equipment. This could potentially 1544 be used for denial of service attack against the AN and/or the NAS. 1546 This is not a new class of risk over already possible IGMP messages 1547 sent from subscribers to the NAS when the AN uses no IGMP snooping, 1548 and thus is transparent as long as processing of ANCP messages on the 1549 NAS/AN is comparable efficient and protected against congestion. 1551 To mitigate this risk, the AN MAY implement control plane protection 1552 mechanisms such as limiting the number of multicast flows a given 1553 user can simultaneously join, or limiting the maximum rate of join/ 1554 leave from a given user. 1556 We also observe that an operator can easily deploy some protection 1557 against attacks using invalid multicast flows by taking advantage of 1558 the mask-based match in the Black List. This way, joins for invalid 1559 multicast flows can be denied at the AN level without any ANCP 1560 protocol interactions and without NAS involvement. 1562 8. Acknowledgements 1564 The authors would like to thank everyone that has provided comments 1565 or input to this document. In particular, the authors acknowledge 1566 the work done by the contributors to the DSL Forum related 1567 activities: Jerome Moisand, Wojciech Dec, Peter Arberg and Ole 1568 Helleberg Andersen. The authors also acknowledge the inputs provided 1569 by Roberta Maglione, Angelo Garofalo, Francois Le Faucheur and 1570 Toerless Eckert regarding multicast. Finally, the authors thank 1571 Bharat Joshi, Stefaan De Cnodder, Kirubaharan Dorairaj and Markus 1572 Freudenberger for providing comments. 1574 9. References 1576 9.1. Normative References 1578 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1579 Requirement Levels", RFC 2119, March 1997. 1581 [RFC2881] Mitton, D. and M. Beadles, "Network Access Server 1582 Requirements Next Generation (NASREQNG) NAS Model", 1583 RFC 2881, Jul 2000. 1585 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1586 Thyagarajan, "Internet Group Management Protocol, Version 1587 3", RFC 3376, October 2002. 1589 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1590 IP", RFC 4607, August 2006. 1592 9.2. Informative References 1594 [G.997.1] ITU-T, "Physical layer management for digital subscriber 1595 line (DSL) transceivers", ITU-T Rec. G.997.1, Sep 2005. 1597 [TR-058] Elias, M. and S. Ooghe, "Multi-Service Architecture & 1598 Framework Requirements", DSL Forum TR-058, September 2003. 1600 [TR-059] Anschutz, T., "DSL Evolution - Architecture Requirements 1601 for the Support of QoS-Enabled IP Services", DSL Forum TR- 1602 059, September 2003. 1604 [TR-101] Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSL 1605 Aggregation", DSL Forum TR-101, May 2006. 1607 [WT-147] Voigt, N., Ooghe, S., and M. Platnic, "Layer 2 Control 1608 Mechanism For Broadband Multi-Service Architectures", DSL 1609 Forum WT-147, June 2007. 1611 [draft-ietf-ancp-security-threats] 1612 Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security 1613 Threats and Security Requirements for the Access Node 1614 Control Protocol (ANCP)", 1615 IETF draft-ietf-ancp-security-threats-01.txt, Dec 2006. 1617 Authors' Addresses 1619 Sven Ooghe 1620 Alcatel-Lucent 1621 Copernicuslaan 50 1622 B-2018 Antwerpen 1623 Belgium 1625 Phone: +32 3 240 42 26 1626 Email: sven.ooghe@alcatel-lucent.be 1628 Norbert Voigt 1629 Nokia Siemens Networks 1630 Siemensallee 1 1631 17489 Greifswald 1632 Germany 1634 Phone: +49 3834 555 771 1635 Email: norbert.voigt@nsn.com 1637 Michel Platnic 1638 ECI Telecom 1639 30 Hasivim Street 1640 49517 Petakh Tikva 1641 Israel 1643 Phone: + 972 3 926 85 35 1644 Email: michel.platnic@ecitele.com 1646 Thomas Haag 1647 T-Systems 1648 Deutsche Telekom Allee 7 1649 64295 Darmstadt 1650 Germany 1652 Phone: +49 6151 937 5347 1653 Email: thomas.haag@t-systems.com 1654 Sanjay Wadhwa 1655 Juniper Networks 1656 10 Technology Park Drive 1657 Westford, MA 01886 1658 US 1660 Phone: 1661 Email: swadhwa@juniper.net 1663 Full Copyright Statement 1665 Copyright (C) The IETF Trust (2007). 1667 This document is subject to the rights, licenses and restrictions 1668 contained in BCP 78, and except as set forth therein, the authors 1669 retain all their rights. 1671 This document and the information contained herein are provided on an 1672 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1673 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1674 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1675 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1676 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1677 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1679 Intellectual Property 1681 The IETF takes no position regarding the validity or scope of any 1682 Intellectual Property Rights or other rights that might be claimed to 1683 pertain to the implementation or use of the technology described in 1684 this document or the extent to which any license under such rights 1685 might or might not be available; nor does it represent that it has 1686 made any independent effort to identify any such rights. Information 1687 on the procedures with respect to rights in RFC documents can be 1688 found in BCP 78 and BCP 79. 1690 Copies of IPR disclosures made to the IETF Secretariat and any 1691 assurances of licenses to be made available, or the result of an 1692 attempt made to obtain a general license or permission for the use of 1693 such proprietary rights by implementers or users of this 1694 specification can be obtained from the IETF on-line IPR repository at 1695 http://www.ietf.org/ipr. 1697 The IETF invites any interested party to bring to its attention any 1698 copyrights, patents or patent applications, or other proprietary 1699 rights that may cover technology that may be required to implement 1700 this standard. Please address the information to the IETF at 1701 ietf-ipr@ietf.org. 1703 Acknowledgment 1705 Funding for the RFC Editor function is provided by the IETF 1706 Administrative Support Activity (IASA).