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