idnits 2.17.1 draft-ietf-ancp-framework-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 7, 2010) is 5190 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Ooghe 3 Internet-Draft Alcatel-Lucent 4 Intended status: Informational N. Voigt 5 Expires: August 11, 2010 Nokia Siemens Networks 6 M. Platnic 7 ECI Telecom 8 T. Haag 9 Deutsche Telekom 10 S. Wadhwa 11 Juniper Networks 12 February 7, 2010 14 Framework and Requirements for an Access Node Control Mechanism in 15 Broadband Multi-Service Networks 16 draft-ietf-ancp-framework-13.txt 18 Abstract 20 The purpose of this document is to define a framework for an Access 21 Node Control Mechanism between a Network Access Server (NAS) and an 22 Access Node (e.g. a Digital Subscriber Line Access Multiplexer 23 (DSLAM)) in a multi-service reference architecture in order to 24 perform QoS-related, service-related and Subscriber-related 25 operations. The Access Node Control Mechanism will ensure that the 26 transmission of the information does not need to go through distinct 27 element managers but rather using a direct device-device 28 communication. This allows for performing access link related 29 operations within those network elements, while avoiding impact on 30 the existing Operational Support Systems (OSSes). 32 This document first identifies a number of use cases for which the 33 Access Node Control Mechanism may be appropriate. It then presents 34 the requirements for the Access Node Control Protocol (ANCP) that 35 must be taken into account during protocol design. Finally, it 36 describes requirements for the network elements that need to support 37 ANCP and the described use cases. These requirements should be seen 38 as guidelines rather than as absolute requirements. RFC 2119 39 therefore does not apply to the nodal requirements. 41 Status of this Memo 43 This Internet-Draft is submitted to IETF in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF), its areas, and its working groups. Note that 48 other groups may also distribute working documents as Internet- 49 Drafts. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 The list of current Internet-Drafts can be accessed at 57 http://www.ietf.org/ietf/1id-abstracts.txt. 59 The list of Internet-Draft Shadow Directories can be accessed at 60 http://www.ietf.org/shadow.html. 62 This Internet-Draft will expire on August 11, 2010. 64 Copyright Notice 66 Copyright (c) 2010 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (http://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with respect 74 to this document. Code Components extracted from this document must 75 include Simplified BSD License text as described in Section 4.e of 76 the Trust Legal Provisions and are provided without warranty as 77 described in the BSD License. 79 This document may contain material from IETF Documents or IETF 80 Contributions published or made publicly available before November 81 10, 2008. The person(s) controlling the copyright in some of this 82 material may not have granted the IETF Trust the right to allow 83 modifications of such material outside the IETF Standards Process. 84 Without obtaining an adequate license from the person(s) controlling 85 the copyright in such materials, this document may not be modified 86 outside the IETF Standards Process, and derivative works of it may 87 not be created outside the IETF Standards Process, except to format 88 it for publication as an RFC or to translate it into languages other 89 than English. 91 Table of Contents 93 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 94 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 6 95 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 96 2. General Architecture Aspects . . . . . . . . . . . . . . . . . 8 97 2.1. Concept of an Access Node Control Mechanism . . . . . . . 8 98 2.2. Reference Architecture . . . . . . . . . . . . . . . . . . 9 99 2.2.1. Home Gateway . . . . . . . . . . . . . . . . . . . . . 10 100 2.2.2. Access Loop . . . . . . . . . . . . . . . . . . . . . 10 101 2.2.3. Access Node . . . . . . . . . . . . . . . . . . . . . 10 102 2.2.4. Access Node Uplink . . . . . . . . . . . . . . . . . . 11 103 2.2.5. Aggregation Network . . . . . . . . . . . . . . . . . 11 104 2.2.6. Network Access Server . . . . . . . . . . . . . . . . 11 105 2.2.7. Regional Network . . . . . . . . . . . . . . . . . . . 11 106 2.3. Prioritizing Access Node Control traffic . . . . . . . . . 11 107 2.4. Interaction with Management Systems . . . . . . . . . . . 13 108 2.5. Circuit Addressing Scheme . . . . . . . . . . . . . . . . 13 109 3. Use Cases for Access Node Control Mechanism . . . . . . . . . 15 110 3.1. Access Topology Discovery . . . . . . . . . . . . . . . . 15 111 3.2. Access Loop Configuration . . . . . . . . . . . . . . . . 17 112 3.3. Remote Connectivity Test . . . . . . . . . . . . . . . . . 18 113 3.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 19 114 3.4.1. Multicast Conditional Access . . . . . . . . . . . . . 20 115 3.4.2. Multicast Admission Control . . . . . . . . . . . . . 23 116 3.4.3. Multicast Accounting and Reporting . . . . . . . . . . 27 117 3.4.4. Spontaneous Admission Response . . . . . . . . . . . . 29 118 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 30 119 4.1. ANCP Functional Requirements . . . . . . . . . . . . . . . 30 120 4.2. ANCP Multicast Requirements . . . . . . . . . . . . . . . 31 121 4.3. Protocol Design Requirements . . . . . . . . . . . . . . . 32 122 4.4. Access Node Control Adjacency Requirements . . . . . . . . 33 123 4.5. ANCP Transport Requirements . . . . . . . . . . . . . . . 33 124 4.6. Access Node Requirements . . . . . . . . . . . . . . . . . 34 125 4.6.1. General Architecture . . . . . . . . . . . . . . . . . 34 126 4.6.2. Control Channel Attributes . . . . . . . . . . . . . . 34 127 4.6.3. Capability Negotiation Failure . . . . . . . . . . . . 35 128 4.6.4. Adjacency Status Reporting . . . . . . . . . . . . . . 35 129 4.6.5. Identification . . . . . . . . . . . . . . . . . . . . 35 130 4.6.6. Multicast . . . . . . . . . . . . . . . . . . . . . . 36 131 4.6.7. Message Handling . . . . . . . . . . . . . . . . . . . 38 132 4.6.8. Parameter Control . . . . . . . . . . . . . . . . . . 38 133 4.7. Network Access Server Requirements . . . . . . . . . . . . 39 134 4.7.1. General Architecture . . . . . . . . . . . . . . . . . 39 135 4.7.2. Control Channel Attributes . . . . . . . . . . . . . . 41 136 4.7.3. Capability Negotiation Failure . . . . . . . . . . . . 41 137 4.7.4. Adjacency Status Reporting . . . . . . . . . . . . . . 41 138 4.7.5. Identification . . . . . . . . . . . . . . . . . . . . 42 139 4.7.6. Multicast . . . . . . . . . . . . . . . . . . . . . . 42 140 4.7.7. Message Handling . . . . . . . . . . . . . . . . . . . 44 141 4.7.8. Wholesale Model . . . . . . . . . . . . . . . . . . . 44 142 5. Management Related Requirements . . . . . . . . . . . . . . . 46 143 6. Security Considerations . . . . . . . . . . . . . . . . . . . 47 144 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 145 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 49 146 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 147 9.1. Normative References . . . . . . . . . . . . . . . . . . . 50 148 9.2. Informative References . . . . . . . . . . . . . . . . . . 50 149 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 151 1. Introduction 153 Digital Subscriber Line (DSL) technology is widely deployed for 154 Broadband Access for Next Generation Networks. Several documents 155 like Broadband Forum TR-058 [TR-058], Broadband Forum TR-059 [TR-059] 156 and Broadband Forum TR-101 [TR-101] describe possible architectures 157 for these access networks. The scope of these specifications 158 consists of the delivery of voice, video and data services. The 159 framework defined by this document is targeted at DSL-based access 160 (either by means of ATM/DSL or as Ethernet/DSL). The framework shall 161 be open to other access technologies, such as Passive Optical 162 Networks using DSL technology at the Optical Network Unit (ONU), or 163 wireless technologies like IEEE 802.16. Several Use Cases such as 164 Access Topology Discovery, Remote Connectivity Test and Multicast may 165 be applied to these access technologies, but the details of this are 166 outside the scope of this document. 168 Traditional architectures require Permanent Virtual Circuit(s) per 169 Subscriber. Such virtual circuit is configured on layer 2 and 170 terminated at the first layer 3 device (e.g. Broadband Remote Access 171 Server (BRAS)). Beside the data plane, the models define the 172 architectures for element, network and service management. 173 Interworking at the management plane is not always possible because 174 of the organizational boundaries between departments operating the 175 local loop, departments operating the ATM network and departments 176 operating the IP network. Besides, management networks are usually 177 not designed to transmit management data between the different 178 entities in real time. 180 When deploying value-added services across DSL access networks, 181 special attention regarding quality of service and service control is 182 required, which implies a tighter coordination between Network Nodes 183 (e.g. Access Nodes and Network Access Server (NAS)), without 184 burdening the Operational Support System (OSS) with unpractical 185 expectations. 187 Therefore, there is a need for an Access Node Control Mechanism 188 between a NAS and an Access Node (e.g. a Digital Subscriber Line 189 Access Multiplexer (DSLAM)) in a multi-service reference architecture 190 in order to perform QoS-related, service-related and Subscriber- 191 related operations. The Access Node Control Mechanism will ensure 192 that the transmission of the information does not need to go through 193 distinct element managers but rather using a direct device-device 194 communication. This allows for performing access link related 195 operations within those network elements, while avoiding impact on 196 the existing OSS systems. 198 This document provides a framework for such an Access Node Control 199 Mechanism and identifies a number of use cases for which this 200 mechanism can be justified. Next, it presents a number of 201 requirements for the Access Node Control Protocol (ANCP) and the 202 network elements that need to support it. 204 The requirements spelled out in this document are based on the work 205 that is performed by the Broadband Forum ([TR-147]). 207 1.1. Requirements Notation 209 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 210 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 211 document are to be interpreted as described in [RFC2119]. 213 1.2. Definitions 215 o Access Node (AN): Network device, usually located at a service 216 provider central office or street cabinet, that terminates Access 217 Loop connections from Subscribers. In case the Access Loop is a 218 Digital Subscriber Line (DSL), this is often referred to as a DSL 219 Access Multiplexer (DSLAM). 221 o Network Access Server (NAS): Network device which aggregates 222 multiplexed Subscriber traffic from a number of Access Nodes. The 223 NAS plays a central role in per-subscriber policy enforcement and 224 QoS. Often referred to as a Broadband Network Gateway (BNG) or 225 Broadband Remote Access Server (BRAS). A detailed definition of 226 the NAS is given in [RFC2881]. 228 o "Net Data Rate": defined by ITU-T G.993.2 [G.993.2], section 3.39, 229 i.e. the portion of the total data rate that can be used to 230 transmit user information (e.g. ATM cells or Ethernet frames). 231 It excludes overhead that pertains to the physical transmission 232 mechanism (e.g. trellis coding in case of DSL). It includes 233 TPS-TC (Transport Protocol Specific - Transmission Convergence) 234 encapsulation; this is zero for ATM encapsulation, and non-zero 235 for 64/65 encapsulation. 237 o "Line Rate": defined by ITU-T G.993.2. It contains the complete 238 overhead including Reed-Solomon and Trellis coding. 240 o Access Node Control Mechanism: a method for multiple network 241 scenarios with an extensible communication scheme that conveys 242 status and control information between one or more ANs and one or 243 more NASs without using intermediate element managers. 245 o Control Channel: a bidirectional IP communication interface 246 between the controller function (in the NAS) and the reporting/ 247 enforcement function (in the AN). It is assumed that this 248 interface is configured (rather than discovered) on the AN and the 249 NAS. 251 o Access Node Control Adjacency: the relationship between an Access 252 Node and a NAS for the purpose of exchanging Access Node Control 253 Protocol messages. The adjacency may either be up or down, 254 depending on the result of the Access Node Control Adjacency 255 protocol operation. 257 o Multicast Flow: designates datagrams sent to a group from a set of 258 sources for which multicast reception is desired. A distinction 259 can be made between Any Source Multicast (ASM) and Source Specific 260 Multicast (SSM). 262 o Join: signaling from the user equipment that it wishes to start 263 receiving a new multicast flow. In ASM, it is referred to as a 264 "Join". In SSM [RFC4607], it is referred to as a "subscribe". In 265 IGMPv2, "joins" are indicated through an "IGMPv2 membership 266 report". In IGMPv3 [RFC3376], "join" are indicated through 267 "membership report" using different Filter-Mode-Change (ASM) and 268 Source-List-Change Records. 270 o Leave: signaling from the user equipment that it wishes to stop 271 receiving a multicast flow. With IGMPv2 this is conveyed inside 272 the "Leave Group" message while in IGMPv3, "leave" is indicated 273 through "IGMPv3 membership report" message using different Filter- 274 Mode-Change (ASM) and Source-List-Change Records. 276 2. General Architecture Aspects 278 This section introduces the basic concept of the Access Node Control 279 Mechanism and describes the reference architecture where it is being 280 applied. Based on the reference architecture, the section then 281 describes how Access Node Control messages are to be prioritized over 282 other data traffic, and the interaction between ANCP and the network 283 management system. Finally, the addressing schemes are described 284 that allow identifying an Access Port in Access Node Control 285 messages. 287 2.1. Concept of an Access Node Control Mechanism 289 The high-level communication framework for an Access Node Control 290 Mechanism is defined in Figure 1. The Access Node Control Mechanism 291 defines a quasi-realtime, general-purpose method for multiple network 292 scenarios with an extensible communication scheme, addressing the 293 different use cases that are described throughout this document. 295 +--------+ 296 | Policy | 297 | Server | 298 +--------+ 299 | 300 | 301 +-----+ +-----+ +--------+ +-----+ +----------+ 302 | CPE |---| HGW |---| | | | | | 303 +-----+ +-----+ | Access | +-------------+ | | | Regional | 304 | Node |---| Aggregation |---| NAS |--| Network | 305 +-----+ +-----+ | | | Network | | | | | 306 | CPE |---| HGW |---| | +-------------+ | | | | 307 +-----+ +-----+ +--------+ +-----+ +----------+ 308 Information Report / Admission Request 309 ------------------------------> 310 Admission Response / Control Request 311 <------------------------------ 312 Control Response 313 ------------------------------> 315 Access Node Control Mechanism 316 <-----------------------------> 317 PPP, DHCP, IP 318 <---------><-----------------------------------------> 320 CPE: Customer Premises Equipment 321 HWG: Home Gateway 323 Figure 1: Access Network Architecture 325 A number of functions can be identified: 327 o A controller function: this function is used to either send out 328 requests for information to be used by the network element where 329 the controller function resides, or to trigger a certain behavior 330 in the network element where the reporting and/or enforcement 331 function resides. 333 o A reporting function: this function is used to convey status 334 information to the controller function. An example of this is the 335 transmission of the Access Loop data rate from an Access Node to a 336 Network Access Server (NAS) tasked with shaping traffic to that 337 rate. 339 o An enforcement function: this function is contacted by the 340 controller function to trigger a remote action on the Access Node. 341 An example is the initiation of a port testing mechanism on an 342 Access Node. Another example is enforcing whether a multicast 343 join is to be honored or denied. 345 The messages shown in Figure 1 show the conceptual message flow. The 346 actual use of these flows, and the times or frequencies when these 347 messages are generated depends on the actual use case, which are 348 described in Section 3. 350 The use cases in this document are described in an abstract way, 351 independent from any actual protocol mapping. The actual protocol 352 specification is out of scope of this document, but there are certain 353 characteristics of the protocol required such as to simplify 354 specification, implementation, debugging & troubleshooting, but also 355 to be easily extensible in order to support additional use cases. 357 2.2. Reference Architecture 359 The reference architecture used in this document can be based on ATM 360 or Ethernet access/aggregation. Specifically: 362 o In case of a legacy ATM aggregation network that is to be used for 363 the introduction of new QoS-enabled IP services, the architecture 364 builds on the reference architecture specified in Broadband Forum 365 [TR-059]; 367 o In case of an Ethernet aggregation network that supports new QoS- 368 enabled IP services (including Ethernet multicast replication), 369 the architecture builds on the reference architecture specified in 370 Broadband Forum [TR-101]. 372 Given the industry's move towards Ethernet as the new access and 373 aggregation technology for triple play services, the primary focus 374 throughout this document is on a TR-101 architecture. However the 375 concepts are equally applicable to an ATM architecture based on TR- 376 059. 378 2.2.1. Home Gateway 380 The Home Gateway (HGW) connects the different Customer Premises 381 Equipment (CPE) to the Access Node and the access network. In case 382 of DSL, the HGW is a DSL Network Termination (NT) that could either 383 operate as a layer 2 bridge or as a layer 3 router. In the latter 384 case, such a device is also referred to as a Routing Gateway (RG). 386 2.2.2. Access Loop 388 The Access Loop ensures physical connectivity between the HGW at the 389 customer premises, and the Access Node. In case of DSL, the Access 390 Loop physical layer could be e.g. ADSL, ADSL2+, VDSL, VDSL2 or 391 SHDSL. In order to increase bandwidth, it is also possible that 392 multiple DSL links are grouped together to form a single virtual 393 link; this process is called "DSL bonding". The protocol 394 encapsulation on the Access Loop could be based on multi-protocol 395 encapsulation over AAL5, defined in [RFC2684]. This covers PPP over 396 Ethernet (PPPoE, defined in [RFC2516]), bridged IP (IPoE, defined in 397 [RFC894]) and routed IP (IPoA, defined in [RFC2225]). Next to this, 398 PPPoA as defined in [RFC2364] can be used. Future scenarios include 399 cases where the Access Loop supports direct Ethernet encapsulation 400 (e.g. when using VDSL or VDSL2). 402 2.2.3. Access Node 404 The Access Node (AN) may support one or more Access Loop technologies 405 and allow them to inter-work with a common aggregation network 406 technology. Besides the Access Loop termination the AN can also 407 aggregate traffic from other Access Nodes using ATM or Ethernet. 409 The framework defined by this document is targeted at DSL-based 410 access (either by means of ATM/DSL or as Ethernet/DSL). The 411 framework shall be open to non-DSL technologies, like Passive Optical 412 Networks (PON) and IEEE 802.16 (WiMAX), but the details of this are 413 outside the scope of this document. 415 The reporting and/or enforcement function defined in Section 2.1 416 typically resides in an Access Node. 418 2.2.4. Access Node Uplink 420 The fundamental requirements for the Access Node uplink are to 421 provide traffic aggregation, Class of Service distinction and 422 customer separation and traceability. This can be achieved using an 423 ATM or an Ethernet based technology. 425 2.2.5. Aggregation Network 427 The aggregation network provides traffic aggregation towards the NAS. 428 The aggregation technology can be based on ATM (in case of a TR-059 429 architecture) or Ethernet (in case of a TR-101 architecture). 431 2.2.6. Network Access Server 433 The Network Access Server (NAS) interfaces to the aggregation network 434 by means of standard ATM or Ethernet interfaces, and towards the 435 Regional Network by means of transport interfaces for Ethernet frames 436 (e.g. GigE, Ethernet over SONET). The NAS functionality correpsonds 437 to the BNG functionality described in Broadband Forum TR-101. In 438 addition to this, the NAS supports the Access Node Control 439 functionality defined for the respective use cases throughout this 440 document. 442 The controller function defined in Section 2.1 typically resides in a 443 NAS. 445 2.2.7. Regional Network 447 The Regional Network connects one or more NAS and associated Access 448 Networks to Network Service Providers (NSPs) and Application Service 449 Providers (ASPs). The NSP authenticates access and provides and 450 manages the IP address to Subscribers. It is responsible for overall 451 service assurance and includes Internet Service Providers (ISPs). 452 The ASP provides application services to the application Subscriber 453 (gaming, video, content on demand, IP telephony etc.). 455 The Regional Network supports aggregation of traffic from multiple 456 Access Networks and hands off larger geographic locations to NSPs and 457 ASPs - relieving a potential requirement for them to build 458 infrastructure to attach more directly to the various Access 459 Networks. 461 2.3. Prioritizing Access Node Control traffic 463 When sending Access Node Control messages across the aggregation 464 network, care is needed that messages won't get lost. The 465 connectivity between the Access Node and the NAS may differ depending 466 on the actual layer 2 technology used (ATM or Ethernet). This 467 section briefly outlines how network connectivity can be established. 469 In case of an ATM access/aggregation network, a typical practice is 470 to send the Access Node Control Protocol messages over a dedicated 471 Permanent Virtual Circuit (PVC) configured between the AN and the 472 NAS. These ATM PVCs would then be given a high priority so that at 473 times of network congestion, loss of the ATM cells carrying the 474 Access Node Control Protocol is avoided or minimized. It is 475 discouraged to route the Access Node Control Protocol messages within 476 the Virtual Path (VP) that also carries the customer connections, if 477 that VP is configured with a best effort QoS class (e.g. Unspecified 478 Bitrate (UBR)). The PVCs of multiple Access Node Control Adjacencies 479 can be aggregated into a VP that is given a high priority and runs 480 across the aggregation network. This requires the presence of a VC 481 cross-connect in the aggregation node that terminates the VP. 483 In case of an Ethernet access/aggregation network, a typical practice 484 is to send the Access Node Control Protocol messages over a dedicated 485 Ethernet Virtual LAN (VLAN) using a separate VLAN identifier (VLAN 486 ID). This can be achieved using a different VLAN ID for each Access 487 Node, or, in networks with many Access Nodes and high degree of 488 aggregation, one Customer VLAN (C-VLAN) per Access Node and one 489 Service VLAN (S-VLAN) for the Access Node Control Adjacencies of all 490 Access Nodes. The traffic should be given a high priority (e.g. by 491 using a high Class of Service (COS) value) so that the frame loss of 492 Ethernet frames carrying the Access Node Control Protocol messages is 493 minimized in the event of network congestion. 495 In both cases, the Control Channel between NAS and Access Node could 496 use the same physical network- and routing resources as the 497 Subscriber traffic. This means that the connection is an inband 498 connection between the involved network elements. Therefore there is 499 no need for an additional physical interface to establish the Control 500 Channel. 502 Note that these methods for transporting Access Node Control Protocol 503 messages are typical examples; they do not rule out other methods 504 that achieve the same behavior. 506 The Access Node Control Adjacency interactions must be reliable. In 507 addition to this, some of the use cases described in Section 3 508 require the interactions to be performed in a transactional fashion, 509 i.e. using a "request/response" mechanism. This is required so that 510 the network elements always remain in a known state, irrespective of 511 whether or not the transaction is successful. 513 2.4. Interaction with Management Systems 515 When introducing an Access Node Control Mechanism, care is needed to 516 ensure that the existing management mechanisms remain operational as 517 before. 519 Specifically when using the Access Node Control Mechanism for 520 performing a configuration action on a network element, one gets 521 confronted with the challenge of supporting multiple managers for the 522 same network element: both the Element Manager as well as the Access 523 Node Control Mechanism may now perform configuration actions on the 524 same network element. Conflicts therefore need to be avoided. 526 Using the Access Node Control Mechanism, the NAS retrieves and 527 controls a number of Subscriber related parameters. The NAS may 528 decide to communicate this information to a central Policy or AAA 529 Server so that it kan keep track of the parameters and apply policies 530 on them. The Server can then enforce those policies on the NAS. For 531 instance, in case a subscriber is connected to more than one NAS, the 532 Policy Server could be used to coordinate the bandwidth available on 533 a given Access Port for use amongst the different NAS devices. 535 Guidelines related to management will be addressed in Section 5. 537 2.5. Circuit Addressing Scheme 539 In order to associate Subscriber parameters to a particular Access 540 Port, the NAS needs to be able to uniquely identify the Access Port 541 (or a specific circuit on an Access Port) using an addressing scheme. 543 In deployments using an ATM aggregation network, the ATM PVC on an 544 Access Loop connects the Subscriber to a NAS. Based on this 545 property, the NAS typically includes a NAS-Port-Id, NAS-Port or 546 Calling-Station-Id attribute in RADIUS authentication & accounting 547 packets sent to the RADIUS server(s). Such attribute includes the 548 identification of the ATM VC for this Subscriber, which allows in 549 turn identifying the Access Loop. 551 In an Ethernet-based aggregation network, a new addressing scheme is 552 defined in [TR-101]. Two mechanisms can be used: 554 o A first approach is to use a one-to-one VLAN assignment model for 555 all Access Ports (e.g. a DSL port) and circuits on an Access Port 556 (e.g. an ATM PVC on an ADSL port). This enables directly deriving 557 the port and circuit identification from the VLAN tagging 558 information, i.e. S-VLAN ID or pair; 560 o A second approach is to use a many-to-one VLAN assignment model 561 and to encode the Access Port and circuit identification in the 562 "Agent Circuit ID" sub-option to be added to a DHCP or PPPoE 563 message. The details of this approach are specified in [TR-101]. 565 This document reuses the addressing scheme specified in TR-101. It 566 should be noted however that the use of such a scheme does not imply 567 the actual existence of a PPPoE or DHCP session, nor on the specific 568 interworking function present in the Access Node. In some cases, no 569 PPPoE or DHCP session may be present, while port and circuit 570 addressing would still be desirable. 572 3. Use Cases for Access Node Control Mechanism 574 3.1. Access Topology Discovery 576 [TR-059] and [TR-101] discuss various queuing/scheduling mechanisms 577 to avoid congestion in the access network while dealing with multiple 578 flows with distinct QoS requirements. One technique that can be used 579 on a NAS is known as "Hierarchal Scheduling" (HS). This option is 580 applicable in a single NAS scenario (in which case the NAS manages 581 all the bandwidth available on the Access Loop) or in a dual NAS 582 scenario (in which case the NAS manages some fraction of the Access 583 Loop's bandwidth). The HS must, at a minimum, support 3 levels 584 modelling the NAS port, Access Node uplink, and Access Loop sync 585 rate. The rationale for the support of HS is as follows: 587 o Provide fairness of network resources within a class. 589 o Allow for a better utilization of network resources. Drop traffic 590 early at the NAS rather than letting it traverse the aggregation 591 network just to be dropped at the Access Node. 593 o Enable more flexible Class of Service (CoS) behaviors other than 594 only strict priority. 596 o The HS system could be augmented to provide per application 597 admission control. 599 o Allow fully dynamic bandwidth partitioning between the various 600 applications (as opposed to static bandwidth partitioning). 602 o Support "per user weighted scheduling" to allow differentiated 603 SLAs (e.g. business services) within a given traffic class. 605 Such mechanisms require that the NAS gains knowledge about the 606 topology of the access network, the various links being used and 607 their respective rates. Some of the information required is somewhat 608 dynamic in nature (e.g. DSL line rate - hence also the net data 609 rate), hence cannot come from a provisioning and/or inventory 610 management OSS system. Some of the information varies less 611 frequently (e.g. capacity of a DSLAM uplink), but nevertheless needs 612 to be kept strictly in sync between the actual capacity of the uplink 613 and the image the BRAS has of it. 615 OSS systems are typically not designed to enforce the consistency of 616 such data in a reliable and scalable manner across organizational 617 boundaries. The Access Topology Discovery function is indended to 618 allow the NAS to perform these functions without having to rely on an 619 integration with an OSS system. 621 Communicating Access Loop attributes is specifically important in 622 case the rate of the Access Loop changes overtime. The DSL actual 623 data rate may be different every time the DSL NT is turned on. In 624 this case, the Access Node sends an Information Report message to the 625 NAS after the DSL line has resynchronized. 627 Additionally, during the time the DSL NT is active, data rate changes 628 can occur due to environmental conditions (the DSL Access Loop can 629 get "out of sync" and can retrain to a lower value, or the DSL Access 630 Loop could use Seamless Rate Adaptation making the actual data rate 631 fluctuate while the line is active). In this case, the Access Node 632 sends an additional Information Report to the NAS each time the 633 Access Loop attributes change above a threshold value. 635 The hierarchy and the rates of the various links to enable the NAS 636 hierarchical scheduling and policing mechanisms are the following: 638 o The identification and speed (data rate) of the DSL Access Loop 639 (i.e. the net data rate) 641 o The identification and speed (data rate) of the Remote 642 Terminal(RT)/Access Node uplink (when relevant) 644 The NAS can adjust downstream shaping to current Access Loop actual 645 data rate, and more generally re-configure the appropriate nodes of 646 its hierarchical scheduler (support of advanced capabilities 647 according to TR-101). 649 This use case may actually include more information than link 650 identification and corresponding data rates. In case of DSL Access 651 Loops, the following Access Loop characteristics can be sent to the 652 NAS (cf. ITU-T Recommendation G.997.1 [G.997.1]): 654 o DSL Type (e.g. ADSL1, ADSL2, SDSL, ADSL2+, VDSL, VDSL2) 656 o Framing mode (e.g. ATM, ITU-T Packet Transfer Mode (PTM), IEEE 657 802.3 Ethernet in the First Mile (EFM)) 659 o DSL port state (e.g. synchronized/showtime, low power, no power/ 660 idle) 662 o Actual net data rate (upstream/downstream) 664 o Maximum achievable/attainable net data rate (upstream/downstream) 666 o Minimum net data rate configured for the Access Loop (upstream/ 667 downstream) 669 o Maximum net data rate configured for the Access Loop (upstream/ 670 downstream) 672 o Minimum net data rate in low power state configured for the Access 673 Loop (upstream/downstream) 675 o Maximum achievable interleaving delay (upstream/downstream) 677 o Actual interleaving delay (upstream/downstream) 679 The NAS MUST be able to receive Access Loop characteristics 680 information, and share such information with AAA/Policy Servers. 682 3.2. Access Loop Configuration 684 Access Loop rates are typically configured in a static way. When a 685 Subscriber wants to change its Access Loop rate, the network operator 686 needs to reconfigure the Access Port configuration, possibly implying 687 a business-to-business transaction between an Internet Service 688 Provider (ISP) and an Access Provider. From an Operating 689 Expenditures (OPEX) perspective this is a costly operation. 691 Using the Access Node Control Mechanism to change the Access Loop 692 rate from the NAS avoids those cross-organization business-to- 693 business interactions and allows to centralize Subscriber-related 694 service data in e.g. a Policy Server. More generally, several Access 695 Loop parameters (e.g. minimum data rate, interleaving delay) could be 696 changed by means of the Access Node Control Mechanism. 698 Triggered by the communication of the Access Loop attributes 699 described in Section 3.1, the NAS could query a Policy or AAA Server 700 to retrieve Access Loop configuration data. The best way to change 701 Access Loop parameters is by using profiles. These profiles (e.g. 702 DSL profiles for different services) are pre-configured by the 703 Element Manager managing the Access Nodes. The NAS may then use the 704 Configure Request message to send a reference to the right profile to 705 the Access Node. The NAS may also update the Access Loop 706 configuration due to a Subscriber service change (e.g. triggered by 707 the Policy Server). 709 The Access Loop Configuration mechanism may also be useful for 710 configuration of parameters that are not specific to the Access Loop 711 technology. Examples include the QoS profile to be used for an 712 Access Loop, or the per-Subscriber multicast channel entitlement 713 information, used for IPTV applications where the Access Node is 714 performing IGMP snooping or IGMP proxy function. The latter is also 715 discussed in Section 3.4. 717 It may be possible that a Subscriber wants to change its Access Loop 718 rate, and that the operator wants to enforce this updated Access Loop 719 Rate on the Access Node using ANCP, but that the Access Node Control 720 Adjacency is down. In such a case, the NAS will not be able to 721 request the configuration change on the Access Node. The NAS should 722 then report this failure to the external management system, which 723 could use application specific signaling to notify the Subscriber of 724 the fact that the change could not be performed at this time. 726 3.3. Remote Connectivity Test 728 Traditionally, ATM circuits are point to point connections between 729 the BRAS and the DSLAM or DSL NT. In order to test the connectivity 730 on layer 2, appropriate OAM functionality is used for operation and 731 troubleshooting. An end-to-end OAM loopback is performed between the 732 edge devices (NAS and HGW) of the broadband access network. 734 When migrating to an Ethernet-based aggregation network (as defined 735 by TR-101), end to end ATM OAM functionality is no longer applicable. 736 Ideally in an Ethernet aggregation network, end-to-end Ethernet OAM 737 as specified in IEEE 802.1ag and ITU-T Recommendation Y.1730/1731 can 738 provide Access Loop connectivity testing and fault isolation. 739 However, most HGWs do not yet support these standard Ethernet OAM 740 procedures. Also, various access technologies exist such as ATM/DSL, 741 Ethernet in the First Mile (EFM) etc. Each of these access 742 technologies have their own link-based OAM mechanisms that have been 743 or are being standardized in different standard bodies. 745 In a mixed Ethernet and ATM access network (including the local 746 loop), it is desirable to keep the same ways to test and troubleshoot 747 connectivity as those used in an ATM based architecture. To reach 748 consistency with the ATM based approach, an Access Node Control 749 Mechanism between NAS and Access Node can be used until end-to-end 750 Ethernet OAM mechanisms are more widely available. 752 Triggered by a local management interface, the NAS can use the Access 753 Node Control Mechanism to initiate an Access Loop test between Access 754 Node and HGW. In case of an ATM based Access Loop the Access Node 755 Control Mechanism can trigger the Access Node to generate ATM (F4/F5) 756 loopback cells on the Access Loop. In case of Ethernet, the Access 757 Node can perform a port synchronization and administrative test for 758 the Access Loop. The Access Node can send the result of the test to 759 the NAS via a Control Response message. The NAS may then send the 760 result via a local management interface. Thus, the connectivity 761 between the NAS and the HGW can be monitored by a single trigger 762 event. 764 3.4. Multicast 766 With the rise of supporting IPTV services in a resource efficient 767 way, multicast services are getting increasingly important. 769 In case of an ATM access/aggregation network, such as the reference 770 architecture specified in Broadband Forum [TR-059], multicast traffic 771 replication is performed in the NAS. In this model, typically IGMP 772 is used to control the multicast replication process towards the 773 subscribers. The NAS terminates and processes IGMP signaling 774 messages sent by the subscribers; towards the Regional Network, the 775 NAS typically uses a multicast routing protocol such as PIM. The ATM 776 Access Nodes and aggregation switches don't perform IGMP processing, 777 nor do they perform multicast traffic replication. As a result, 778 network resources are wasted within the access/aggregation network. 780 To overcome this resource inefficiency, the Access Node, aggregation 781 node(s) and the NAS must all be involved in the multicast replication 782 process. This avoids that several copies of the same stream are sent 783 within the access/aggregation network. In case of an Ethernet-based 784 access/aggregation network, this may, for example, be achieved by 785 means of IGMP snooping or IGMP proxy in the Access Node and 786 aggregation node(s). 788 By introducing IGMP processing in the access/aggregation nodes, the 789 multicast replication process is now divided between the NAS, the 790 aggregation node(s) and Access Nodes. In order to ensure backward 791 compatibility with the ATM-based model, the NAS, aggregation node and 792 Access Node need to behave as a single logical device. This logical 793 device must have exactly the same functionality as the NAS in the ATM 794 access/aggregation network. The Access Node Control Mechanism can be 795 used to make sure that this logical/functional equivalence is 796 achieved by exchanging the necessary information between the Access 797 Node and the NAS. 799 Another option is for the subscriber to communicate the "join/leave" 800 information with the NAS. This can for instance be done by 801 terminating all subscriber IGMP signaling on the NAS. Another 802 example could be a subscriber using some form of application level 803 signaling, which is redirected to the NAS. In any case, this option 804 is transparent to the access and aggregation network. In this 805 scenario, the NAS can use ANCP to create replication state in the AN 806 for efficient multicast replication. The NAS sends a single copy of 807 the multicast stream towards the AN. The NAS can perform conditional 808 access and multicast admission control on multicast joins, and create 809 replication state in the AN if the flow is admitted by the NAS. 811 The following subsections describe the different use cases related to 812 multicast. 814 3.4.1. Multicast Conditional Access 816 In a DSL Broadband access scenario Service Providers may want to 817 dynamically control, at the network level, access to some multicast 818 flows on a per user basis. This may be used in order to 819 differentiate among multiple Service Offers or to realize/reinforce 820 conditional access for sensitive content. Note that, in some 821 environments, application layer conditional access by means of 822 Digital Rights Management (DRM) may provide sufficient control, so 823 that Multicast Conditional Access may not be needed. 825 Where Multicast Conditional Access is required, it is possible, in 826 some cases, to provision the necessary conditional access information 827 into the AN so the AN can then perform the conditional access 828 decisions autonomously. For these cases, the NAS can use ANCP to 829 provision the necessary information in the AN so that the AN can 830 decide locally to honor a join or to not honor a join. This can be 831 done with the Control Request and Control Response messages. 833 Provisioning the conditional access information on the AN can be done 834 using a "White list", "Grey list", and/or a "Black list". A White 835 list associated with an Access Port identifies the multicast flows 836 that are allowed to be replicated to that port. A Black list 837 associated with an Access Port identifies the multicast flows that 838 are not allowed to be replicated to that port. A Grey list 839 associated with an Access Port identifies the multicast flows for 840 which the AN on receiving a join message, before starting traffic 841 replication queries the NAS for further authorization. Each list 842 contains zero, one or multiple entries and each entry may specify a 843 single flow or contain ranges (i.e. mask on Group address and/or mask 844 on Source address). 846 Upon receiving a join message on an Access Port, the Access Node will 847 first check if the requested multicast flow is part of a White, Grey 848 or a Black list associated with that Access Port. If it is part of a 849 White list, the AN autonomously starts replicating multicast traffic. 850 If it is part of a Black list, the AN autonomously discards the 851 message because the request is not authorized, and may thus inform 852 the NAS and log the request accordingly. If it is part of a Grey 853 list the AN uses ANCP to query the NAS, that in turn will respond to 854 the AN indicating whether the join is to be honored (and hence 855 replication performed by the AN) or denied (and hence replication not 856 performed by the AN.) 858 If the requested multicast flow is part of multiple lists associated 859 with the Access Port, then the most specific match will be used. If 860 the most specific match occurs in multiple lists, the Black list 861 entry takes precedence over the Grey list, which takes precedence 862 over the White list. 864 If the requested multicast flow is not part of any list, the message 865 should be discarded. This default behavior can easily be changed by 866 means of a "catch-all" statement in either the White list or the Grey 867 list. For instance, adding () in the White List would make 868 the default behavior to accept join messages for a multicast flow 869 that has no other match on any list. Similarly, if the default 870 behavior should be to send a request to the NAS, then adding 871 () in the Grey List accomplishes that. 873 The White List, Black List and Grey List can contain entries 874 allowing: 876 o an exact match for a (*,G) ASM group (e.g. ); 878 o an exact match for a (S,G) SSM channel (e.g. 879 ); 881 o a mask-based range match for a (*,G) ASM group (e.g. ); 884 o a mask-based range match for a (S,G) SSM channel (e.g. ); 887 Following are some example configurations: 889 o Scenario 1: reject all messages 891 * Black List = {} 893 o Scenario 2: reject all messages, except Join (S=*,G=Gi) (1<=i<=n) 895 * White List = { , , ... } 897 * Black List = {} 899 o Scenario 3: AN performs autonomous decisions for some channels, 900 and asks the NAS for other channels 902 * White List = { , , ... } 904 * Grey List = { } for m>n 906 * Black list = {} 907 * ==> Join (S=*,G=Gi) gets honored by AN ( 1<=i<=n ) 909 * ==> Join (S=s,G=Gm) triggers ANCP Admission Request to NAS 911 * ==> everything else gets rejected by AN 913 The use of a White list and Black list may be applicable, for 914 instance, to regular IPTV services (i.e. Broadcast TV) offered by an 915 Access Provider to broadband (e.g. DSL) subscribers. For this 916 application, the IPTV subscription is typically bound to a specific 917 DSL line, and the multicast flows that are part of the subscription 918 are well-known beforehand. Furthermore, changes to the conditional 919 access information are infrequent, since they are bound to the 920 subscription. Hence the Access Node can be provisioned with the 921 conditional access information related to the IPTV service. 923 In some other cases, it may be desirable to have the conditional 924 access decision being taken by the NAS or a Policy Server. This may 925 be the case when conditional access information changes frequently, 926 or when the multicast groups are not known to a client application in 927 advance. The conditional access control could be tied to a more 928 complex policy/authorization mechanism, e.g. time of day access, or 929 location based access or to invoke a remote authorisation server. 930 For these cases, the AN can use ANCP to query the NAS, that in turn 931 will respond to the AN indicating whether the join is to be honored 932 (and hence replication performed by the AN) or denied. This can be 933 done with the Admission Request and Admission Response messages. 935 Some examples of using NAS querying are the following: 937 o Roaming users: a subscriber that logs in on different wireless 938 hotspots and would like to receive multicast content he is 939 entitled to receive; 941 o A related example is that of mobility or seamless handover; in 942 both cases the burden of (re)configuring access nodes with White 943 lists or Black lists may be too high; 945 o "Over The Top Video Partnerships": Service Providers may choose to 946 partner with Internet video providers to provide video content. 947 In this case, the multicast group mappings may not be known in 948 advance, or may be reused for different content in succession. 950 o "Pay Per View": This is the case when a subscriber chooses a 951 specific IPTV channel which is made available for a given amount 952 of time. 954 3.4.2. Multicast Admission Control 956 The successful delivery of Triple Play Broadband services is quickly 957 becoming a big capacity planning challenge for most of the Service 958 Providers nowadays. Solely increasing available bandwidth is not 959 always practical, cost-economical and/or sufficient to satisfy end 960 user experience given not only the strict requirements of unicast 961 delay sensitive applications like VoIP and Video, but also the fast 962 growth of multicast interactive applications such as 963 videoconferencing, digital TV, digital audio, online movies and 964 networked gaming. These applications are typically characterized by 965 a delay sensitive nature, an extremely loss sensitive nature and 966 intensive bandwidth requirements. They are also typically "non- 967 elastic", which means that they operate at a fixed bandwidth, that 968 cannot be dynamically adjusted to the currently available bandwidth. 970 Therefore a Connection Admission Control (CAC) mechanism covering 971 admission of video traffic over the DSL Broadband access is required, 972 in order to avoid oversubscribing the available bandwidth and 973 negatively impacting the end user experience. 975 Considering specifically admission control over the access line, 976 before honoring a user request to join a new multicast flow, the 977 combination of AN and NAS must ensure admission control is performed 978 to validate that there is sufficient bandwidth remaining on the 979 access line to carry the new video stream (in addition to all other 980 multicast and unicast video streams sent over the access line). The 981 solution needs to cope with multiple flows per access line and needs 982 to allow access line bandwidth to be dynamically shared across 983 multicast and unicast traffic (the unicast CAC is performed either by 984 the NAS or by some off-path Policy Server). 986 Thus, supporting CAC for the access line requires some form of 987 synchronization between the entity performing multicast CAC (e.g. the 988 NAS or the AN), the entity performing unicast CAC (e.g. the Policy 989 Server) and the entity actually enforcing the multicast replication 990 (i.e. the AN). This synchronization can be achieved in a number of 991 ways: 993 o One approach is for the AN to query the NAS so that Admission 994 Control for the access line is performed by the NAS, or by the 995 Policy Server which interacts with the AN via NAS. The AN can use 996 ANCP to query the NAS, that in turn performs multicast Admission 997 Control check for the new multicast flow and responds to the AN 998 indicating whether the join is to be honored (and hence 999 replication performed by the AN) or denied. The NAS may locally 1000 keep track of the portion of the Access Loop net data rate that is 1001 available for (unicast or multicast) video flows, and perform 1002 video bandwidth accounting for the Access Loop. Upon receiving an 1003 Admission Request from the AN, the NAS can check available Access 1004 Loop bandwidth before admitting or denying the multicast flow. In 1005 the process, the NAS may communicate with the Policy Server. For 1006 unicast video services such as Video on Demand (VoD), the NAS may 1007 also be queried (by a Policy Server or via on-path CAC signaling), 1008 so that it can perform admission control for the unicast flow, and 1009 update the remaining available Access Loop bandwidth. The ANCP 1010 requirements to support this approach are specified in this 1011 document. 1013 o The above model could be enhanced with the notion of "Delegation 1014 of Authorization". In such a model, the NAS or the Policy Server 1015 delegates authority to the Access Node to perform multicast 1016 Admission Control on the Access Loop. This is sometimes referred 1017 to as "Bandwidth Delegation", referring to the portion of the 1018 total Access Loop bandwidth which can be used by the Access Node 1019 for multicast Admission Control. In this model, the NAS or the 1020 Policy Server manages the total access line bandwidth, performs 1021 unicast admission control and uses ANCP to authorize the Access 1022 Node to perform multicast Admission Control within the bounds of 1023 the "delegated bandwidth". Upon receiving a request for a 1024 multicast flow replication which matches an entry in the White or 1025 Grey List, the AN performs the necessary bandwidth admission 1026 control check for the new multicast flow, before starting the 1027 multicast flow replication. At this point, there is typically no 1028 need for the Access Node to communicate with the NAS or the Policy 1029 Server via the NAS. The ANCP requirements to support this 1030 approach are also specified in this document. 1032 o In case the subscriber communicates the "join/leave" information 1033 with the NAS (e.g. by terminating all subscriber IGMP signaling on 1034 the NAS, or by using some form of application level signaling), 1035 the approach is very similar. In this case, the NAS may locally 1036 keep track of the portion of the Access Loop bandwidth that is 1037 available for video flows, perform CAC for unicast and multicast 1038 flows and perform video bandwidth management. The NAS can set the 1039 replication state on the AN using ANCP if the flow is admitted. 1040 For unicast video services the NAS may be queried (by a policy 1041 server or via on-path CAC signaling) to perform admission control 1042 for the unicast flow, and update the remaining available Access 1043 Loop bandwidth. The ANCP requirements to support this approach 1044 are specified in this document; 1046 o In the last approach, the Policy Server queries the AN directly or 1047 indirectly via the NAS, so that both unicast and multicast CAC for 1048 the access line are performed by the AN. In this case, a 1049 subscriber request for a unicast flow (e.g. a Video on Demand 1050 session) will trigger a resource request message towards a Policy 1051 Server; the latter will then query the AN (possibly via the NAS), 1052 that in turn will perform unicast CAC for the access line and 1053 respond, indicating whether the unicast request is to be honored 1054 or denied. The above model could also be enhanced with the notion 1055 of "Delegation of Authorization". In such a model, the Policy 1056 Server delegates authority to the Access Node to perform multicast 1057 Admission Control on the Access Loop. In the case when the Policy 1058 Server queries the AN directly, the approach doesn't require the 1059 use of ANCP. It is therefore beyond the scope of this document. 1060 In the case when the Policy Server queries the AN indirectly via 1061 the NAS, the approach requires the use of ANCP and is therefore in 1062 the scope of this document. 1064 3.4.2.1. Delegation of Authority - Bandwidth Delegation 1066 The NAS uses ANCP to indicate to the AN whether or not Admission 1067 Control is required for a particular multicast flow on a given Access 1068 Port. In case Admission Control is required, the Access Node needs 1069 to know whether or not it is authorized to perform Admission Control 1070 itself and, if so, within which bounds it is authorized to do so 1071 (i.e. how much bandwidth is "delegated" by the NAS or the Policy 1072 Server). Depending on the type of multicast flow, Admission Control 1073 may or may not by done by the AN: 1075 o Multicast flows that require a Conditional Access operation to be 1076 performed by the Access Node, are put in the Black or White List. 1077 In addition, the Access Node performs Admission Control for those 1078 flows in the White List for which it is authorized to do so. 1080 o Multicast flows that require a Conditional Access operation to be 1081 performed by the NAS or the Policy Server, are put in the Grey 1082 List. In addition, for those flows in the Grey List for which the 1083 Access Node should perform Admission Control, the NAS or the 1084 Policy Server will delegate authority to the AN. 1086 In some cases, the bandwidth that the NAS or the Policy Server 1087 initially delegated to the AN may not be enough to satisfy a 1088 multicast request for a new flow. In this scenario the AN can use 1089 ANCP to query the NAS in order to request additional delegated 1090 multicast bandwidth. This is a form of extending the AN 1091 authorization to perform Admission Control. The NAS or the Policy 1092 Server decides if the request for more bandwidth can be satisfied and 1093 uses ANCP to send a response to the AN indicating the updated 1094 delegated multicast bandwidth. It is worth noting that in this case, 1095 the time taken to complete the procedure is an increment to the 1096 zapping delay: in order to minimize the zapping delay for future join 1097 requests the AN can insert in the request message two values: the 1098 minimum amount of additional multicast bandwidth requested, and the 1099 preferred additional amount. The first value is the amount that 1100 allows the present join request to be satisfied, the second value an 1101 amount that anticipates further join requests. 1103 In some cases, the NAS or the Policy Server may not have enough 1104 unicast bandwidth to satisfy a new incoming video request: in these 1105 scenarios the NAS can use ANCP to query (or instruct) the AN in order 1106 to decrease the amount of multicast bandwidth previously delegated on 1107 a given Access Port. This is a form of limiting/withdrawing AN 1108 authorization to perform Admission Control. The NAS can use ANCP to 1109 send a response to AN indicating the updated delegated multicast 1110 bandwidth. Based on considerations similar to those of the previous 1111 paragraph, it indicates the minimum amount of multicast bandwidth 1112 that it needs released and a preferred amount, which may be larger. 1114 Note: in order to avoid impacting existing multicast traffic, the NAS 1115 must not decrease the amount of delegated multicast bandwidth to a 1116 value lower than the bandwidth that is currently in use. This 1117 requires the NAS to be aware of this information (e.g. by means of a 1118 separate query action). 1120 In addition, in some cases, upon receiving a leave for a specific 1121 multicast flow, the AN may decide that it has an excess of delegated 1122 but uncommitted bandwidth. In such case, the AN can use ANCP to send 1123 a message to the NAS to release (part of the) unused multicast 1124 bandwidth previously delegated. In this process, the Access Node may 1125 decide to retain a minimum amount of bandwidth for multicast 1126 services. 1128 3.4.2.2. When not to perform Admission Control for a subset of flows 1130 In general, the Access Node and NAS may not be aware of all possible 1131 multicast groups that will be streamed in the access network. For 1132 instance, it is likely that there will be multicast streams offered 1133 across the Internet. For these unknown streams, performing bandwidth 1134 Admission Control may be challenging. 1136 To solve this, these requests could be accepted without performing 1137 Admission Control. This solution works, provided that the network 1138 handles the streams as best effort, so that other streams (that are 1139 subject to Admission Control) are not impacted at times of 1140 congestion. 1142 Disabling Admission Control for an unknown stream can be achieved by 1143 adding a "catch-all statement" in the Access Node white list or grey 1144 list. In case the Access Node queries the NAS, the NAS on his turn 1145 will have to accept the request. That way, the unknown streams are 1146 not blocked by default. 1148 Next, in order to ensure that the streams are handled as best effort, 1149 the flow must be marked as such when entering the service provider 1150 network. This way, whenever congestion occurs somewhere in the 1151 access/aggregation network, this stream will be kicked out before the 1152 access provider's own premium content. 1154 The above concept is applicable beyond the notion of "Internet 1155 streams" or other unknown streams; it can applied to known multicast 1156 streams as well. In this case, the Access Node or NAS will accept 1157 the stream even when bandwidth may not be sufficient to support the 1158 stream. This again requires that the stream is marked as best effort 1159 traffic before entering the access/aggregation network. 1161 3.4.2.3. Multicast Admission Control and White Lists 1163 As mentioned in section Section 3.4.1, conditional access to popular 1164 IPTV channels can be achieved by means of a White and Black list 1165 configured on the Access Node. This method allows the Access Node to 1166 autonomously decide whether or not access can be granted to a 1167 multicast flow. 1169 IPTV is an example of a service that will not be offered as best 1170 effort, but requires some level of guaranteed Quality of Service. 1171 This requires the use of Multicast Admission Control. Hence, if the 1172 Access Node wants to autonomously perform the admission process, it 1173 must be aware of the bandwidth characteristics of multicast flows. 1174 Otherwise, the Access Node would have to query the NAS for Multicast 1175 Admission Control (as per the Grey list behavior); this would defeat 1176 the purpose of using a White and Black list. 1178 Some network deployments may combine the use of White list, Black 1179 list and Grey list. The implications of such a model to the overall 1180 Multicast Admission Control model are not fully explored in this 1181 document. 1183 3.4.3. Multicast Accounting and Reporting 1185 It may be desirable to perform time and/or volume based accounting 1186 for certain multicast flows sent on particular Access Ports. In case 1187 the AN is performing the traffic replication process, it knows when 1188 replication of a multicast flow to a particular Access Port or user 1189 start and stops. Multicast accounting can be addressed in two ways: 1191 o The AN keeps track of when replication for a given multicast flow 1192 starts or ends on a specified Access Port, and generates time 1193 and/or volume based accounting information per Access Port and per 1194 multicast flow, before sending it to a central accounting system 1195 for logging. Given that the AN communicates with the accounting 1196 system directly, the approach doesn't require the use of ANCP. It 1197 is therefore beyond the scope of this document; 1199 o The AN keeps track of when replication for a given multicast flow 1200 starts or ends on a specified Access Port, and reports this 1201 information to the NAS for further processing. In this case, ANCP 1202 can be used to send the information from the AN to the NAS. This 1203 will be discussed in the remainder of this document. 1205 The Access Node can send multicast accounting information to the NAS 1206 using the Information Report message. A distinction can be made 1207 between two cases: 1209 o Basic accounting information: the Access Node informs the NAS 1210 whenever replication starts or ends for a given multicast flow on 1211 a particular Access Port; 1213 o Detailed accounting information: the Access Node not only informs 1214 the NAS when replication starts or ends, but also informs the NAS 1215 about the multicast traffic volume replicated on the Access Port 1216 for that multicast flow. This is done by adding a byte count in 1217 the Information Report message which is sent to the NAS when 1218 replication ends. 1220 Upon receiving the Information Report messages, the NAS generates the 1221 appropriate time and/or volume based accounting records per Access 1222 Loop and per multicast flow, to be sent to the accounting system. 1224 The NAS should inform the Access Node about the type of accounting 1225 needed for a given multicast flow on a particular Access Port: 1227 o No reporting messages need to be sent to the NAS 1229 o Basic accounting is required 1231 o Detailed accounting is required 1233 Note that in case of very fast channel changes, the amount of 1234 Information Report messages to be sent to the NAS could become high. 1236 The ANCP requirements to support this use case are specified below in 1237 this document. 1239 It may also be desirable for the NAS to have the capability to 1240 asynchronously query the AN to obtain an instantaneous status report 1241 related to multicast flows currently replicated by the AN. Such a 1242 reporting functionality could be useful for troubleshooting and 1243 monitoring purposes. The NAS can query the AN to know the following: 1245 o Which flows are currently being sent on a specific Access Port 1246 (i.e. a report for one Access Port) 1248 o On which Access Ports is a specified multicast flow currently 1249 being sent (i.e. a report for one multicast flow) 1251 o Which multicast flows are currently being sent on each of the 1252 Access Ports (i.e. a global report for one Access Node) 1254 3.4.4. Spontaneous Admission Response 1256 The capability to dynamically stop the replication of a multicast 1257 flow can be useful in different scenarios: for example in case of 1258 prepaid service, when available credit expires, the Service Provider 1259 may want to be able to stop multicast replication on a specified 1260 Access Port for a particular user. Another example of applicability 1261 for this functionality is a scenario where a Service Provider would 1262 like to show a "Content Preview": in this case a multicast content 1263 will be delivered just for a fixed amount of time. 1265 In both cases an external entity (for example a Policy Server or an 1266 external application entity), can instruct the NAS to interrupt the 1267 multicast replication of a specified multicast flow to a specified 1268 Access Port or user. The NAS can then use ANCP to communicate this 1269 decision to the Access Node. This can be done with the Admission 1270 Response message. 1272 In some deployment scenarios, the NAS may be made aware of end-users 1273 requests to join/leave a multicast flow by other means than ANCP 1274 Admission Requests sent by the AN. One possible deployment scenario 1275 where this model applies is the case where the Access Node doesn't 1276 process the IGMP join/leave messages from the end-user (e.g. because 1277 they are tunneled), but forwards them to the NAS. In such 1278 environments, the NAS can control multicast replication on the AN via 1279 ANCP through the use of Spontaneous Admission Responses (i.e. sent by 1280 the NAS without prior receipt of a corresponding Admission Request). 1282 4. Requirements 1284 4.1. ANCP Functional Requirements 1286 R-1 The ANCP MUST be easily extensible through the definition of new 1287 message types or TLVs to support use cases beyond those 1288 currently addressed in this document (this includes the use of 1289 Access Nodes different from a DSLAM, e.g. a PON Access Node). 1291 R-2 The ANCP MUST be flexible enough to accommodate the various 1292 technologies that can be used in an access network and in the 1293 Access Node; this includes both ATM and Ethernet. 1295 R-3 The Access Node Control interactions MUST be reliable (using 1296 either a reliable transport protocol (e.g. TCP) for the Access 1297 Node Control Protocol messages, or by designing ANCP to be 1298 reliable). 1300 R-4 The ANCP MUST support "request/response" transaction-based 1301 interactions for the NAS to communicate control decisions to the 1302 Access Node, or for the NAS to request information from the 1303 Access Node. Transactions MUST be atomic, i.e. they are either 1304 fully completed, or rolled-back to the previous state. This is 1305 required so that the network elements always remain in a known 1306 state, irrespective of whether or not the transaction is 1307 successful. 1309 In case the NAS wants to communicate a bulk of independent control 1310 decisions to the Access Node, the transaction (and notion of 1311 atomicity) applies to the individual control decisions. This avoids 1312 having to roll back all control decisions. Similarly, if the NAS 1313 wants to request a bulk of independent information elements from the 1314 Access Node, the notion of transaction applies to the individual 1315 information elements. 1317 R-5 The ANCP MUST be scalable enough to allow a given NAS to control 1318 at least 5000 Access Nodes. 1320 R-6 The operation of the ANCP in the NAS and Access Nodes MUST be 1321 controllable via a management station (e.g. via SNMP). This 1322 MUST allow a management station to retrieve statistics and 1323 alarms related to the operation of the ANCP, as well as to allow 1324 it to initiate OAM operations and retrieve corresponding 1325 results. 1327 4.2. ANCP Multicast Requirements 1329 R-7 The ANCP MUST support providing multicast conditional access 1330 information to Access Ports on an Access Node, using Black, 1331 Grey and White lists. 1333 R-8 The ANCP MUST support binding a particular Black, Grey and 1334 White List to a given Access Port. 1336 R-9 Upon receiving a join to a multicast flow which matches the 1337 Grey List the ANCP MUST allow the AN to query the NAS to 1338 request an admission decision for replicating that multicast 1339 flow to a particular Access Port. 1341 R-10 The ANCP MUST allow the NAS to send an admission decision to 1342 the AN indicating whether or not a multicast flow may be 1343 replicated to a particular Access Port. 1345 R-11 The ANCP MUST allow the NAS to indicate to the AN whether or 1346 not Admission Control is needed for some multicast flows on a 1347 given Access Port and where needed whether or not the Access 1348 Node is authorized to perform Admission Control itself (i.e. 1349 whether or not AN Bandwidth Delegation applies). 1351 R-12 In case of Admission Control without AN Bandwidth Delegation, 1352 the ANCP MUST allow the NAS to reply to a query from the AN 1353 indicating whether or not a multicast flow is allowed to be 1354 replicated to a particular Access Port. 1356 R-13 In case of Admission Control with AN Bandwidth Delegation, the 1357 ANCP MUST allow the NAS to delegate a certain amount of 1358 bandwidth to the AN for a given Access Port for multicast 1359 services only. 1361 R-14 In case of Admission Control with AN Bandwidth Delegation, the 1362 ANCP MUST allow the AN to query the NAS to request additional 1363 multicast bandwidth on a given Access Port. 1365 R-15 In case of Admission Control with AN Bandwidth Delegation, the 1366 ANCP MUST allow the NAS to query (or to instruct) the AN to 1367 reduce the amount of bandwidth previously delegated on a given 1368 Access Port. 1370 R-16 In case of Admission Control with AN Bandwidth Delegation, the 1371 ANCP MUST allow the AN to inform the NAS in case it 1372 autonomously releases redundant multicast bandwidth on a given 1373 Access Port. 1375 R-17 The ANCP MUST allow the AN to send an Information Report 1376 message to the NAS whenever replication of a multicast flow on 1377 a particular Access Port start or ends. 1379 R-18 The ANCP MUST allow the AN to send an Information Report 1380 message to the NAS indicating the multicast traffic volume that 1381 has been replicated on that port. 1383 R-19 The ANCP MUST allow the NAS to indicate to the AN whether or 1384 not multicast accounting is needed for a multicast flow on a 1385 particular Access Port. 1387 R-20 In case multicast accounting is needed for a multicast flow on 1388 a particular Access Port, the ANCP MUST allow the NAS to 1389 indicate to the AN whether or not additional volume accounting 1390 information is required. 1392 R-21 The ANCP MUST allow the NAS to revoke a decision to replicate a 1393 multicast flow to a particular Access Port, which had been 1394 conveyed earlier to an AN. 1396 R-22 The ANCP MUST support partial updates of the White, Grey and 1397 Black lists. 1399 R-23 The ANCP MUST allow the NAS to query the AN to obtain 1400 information on what multicast flows are currently being 1401 replicated on a given Access Port, what Access Ports are 1402 currently receiving a given multicast flow, or what multicast 1403 flows are currently replicated on each Access Port. 1405 4.3. Protocol Design Requirements 1407 R-24 The ANCP SHOULD provide a "shutdown" sequence allowing the 1408 protocol to inform the peer that the system is gracefully 1409 shutting down. 1411 R-25 The ANCP SHOULD include a "report" model for the Access Node to 1412 spontaneously communicate to the NAS changes of states. 1414 R-26 The ANCP SHOULD support a graceful restart mechanism to enable 1415 it to be resilient to network failures between the AN and NAS. 1417 R-27 The ANCP MUST provide a means for the AN and the NAS to inform 1418 each peer about the supported use cases (either use cases 1419 defined in this document or future use cases yet to be 1420 defined), and to negotiate a common subset. 1422 4.4. Access Node Control Adjacency Requirements 1424 The notion of an Access Node Control Adjacency is defined in 1425 Section 1.2. 1427 R-28 The ANCP MUST support an adjacency protocol in order to 1428 automatically synchronize its operational state between its 1429 peers, to agree on which version of the protocol to use, to 1430 discover the identity of its peers, and detect when they 1431 change. 1433 R-29 The ANCP MUST include a mechanism to automatically detect 1434 adjacency loss. 1436 R-30 A loss of the Access Node Control Adjacency MUST NOT affect 1437 subscriber connectivity. 1439 R-31 If the Access Node Control Adjacency is lost, it MUST leave the 1440 network elements in a known state, irrespective of whether or 1441 not the ongoing transaction was successful. 1443 R-32 The ANCP MUST support a mechanism to synchronize access port 1444 configuration and status information between ANCP peers as part 1445 of establishing or recovering the Access Node Control 1446 Adjacency. 1448 4.5. ANCP Transport Requirements 1450 R-33 The Access Node Control Mechanism MUST be defined in a way that 1451 is independent of the underlying layer 2 transport technology. 1452 Specifically, the Access Node Control Mechanism MUST support 1453 transmission over an ATM as well as over an Ethernet 1454 aggregation network. 1456 R-34 The ANCP MUST use the IP protocol stack. 1458 R-35 If the layer 2 transport technology is based on ATM, then the 1459 ANCP peers must use the encapsulation according to [RFC2684] 1460 routed (IPoA). 1462 R-36 If the layer 2 transport technology is based on Ethernet, then 1463 the ANCP peers must use the encapsulation according to [RFC894] 1464 (IPoE). 1466 4.6. Access Node Requirements 1468 This section lists the requirements for an AN that supports the use 1469 cases defined in this document. Note that this document does not 1470 intend to impose absolute requirements on network elements. 1471 Therefore, the words "must" and "should" used in this section are not 1472 capitalized. 1474 4.6.1. General Architecture 1476 The Access Node Control Mechanism is defined to operate between an 1477 Access Node (AN) and a NAS. In some cases, one AN can be connected 1478 to more than one physical NAS devices (e.g. in case different 1479 wholesale service providers have different NAS devices). In such a 1480 model, the physical AN needs to be split in virtual ANs, each having 1481 its own Access Node Control reporting and/or enforcement function. 1483 R-37 An Access Node as physical device can be split in logical 1484 partitions. Each partition may have its independent NAS. 1485 Therefore the Access Node must support at least 2 partitions. 1486 The Access Node should support 8 partitions. 1488 R-38 One partition is grouped of several Access Ports. Each Access 1489 Port on an Access Node must be assigned uniquely to one 1490 partition. 1492 It is assumed that all circuits (i.e. ATM PVCs or Ethernet VLANs) on 1493 top of the same physical Access Port are associated with the same 1494 partition. In other words, partitioning is performed at the level of 1495 the physical Access Port only. 1497 R-39 Each AN partition must have a separate Access Node Control 1498 Adjacency to a NAS. 1500 R-40 Each AN partition must be able to enforce access of the 1501 controllers to their designated partitions. 1503 R-41 The Access Node should be able to establish and maintain ANCP 1504 Adjacencies to redundant controllers. 1506 4.6.2. Control Channel Attributes 1508 The Control Channel is a bidirectional IP communication interface 1509 between the controller function (in the NAS) and the reporting/ 1510 enforcement function (in the AN). It is assumed that this interface 1511 is configured (rather than discovered) on the AN and the NAS. 1513 Depending on the network topology, the Access Node can be located in 1514 a street cabinet or in a central office. If an Access Node in a 1515 street cabinet is connected to a NAS, all user traffic and Access 1516 Node Control data can use the same physical link. 1518 R-42 The Control Channel should use the same facilities as the ones 1519 used for the data traffic. Note that this is actually a 1520 deployment consideration, which has no impact on the actual 1521 protocol design. 1523 R-43 The Access Node must process control transactions in real-time 1524 (i.e. with a specific response latency). 1526 R-44 The Access Node should mark Access Node Control Protocol 1527 messages with a high priority (e.g. VBR-rt for ATM cells, 1528 p-bit 6 or 7 for Ethernet packets) in order to avoid or reduce 1529 the likelihood of dropping packets in case of network 1530 congestion. 1532 R-45 If ATM interfaces are used then any VPI and VCI value must be 1533 able to be used for the purpose of supporting the Access Node 1534 Control Channel. 1536 R-46 If Ethernet interfaces are used then any C-VID and S-VID must 1537 be able to be used for the purpose of supporting the Access 1538 Node Control Channel. 1540 4.6.3. Capability Negotiation Failure 1542 R-47 In case the Access Node and NAS cannot agree on a common set of 1543 capabilities, as part of the ANCP capability negotiation 1544 procedure, the Access Node must report this to network 1545 management. 1547 4.6.4. Adjacency Status Reporting 1549 R-48 The Access Node should support generating an alarm to a 1550 management station upon loss or malfunctioning of the Access 1551 Node Control Adjacency with the NAS. 1553 4.6.5. Identification 1555 R-49 To identify the Access Node and Access Port within a control 1556 domain a unique identifier is required. This identifier must 1557 be in line with the addressing scheme principles specified in 1558 section 3.9.3 of TR-101. 1560 R-50 In a Broadband Forum TR-101 network arcitecture, an Access 1561 Circuit Identifier (ACI) identifying an AN and Access Port is 1562 added to DHCP and PPPoE messages. The NAS must use the same 1563 ACI format in ANCP messages in order to allow the NAS to 1564 correlate this information with the information present in DHCP 1565 and PPPoE messages. 1567 4.6.6. Multicast 1569 R-51 The AN must deny any join to a multicast flow matching the 1570 Black List for the relevant Access Port. 1572 R-52 The AN must accept any join to a multicast flow matching the 1573 White List and for which no Bandwidth Delegation is used. 1575 R-53 Upon receiving a join to a multicast flow which matches the 1576 White List and for which Bandwidth Delegation is used, the AN 1577 must perform the necessary bandwidth admission control check 1578 for the new flow before starting the multicast flow 1579 replication. This may involve a decision taken locally, or 1580 querying the NAS or external system such as a Policy Server, to 1581 request additional delegated multicast bandwidth on a given 1582 Access Port. 1584 R-54 Upon receiving a join to a multicast flow which matches the 1585 Grey List and for which no Bandwidth Delegation is used, the AN 1586 must support using ANCP to query the NAS to receive a response 1587 indicating whether that join is to be honored or denied. In 1588 this case, the NAS will perform both the necessary conditional 1589 access and the admission control checks for the new flow. 1591 R-55 Upon receiving a join to a multicast flow which matches the 1592 Grey List and for which Bandwidth Delegation is used, the AN 1593 must first perform the necessary bandwidth admission control 1594 check for the new flow. If successful, the AN must support 1595 using ANCP to query the NAS to receive a response indicating 1596 whether that join is to be honored or denied. 1598 R-56 In case of Admission Control with AN Bandwidth Delegation, the 1599 AN must support using ANCP to notify the NAS when the the user 1600 leaves the multicast flow. 1602 R-57 In case of Admission Control with AN Bandwidth Delegation, the 1603 AN must support using ANCP to query the NAS to request 1604 additional delegated multicast bandwidth on a given Access 1605 Port; the AN should be able to specify both the minimum and the 1606 preferred amount of additional multicast bandwidth requested. 1608 R-58 In case of Admission Control with AN Bandwidth Delegation, upon 1609 receiving a Bandwidth Delegation Request from the NAS querying 1610 the AN for the delegated multicast bandwidth on a given Access 1611 Port, the AN must support using ANCP to send a Bandwidth 1612 Delegation Response, indicating the currently delegated 1613 multicast bandwidth. 1615 R-59 In case of Admission Control with AN Bandwidth Delegation, it 1616 may happen that the NAS wants to "revoke" (part of) the 1617 delegated bandwidth. Part of the previously delegated 1618 bandwidth may however be in use by multicast services. 1619 Therefore, upon receiving a Bandwidth Delegation Request from 1620 the NAS instructing to decrease the delegated multicast 1621 bandwidth on a given Access Port, the AN must support using 1622 ANCP to send a Bandwidth Delegation Response, indicating the 1623 delegated multicast bandwidth after the decrease (indicating 1624 how much of the delegated bandwidth can be returned to the NAS 1625 without impacting multicast services that are currently 1626 running). 1628 R-60 In case of Admission Control with AN Bandwidth Delegation, the 1629 AN must support using ANCP to send a Bandwidth Release message 1630 to the NAS in order to release unused delegated multicast 1631 bandwidth on a given Access Port. 1633 R-61 If the requested multicast flow is not part of any list 1634 associated with the Access Port, the AN must discard the 1635 message. 1637 R-62 If the requested multicast flow is part of multiple lists 1638 associated with the Access Port, the AN must use the most 1639 specific match. 1641 R-63 If the requested multicast flow has the same most specific 1642 match in multiple lists, the AN must give precedence to the 1643 Black list, followed by the Grey list, and then the White list. 1645 R-64 The AN must support configuring a "catch-all" statement in the 1646 Black, White or Grey list in order to enforce a default 1647 behavior for a join to a multicast flow which doesn't match any 1648 other entry in a list for the relevant Access Port. 1650 R-65 Upon querying the NAS, the AN must not propagate the join 1651 message before the successful authorization from the NAS is 1652 received. 1654 R-66 Upon receiving a leave for a multicast flow which matches the 1655 Grey List, the AN should be able to autonomously stop 1656 replication and advertise this event to the NAS. 1658 R-67 The AN must support using ANCP to send an Information Report 1659 message to the NAS whenever replication starts or ends. 1661 R-68 The AN should support using ANCP to send an Information Report 1662 message to the NAS indicating the multicast traffic volume that 1663 has been replicated on that port. 1665 R-69 Upon request by the NAS, the AN must support using ANCP to send 1666 an Information Report message to the NAS, indicating what 1667 multicast flows are currently being replicated on a given 1668 Access Port. 1670 R-70 Upon request by the NAS, the AN must support using ANCP to send 1671 an Information Report message to the NAS, indicating what 1672 Access Ports are currently receiving a given multicast flow. 1674 R-71 Upon request by the NAS, the AN must support using ANCP to send 1675 an Information Report message to the NAS, indicating what 1676 multicast flows are currently being replicated on each Access 1677 Port. 1679 R-72 Upon receiving an Admission Response from the NAS, indicating 1680 that replication of a multicast flow is to start or stop on a 1681 given access port of the AN, the AN must enforce this decision. 1682 This decision must be taken irrespective of whether or not a 1683 corresponding Admission Request was issued by the AN earlier 1684 on. 1686 4.6.7. Message Handling 1688 R-73 The Access Node must be designed to allow fast completion of 1689 ANCP operations, in the order of magnitude of tens of 1690 milliseconds. 1692 R-74 The Access Node should avoid sending bursts of ANCP messages 1693 related to notification of line attributes or line state, by 1694 spreading message transmission over time. 1696 4.6.8. Parameter Control 1698 Naturally the Access Node Control Mechanism is not designed to 1699 replace an Element Manager managing the Access Node. There are 1700 parameters in the Access Node, such as the DSL noise margin and DSL 1701 Power Spectral Densities (PSD), which are not allowed to be changed 1702 via ANCP or any other control session, but only via the Element 1703 Manager. This has to be ensured and protected by the Access Node. 1705 When using ANCP for Access Loop Configuration, the EMS needs to 1706 configure on the Access Node which parameters may or may not be 1707 modified using the Access Node Control Mechanism. Furthermore, for 1708 those parameters that may be modified using ANCP, the EMS needs to 1709 specify the default values to be used when an Access Node comes up 1710 after recovery. 1712 R-75 When Access Loop Configuration via ANCP is required, the EMS 1713 must configure on the Access Node which parameter set(s) may be 1714 changed/controlled using ANCP. 1716 R-76 Upon receiving an Access Node Control Request message, the 1717 Access Node must not apply changes to the parameter set(s) that 1718 have not been enabled by the EMS. 1720 4.7. Network Access Server Requirements 1722 This section lists the requirements for a NAS that supports the use 1723 cases defined in this document. Note that this document does not 1724 intend to impose absolute requirements on network elements. 1725 Therefore, the words "must" and "should" used in this section are not 1726 capitalized. 1728 4.7.1. General Architecture 1730 R-77 The NAS must establish ANCP Adjacencies only with authorized 1731 ANCP peers. 1733 R-78 The NAS must support the capability to simultaneously run ANCP 1734 with multiple ANs in a network. 1736 R-79 The NAS must be able to establish an Access Node Control 1737 Adjacency to a particular partition on an AN and control the 1738 access loops belonging to such a partition. 1740 R-80 The NAS must support obtaining access loop information (e.g. 1741 net data rate), from its peer Access Node partitions via the 1742 Access Node Control Mechanism. 1744 R-81 The NAS must support shaping traffic directed towards a 1745 particular access loop to not exceed the net data rate learnt 1746 from the AN via the Access Node Control Mechanism. 1748 R-82 The NAS should support reducing or disabling the shaping limit 1749 used in the Hierarchical Scheduling process, according to per- 1750 subscriber authorization data retrieved from a AAA or Policy 1751 Server. 1753 R-83 The NAS must support reporting of access loop attributes 1754 learned via the Access Node Control Mechanism to a Policy or 1755 AAA Server using RADIUS VSAs. 1757 R-84 In a TR-059/TR-101 network architecture, the NAS shapes traffic 1758 sent to a particular Access Port according to the bitrate 1759 available on that port. The NAS should take into account the 1760 layer-1 and layer-2 encapsulation overhead on the Access Port, 1761 retrieved from the AN via the Access Node Control Mechanism. 1763 R-85 The NAS should support dynamically configuring and re- 1764 configuring discrete service parameters for access loops that 1765 are controlled by the NAS. The configurable service parameters 1766 for access loops could be driven by local configuration on the 1767 NAS or by a Policy Server. 1769 R-86 The NAS should support triggering an AN via the Access Node 1770 Control Mechanism to execute local OAM procedures on an access 1771 loop that is controlled by the NAS. If the NAS supports this 1772 capability, then the following applies: 1774 * The NAS must identify the access loop on which OAM 1775 procedures need to be executed by specifying an Access 1776 Circuit Identifier (ACI) in the request message to the AN; 1778 * The NAS should support processing and reporting of the 1779 remote OAM results learned via the Access Node Control 1780 Mechanism. 1782 * As part of the parameters conveyed within the OAM message to 1783 the AN, the NAS should send the list of test parameters 1784 pertinent to the OAM procedure. The AN will then execute 1785 the OAM procedure on the specified access loop according to 1786 the specified parameters. In case no test parameters are 1787 conveyed, the AN and NAS must use default and/or 1788 appropriately computed values. 1790 * After issuing an OAM request, the NAS will consider the 1791 request to have failed if no response is received after a 1792 certain period of time. The timeout value should be either 1793 the one sent within the OAM message to the AN, or the 1794 computed timeout value when no parameter was sent. 1796 The exact set of test parameters mentioned above depends on the 1797 particular OAM procedure executed on the access loop. An 1798 example of a set of test parameters is the number of loopbacks 1799 to be performed on the access loop and the timeout value for 1800 the overall test. In this case, and assuming an ATM based 1801 access loop, the default value for the timeout parameter would 1802 be equal to the number of F5 loopbacks to be performed, 1803 multiplied by the F5 loopback timeout (i.e. 5 seconds per the 1804 ITU-T I.610 standard). 1806 R-87 The NAS must treat PPP or DHCP session state independently from 1807 any Access Node Control Adjacency state. The NAS must not 1808 bring down the PPP or DHCP sessions just because the Access 1809 Node Control Adjacency goes down. 1811 R-88 The NAS should internally treat Access Node Control traffic in 1812 a timely and scalable fashion. 1814 R-89 The NAS should support protection of Access Node Control 1815 communication to an Access Node in case of line card failure. 1817 4.7.2. Control Channel Attributes 1819 R-90 The NAS must mark Access Node Control Protocol messages as high 1820 priority (e.g. appropriately set DSCP, Ethernet priority bits 1821 or ATM CLP bit) such that the aggregation network between the 1822 NAS and the AN can prioritize the Access Node Control Protocol 1823 messages over user traffic in case of congestion. 1825 4.7.3. Capability Negotiation Failure 1827 R-91 In case the NAS and Access Node cannot agree on a common set of 1828 capabilities, as part of the ANCP capability negotiation 1829 procedure, the NAS must report this to network management. 1831 R-92 The NAS must only commence Access Node Control information 1832 exchange and state synchronization with the AN when there is a 1833 non-empty common set of capabilities with that AN. 1835 4.7.4. Adjacency Status Reporting 1837 R-93 The NAS must support generating an alarm to a management 1838 station upon loss or malfunctioning of the Access Node Control 1839 Adjacency with the Access Node. 1841 4.7.5. Identification 1843 R-94 The NAS must support correlating Access Node Control Protocol 1844 messages pertaining to a given access loop with subscriber 1845 session(s) over that access loop. This correlation must be 1846 achieved by either: 1848 * Matching an Access Circuit Identifier (ACI) inserted by the 1849 AN in Access Node Control Protocol messages with 1850 corresponding ACI value received in subscriber signaling 1851 (e.g. PPPoE and DHCP) messages as inserted by the AN. The 1852 format of ACI is defined in [TR-101]; 1854 * Matching an ACI inserted by the AN in Access Node Control 1855 Protocol messages with an ACI value locally configured for a 1856 static subscriber on the NAS. 1858 4.7.6. Multicast 1860 R-95 The NAS must support using ANCP to configure multicast 1861 conditional access information to Access Ports on an Access 1862 Node, using Black Lists, Grey Lists and White Lists. 1864 R-96 The NAS must support using ANCP to indicate to the AN whether 1865 or not Admission Control is needed for some multicast flows on 1866 a given Access Port and where needed whether or not the Access 1867 Node is authorized to perform Admission Control itself (i.e. 1868 whether or not AN Bandwidth Delegation applies). 1870 R-97 Upon receiving a query from the AN for a request to replicate 1871 a multicast flow to a particular Access Port, and no AN 1872 Bandwidth Delegation is used for that flow, the NAS must be 1873 able to perform the necessary checks (conditional access 1874 and/or admission control) for the new flow. The NAS must 1875 support using ANCP to reply to the AN indicating whether the 1876 request is to be honored or denied. This may involve a 1877 decision taken locally or querying an external system such as 1878 a Policy Server. 1880 R-98 Upon receiving a query from the AN for a request to replicate 1881 a multicast flow to a particular Access Port, and Admission 1882 Control with AN Bandwidth Delegation is used for that flow, 1883 the NAS must be able to perform the conditional access checks 1884 (if needed), and must support using ANCP to delegate a certain 1885 amount of bandwidth to the AN for a given Access Port. 1887 R-99 In case of Admission Control with AN Bandwidth Delegation, 1888 upon receiving a Bandwidth Delegation Request from the AN 1889 requesting to increase the delegated multicast bandwidth on a 1890 given Access Port, the NAS must support using ANCP to send a 1891 Bandwidth Delegation Response indicating the new delegating 1892 multicast bandwidth. 1894 R-100 In case of Admission Control with AN Bandwidth Delegation, the 1895 NAS must support using ANCP to send a request to the AN to 1896 decrease the amount of multicast bandwidth previously 1897 delegated on a given Access Port; the NAS should be able to 1898 specify both the minimum and the preferred amount decrement of 1899 multicast bandwidth requested. 1901 R-101 In case of Admission Control with AN Bandwidth Delegation, 1902 upon receiving an ANCP Bandwidth Release message, the NAS must 1903 be able to update accordingly its view of the multicast 1904 bandwidth delegated to the AN. 1906 R-102 The NAS must support using ANCP to configure the Access Node 1907 with the "maximum number of multicast streams" allowed to be 1908 received concurrently per Access Port. 1910 R-103 The NAS must support using ANCP to incrementally add, remove 1911 and modify individual entries in White, Black and Grey lists. 1913 R-104 The NAS must support using ANCP to indicate to the AN whether 1914 or not multicast accounting is needed for a multicast flow on 1915 a particular Access Port. 1917 R-105 In case multicast accounting is needed for a multicast flow on 1918 a particular Access Port, the NAS should support using ANCP to 1919 indicate to the AN whether or not additional volume accounting 1920 information is required. 1922 R-106 The NAS must support using ANCP to query the AN to obtain 1923 information on what multicast flows are currently replicated 1924 on a given Access Port. 1926 R-107 The NAS must support using ANCP to query the AN to obtain 1927 information on what Access Ports are currently receiving a 1928 given multicast flow. 1930 R-108 The NAS must support using ANCP to query the AN to obtain 1931 information on what multicast flows are currently replicated 1932 on each Access Port. 1934 R-109 When Multicast replication occurs on the AN, the NAS must 1935 support using ANCP to revoke the authorization to replicate a 1936 multicast flow to a particular Access Port. 1938 R-110 The NAS should support using ANCP to indicate to the AN that 1939 replication of a multicast flow is to start or stop on a given 1940 access port of the AN, without having received a corresponding 1941 Admission Request from the AN earlier on. 1943 4.7.7. Message Handling 1945 R-111 The NAS must be designed to allow fast completion of ANCP 1946 operations, in the order of magnitude of tens of milliseconds. 1948 R-112 The NAS should protect its resources from misbehaved Access 1949 Node Control peers by providing a mechanism to dampen 1950 information related to an Access Node partition. 1952 4.7.8. Wholesale Model 1954 Broadband Forum TR-058 [TR-058], Broadband Forum TR-059 [TR-059] and 1955 Broadband Forum TR-101 [TR-101] describe a DSL broadband access 1956 architecture and how it enables wholesaling. In such a model, the 1957 broadband access provider has a wholesale agreement with one or more 1958 service providers. The access provider owns the broadband access 1959 network and manages connectivity to the service providers. This 1960 allows service providers to provide broadband services to retail 1961 customers, whitout having to own the access network infrastructure 1962 itself. 1964 When applying the Access Node Control Mechanism to a wholesale 1965 network architecture, a number of additional requirements apply. 1967 R-113 In case of wholesale access, the network provider's NAS should 1968 support reporting of access loop attributes learned from AN 1969 via the Access Node Control Mechanism (or values derived from 1970 such attributes), to a retail provider's network gateway 1971 owning the corresponding subscriber(s). 1973 R-114 In case of L2TP wholesale, the NAS must support a proxy 1974 architecture that gives different providers conditional access 1975 to dedicated Access Node Control resources on an Access Node. 1977 R-115 The NAS when acting as an L2TP Access Concentrator (LAC) must 1978 communicate generic access line related information to the LNS 1979 in a timely fashion. 1981 R-116 The NAS when acting as a LAC may asynchronously notify the LNS 1982 of updates to generic access line related information. 1984 5. Management Related Requirements 1986 This section lists the management related requirements for the AN and 1987 NAS. Note that this document does not intend to impose absolute 1988 requirements on network elements. Therefore, the words "must" and 1989 "should" used in this section are not capitalized. 1991 R-117 It must be possible to configure the following parameters on 1992 the Access Node and the NAS: 1994 * Parameters related to the Control Channel transport method: 1995 these include the VPI/VCI and transport characteristics 1996 (e.g. VBR-rt or CBR) for ATM networks or the C-VLAN ID and 1997 S-VLAN ID and p-bit marking for Ethernet networks; 1999 * Parameters related to the Control Channel itself: these 2000 include the IP address of the IP interface on the Access 2001 Node and the NAS 2003 R-118 When the operational status of the Control Channel is changed 2004 (up>down, down>up) a linkdown/linkup trap should be sent 2005 towards the EMS. This requirement applies to both the AN and 2006 the NAS. 2008 R-119 The Access Node must provide the possibility using SNMP to 2009 associate individual DSL lines with specific Access Node 2010 Control Adjacencies. 2012 R-120 The Access Node must notify the EMS of configuration changes 2013 made by the NAS on the AN using ANCP, in a timely manner. 2015 R-121 The Access Node must provide a mechanism that allows the 2016 concurrent access on the same resource from several managers 2017 (EMS via SNMP, NAS via ANCP). Only one manager may perform a 2018 change at a certain time. 2020 R-122 The ANCP may provide a notification mechanism to inform the 2021 NAS about configuration changes done by an EMS, in a timely 2022 manner. This applies only to changes of parameters which are 2023 part of the Use Case Access Loop Configuration. 2025 6. Security Considerations 2027 [draft-ietf-ancp-security-threats] lists the ANCP related security 2028 threats that could be encountered on the Access Node and the NAS. It 2029 develops a threat model and identifies requirements for ANCP 2030 security, aiming to decide which security functions are required at 2031 the ANCP level. 2033 With Multicast handling as described in this document, ANCP protocol 2034 activity between the AN and the NAS is triggered by join/leave 2035 requests coming from the end-user equipment. This could potentially 2036 be used for denial of service attack against the AN and/or the NAS. 2038 This is not a new class of risk over already possible IGMP messages 2039 sent from subscribers to the NAS when the AN uses no IGMP snooping, 2040 and thus is transparent as long as processing of ANCP messages on the 2041 NAS/AN is comparable efficient and protected against congestion. 2043 To mitigate this risk, the AN MAY implement control plane protection 2044 mechanisms such as limiting the number of multicast flows a given 2045 user can simultaneously join, or limiting the maximum rate of join/ 2046 leave from a given user. 2048 We also observe that an operator can easily deploy some protection 2049 against attacks using invalid multicast flows by taking advantage of 2050 the mask-based match in the Black List. This way, joins for invalid 2051 multicast flows can be denied at the AN level without any ANCP 2052 protocol interactions and without NAS involvement. 2054 R-123 The ANCP MUST comply to the security requirements spelled out 2055 in draft-ietf-ancp-security-threats. 2057 R-124 The Access Node MUST NOT allow the sending of Access Node 2058 Control Messages towards the customer premises. 2060 7. IANA Considerations 2062 This document has no actions for IANA. 2064 8. Acknowledgements 2066 The authors would like to thank everyone that has provided comments 2067 or input to this document. In particular, the authors acknowledge 2068 the work done by the contributors to the Broadband Forum related 2069 activities: Jerome Moisand, Wojciech Dec, Peter Arberg and Ole 2070 Helleberg Andersen. The authors also acknowledge the inputs provided 2071 by Roberta Maglione, Angelo Garofalo, Francois Le Faucheur and 2072 Toerless Eckert regarding multicast. Finally, the authors thank 2073 Bharat Joshi, Stefaan De Cnodder, Kirubaharan Dorairaj, Markus 2074 Freudenberger, Fortune Huang and Lothar Reith for providing comments. 2076 9. References 2078 9.1. Normative References 2080 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2081 Requirement Levels", RFC 2119, March 1997. 2083 [RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation 2084 over ATM Adaptation Layer 5", RFC 2684, September 1999. 2086 [RFC894] Hornig, C., "A Standard for the Transmission of IP 2087 Datagrams over Ethernet Networks", RFC 894, April 1984. 2089 [TR-101] Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSL 2090 Aggregation", Broadband Forum TR-101, May 2006. 2092 [draft-ietf-ancp-security-threats] 2093 Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security 2094 Threats and Security Requirements for the Access Node 2095 Control Protocol (ANCP)", 2096 IETF draft-ietf-ancp-security-threats-06.txt, 2097 October 2008. 2099 9.2. Informative References 2101 [G.993.2] ITU-T, "Very high speed digital subscriber line 2102 transceivers 2 (VDSL2)", ITU-T Rec. G.993.2, Feb 2006. 2104 [G.997.1] ITU-T, "Physical layer management for digital subscriber 2105 line (DSL) transceivers", ITU-T Rec. G.997.1, Sep 2005. 2107 [RFC2225] Laubach, M. and J. Halpern, "Classical IP and ARP over 2108 ATM", RFC 2225, April 1998. 2110 [RFC2364] Gross, G., Kaycee, M., Lin, A., Malis, A., and J. 2111 Stephens, "PPP Over AAL5", RFC 2364, July 1998. 2113 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., 2114 and R. Wheeler, "A Method for Transmitting PPP Over 2115 Ethernet (PPPoE)", RFC 2516, February 1999. 2117 [RFC2881] Mitton, D. and M. Beadles, "Network Access Server 2118 Requirements Next Generation (NASREQNG) NAS Model", 2119 RFC 2881, Jul 2000. 2121 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 2122 Thyagarajan, "Internet Group Management Protocol, Version 2123 3", RFC 3376, October 2002. 2125 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 2126 IP", RFC 4607, August 2006. 2128 [TR-058] Elias, M. and S. Ooghe, "Multi-Service Architecture & 2129 Framework Requirements", Broadband Forum TR-058, 2130 September 2003. 2132 [TR-059] Anschutz, T., "DSL Evolution - Architecture Requirements 2133 for the Support of QoS-Enabled IP Services", Broadband 2134 Forum TR-059, September 2003. 2136 [TR-147] Voigt, N., Ooghe, S., and M. Platnic, "Layer 2 Control 2137 Mechanism For Broadband Multi-Service Architectures", 2138 Broadband Forum TR-147, November 2008. 2140 Authors' Addresses 2142 Sven Ooghe 2143 Alcatel-Lucent 2144 Copernicuslaan 50 2145 B-2018 Antwerpen 2146 Belgium 2148 Phone: +32 3 240 42 26 2149 Email: sven.ooghe@alcatel-lucent.com 2151 Norbert Voigt 2152 Nokia Siemens Networks 2153 Siemensallee 1 2154 17489 Greifswald 2155 Germany 2157 Phone: +49 3834 555 771 2158 Email: norbert.voigt@nsn.com 2160 Michel Platnic 2161 ECI Telecom 2162 30 Hasivim Street 2163 49517 Petakh Tikva 2164 Israel 2166 Phone: + 972 54 33 81 567 2167 Email: mplatnic@gmail.com 2169 Thomas Haag 2170 Deutsche Telekom 2171 Heinrich-Hertz-Strasse 3-7 2172 64295 Darmstadt 2173 Germany 2175 Phone: +49 6151 628 2088 2176 Email: haagt@telekom.de 2177 Sanjay Wadhwa 2178 Juniper Networks 2179 10 Technology Park Drive 2180 Westford, MA 01886 2181 US 2183 Phone: 2184 Email: swadhwa@juniper.net