idnits 2.17.1 draft-ietf-ancp-mc-extensions-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (Using the creation date from RFC6320, updated by this document, for RFC5378 checks: 2007-03-06) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 21, 2014) is 3709 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'PIMreg' -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANCP F. Le Faucheur 3 Internet-Draft Cisco 4 Updates: 6320 (if approved) R. Maglione 5 Intended status: Standards Track Cisco Systems 6 Expires: August 25, 2014 T. Taylor 7 Huawei 8 February 21, 2014 10 Multicast Control Extensions for ANCP 11 draft-ietf-ancp-mc-extensions-15.txt 13 Abstract 15 This document specifies the extensions to the Access Node Control 16 Protocol required for support of the multicast use cases defined in 17 the Access Node Control Protocol framework document and one 18 additional use case described in this document. These use cases are 19 organized into the following ANCP capabilities: 21 o NAS-initiated multicast replication; 23 o conditional access and admission control with white and black 24 lists; 26 o conditional access and admission control with grey lists; 28 o bandwidth delegation; 30 o committed bandwidth reporting. 32 These capabilities may be combined according to the rules given in 33 this specification. 35 This document updates RFC 6320 by assigning capability type 3 to a 36 capability specified in this document and by changing the starting 37 point for IANA allocation of result codes determined by IETF 38 Consensus from 0x100 to 0x64. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on August 25, 2014. 57 Copyright Notice 59 Copyright (c) 2014 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 75 1.1. A Note On Scope . . . . . . . . . . . . . . . . . . . . . 6 76 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 3. Multicast Use Cases . . . . . . . . . . . . . . . . . . . . . 7 78 3.1. NAS Initiated Multicast Replication Control Use Case . . 8 79 3.1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 8 80 3.1.2. Message Flow . . . . . . . . . . . . . . . . . . . . 8 81 3.2. Conditional Access and Admission Control Use Case . . . . 9 82 3.2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 9 83 3.2.2. Message Flow . . . . . . . . . . . . . . . . . . . . 10 84 3.3. Multicast Flow Reporting Use Case . . . . . . . . . . . . 11 85 3.3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 12 86 3.3.2. Message Flow . . . . . . . . . . . . . . . . . . . . 12 87 3.4. Committed Bandwidth Reporting Use Case . . . . . . . . . 12 88 3.4.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 12 89 3.4.2. Message Flow . . . . . . . . . . . . . . . . . . . . 13 90 4. ANCP Messages . . . . . . . . . . . . . . . . . . . . . . . . 14 91 4.1. Provisioning Message . . . . . . . . . . . . . . . . . . 14 92 4.1.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 15 93 4.1.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 15 94 4.2. Port Management Message . . . . . . . . . . . . . . . . . 16 95 4.2.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 17 96 4.2.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 17 97 4.3. Multicast Replication Control Message . . . . . . . . . . 18 98 4.3.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 21 99 4.3.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 22 100 4.4. Multicast Admission Control Message . . . . . . . . . . . 24 101 4.4.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 25 102 4.4.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 27 103 4.5. Bandwidth Reallocation Request Message . . . . . . . . . 28 104 4.5.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 28 105 4.5.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 29 106 4.6. Bandwidth Transfer Message . . . . . . . . . . . . . . . 32 107 4.6.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 32 108 4.6.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 33 109 4.7. Delegated Bandwidth Query Request Message . . . . . . . . 34 110 4.7.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 34 111 4.7.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 34 112 4.8. Delegated Bandwidth Query Response Message . . . . . . . 35 113 4.8.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 35 114 4.8.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 35 115 4.9. Multicast Flow Query Request and Response Messages . . . 36 116 4.9.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 36 117 4.9.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 37 118 4.10. Committed Bandwidth Report Message . . . . . . . . . . . 38 119 4.10.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 39 120 4.10.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 39 121 5. ANCP TLVs For Multicast . . . . . . . . . . . . . . . . . . . 39 122 5.1. Multicast-Service-Profile TLV . . . . . . . . . . . . . . 39 123 5.2. Multicast-Service-Profile-Name TLV . . . . . . . . . . . 41 124 5.3. List-Action TLV . . . . . . . . . . . . . . . . . . . . . 41 125 5.4. Sequence-Number TLV . . . . . . . . . . . . . . . . . . . 44 126 5.5. Bandwidth-Allocation TLV . . . . . . . . . . . . . . . . 44 127 5.6. White-List-CAC TLV . . . . . . . . . . . . . . . . . . . 45 128 5.7. MRepCtl-CAC TLV . . . . . . . . . . . . . . . . . . . . . 45 129 5.8. Bandwidth-Request TLV . . . . . . . . . . . . . . . . . . 46 130 5.9. Request-Source-IP TLV . . . . . . . . . . . . . . . . . . 47 131 5.10. Request-Source-MAC TLV . . . . . . . . . . . . . . . . . 47 132 5.11. Request-Source-Device-Id TLV . . . . . . . . . . . . . . 48 133 5.12. Multicast-Flow TLV . . . . . . . . . . . . . . . . . . . 49 134 5.13. Report-Buffering-Time TLV . . . . . . . . . . . . . . . . 50 135 5.14. Committed-Bandwidth TLV . . . . . . . . . . . . . . . . . 50 136 6. Multicast Capabilities . . . . . . . . . . . . . . . . . . . 51 137 6.1. Required Protocol Support . . . . . . . . . . . . . . . . 52 138 6.1.1. Protocol Requirements For NAS-Initiated Replication . 52 139 6.1.2. Protocol Requirements For Committed Multicast 140 Bandwidth Reporting . . . . . . . . . . . . . . . . . 53 141 6.1.3. Protocol Requirements For Conditional Access and 142 Admission Control With White and Black Lists . . . . 54 143 6.1.4. Protocol Requirements For Conditional Access and 144 Admission Control With Grey Lists . . . . . . . . . . 55 145 6.1.5. Protocol Requirements For Delegated Bandwidth . . . . 56 147 6.2. Capability-Specific Procedures for Providing Multicast 148 Service . . . . . . . . . . . . . . . . . . . . . . . . . 57 149 6.2.1. Procedures For NAS-Initiated Replication . . . . . . 57 150 6.2.2. Procedures For Committed Bandwidth Reporting . . . . 58 151 6.2.3. Procedures For Conditional Access and Admission 152 Control With Black and White Lists . . . . . . . . . 59 153 6.2.4. Procedures For Conditional Access and Admission 154 Control With Grey Lists . . . . . . . . . . . . . . 61 155 6.2.5. Procedures For Delegated Bandwidth . . . . . . . . . 62 156 6.3. Combinations of Multicast Capabilities . . . . . . . . . 63 157 6.3.1. Combination of Conditional Access and Admission 158 Control With White and Black Lists and Conditional 159 Access and Admission Control With Grey Lists . . . . 63 160 6.3.2. Combination of Conditional Access and Admission 161 Control With Delegated Bandwidth . . . . . . . . . . 65 162 6.3.3. Combination of NAS-Initiated Replication with Other 163 Capabilities . . . . . . . . . . . . . . . . . . . . 65 164 6.3.4. Combinations of Committed Bandwidth Reporting with 165 Other Multicast Capabilities . . . . . . . . . . . . 65 166 7. Miscellaneous Considerations . . . . . . . . . . . . . . . . 66 167 7.1. Report Buffering Considerations . . . . . . . . . . . . . 66 168 7.2. Congestion Considerations . . . . . . . . . . . . . . . . 67 169 8. Security Considerations . . . . . . . . . . . . . . . . . . . 67 170 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 68 171 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 72 172 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 73 173 11.1. Normative References . . . . . . . . . . . . . . . . . . 73 174 11.2. Informative References . . . . . . . . . . . . . . . . . 73 175 Appendix A. Example of Messages and Message Flows . . . . . . . 74 176 A.1. Provisioning Phase . . . . . . . . . . . . . . . . . . . 75 177 A.2. Handling a Grey-Listed Flow . . . . . . . . . . . . . . . 81 178 A.3. Handling White-Listed Flows . . . . . . . . . . . . . . . 86 179 A.4. Handling Of Black-Listed Join Requests . . . . . . . . . 91 180 A.5. Handling Of Requests To Join and Leave the On-Line Game . 91 181 A.6. Example Flow For Multicast Flow Reporting . . . . . . . . 94 182 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 97 184 1. Introduction 186 [RFC5851] defines a framework and requirements for an Access Node 187 control mechanism between a Network Access Server (NAS) and an Access 188 Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)) in a 189 multi-service reference architecture in order to perform QoS-related, 190 service-related and subscriber-related operations. [RFC6320] 191 specifies a protocol for Access Node Control in broadband networks in 192 line with this framework. 194 [RFC6320] supports three use cases defined in [RFC5851], specifically 195 for DSL access: the DSL Topology Discovery use case, the DSL Line 196 Configuration use case and the DSL Remote Connectivity Test use case. 197 However, it does not support the multicast use cases defined in 198 [RFC5851]. The present document specifies the extensions to the 199 Access Node Control Protocol required for support of these multicast 200 use cases. In addition, it supports the Committed Bandwidth 201 Reporting use case, described below. In terms of the ANCP protocol, 202 these use cases are organized into five capabilities: 204 o NAS-initiated multicast replication; 206 o conditional access and admission control with white and black 207 lists; 209 o conditional access and admission control with grey lists; 211 o bandwidth delegation; 213 o committed bandwidth reporting. 215 NAS-initiated multicast replication assumes that multicast "join" and 216 "leave" requests are terminated on the NAS, or that the NAS receives 217 requests to establish multicast sessions through other means (e.g., 218 application-level signalling). The NAS sends commands to the AN to 219 start or stop replication of specific multicast flows on specific 220 subscriber ports. This use case is described briefly in the next-to- 221 last paragraph of Section 3.4 of [RFC5851]. 223 Conditional access is described in Section 3.4.1 of [RFC5851]. 224 Section 3.4.2.2 mentions a way in which conditional access can be 225 combined with admission control to allow best effort multicast flows. 226 Section 3.4.2.3 points out the necessary conditions for using both 227 conditional access and admission control. 229 In the case of "conditional access and admission control with white 230 and black lists", multicast join and leave requests are terminated at 231 the AN and accepted or ignored in accordance with the direction 232 provided by white and black lists respectively. The white and black 233 lists are provisioned per port at startup time and may be modified 234 thereafter. The NAS may combine conditional access with admission 235 control of white-listed flows by appropriate provisioning. 237 Conditional access and admission control with grey lists is similar 238 to conditional access and admission control with white lists, except 239 that before accepting any request matching a grey list entry, the AN 240 sends a request to the NAS for permission to replicate the flow. 242 Again, the NAS can enable admission control of grey-listed flows at 243 the AN. 245 Bandwidth delegation is described in Section 3.4.2.1 of [RFC5851]. 246 It allows flexible sharing of total video bandwidth on an access line 247 between the AN and the NAS. One application of such bandwidth 248 sharing is where the AN does multicast admission control, while the 249 NAS or Policy Server does unicast admission control. In that case, 250 bandwidth delegation allows dynamic sharing of bandwidth between 251 unicast and multicast video traffic on each access line. 253 Committed bandwidth reporting is described below, in Section 3.4. 254 The AN reports the amount of multicast bandwidth it has granted to a 255 given access line each time that value changes. These reports may be 256 buffered for a NAS-provisionable interval so that reports for 257 multiple access lines can be bundled into the same message. 259 The formal specification of the behaviours associated with each of 260 these capabilities, singly and in combination, is given in Section 6. 262 In addition to the multicast service processing behaviour just 263 sketched, the definition of each capability includes support for the 264 multicast accounting and reporting services described in 265 Section 3.4.3 of [RFC5851]. Because of this common content and 266 because of other protocol overlaps between the different 267 capabilities, the protocol descriptions for the multicast extensions 268 specified in this document are merged into a single non-redundant 269 narrative. Tables in Section 6 then indicate the specific sub- 270 sections of the protocol description that have to be implemented to 271 support each capability. 273 This document updates RFC 6320 by assigning capability type 3 to the 274 NAS-initiated multicast replication capability and by changing the 275 starting point for IANA allocation of result codes determined by IETF 276 Consensus from 0x100 to 0x64. 278 1.1. A Note On Scope 280 The requirements in [RFC5851] were formulated with the IPTV 281 application in mind. Two basic assumptions underlie the use case 282 descriptions: 284 o that the Home Gateway operates in bridged mode, and 286 o that multicast signalling uses IGMP ([RFC2236] or [RFC3376]) or 287 MLD [RFC3810] rather than PIM [RFC4601]. 289 Without the first assumption the AN may lose sight of individual 290 subscriber devices making requests for multicast service. This has a 291 very minor effect on the capabilities described below, but prevents 292 the application of per-device policies at the NAS. Changing the 293 second assumption would require that, in applications where the AN is 294 responsible for snooping IGMP and MLD, it now also monitor for PIM 295 signalling. The capabilities described in the present document do 296 not depend explicitly on what type of multicast signalling is used, 297 but the multiple phases of PIM setup could add complexity to their 298 implementation. 300 2. Terminology 302 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 303 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 304 document are to be interpreted as described in [RFC2119]. 306 This document reuses the terms "connection admission control" ("CAC" 307 or simply "admission control") and "conditional access" as they are 308 used in [RFC5851]. 310 The expression "delegated bandwidth" is used as a shorter way of 311 saying: "the total amount of video bandwidth delegated to the AN for 312 multicast admission control". 314 3. Multicast Use Cases 316 Quoting from [RFC5851]: 318 "... the Access Node, aggregation node(s) and the NAS must all be 319 involved in the multicast replication process. This avoids that 320 several copies of the same stream are sent within the access/ 321 aggregation network. In case of an Ethernet-based access/aggregation 322 network, this may, for example, be achieved by means of IGMP snooping 323 or IGMP proxy in the Access Node and aggregation node(s). By 324 introducing IGMP processing in the access/aggregation nodes, the 325 multicast replication process is now divided between the NAS, the 326 aggregation node(s) and Access Nodes. In order to ensure backward 327 compatibility with the ATM-based model, the NAS, aggregation node and 328 Access Node need to behave as a single logical device. This logical 329 device must have exactly the same functionality as the NAS in the ATM 330 access/aggregation network. The Access Node Control Mechanism can be 331 used to make sure that this logical/functional equivalence is 332 achieved by exchanging the necessary information between the Access 333 Node and the NAS." 335 [RFC5851] describes the use cases for ANCP associated with such 336 multicast operations, and identifies the associated ANCP 337 requirements. The present section describes a subset of these use 338 cases as background to facilitate reading of this document, but the 339 reader is referred to [RFC5851] for a more exhaustive description of 340 the ANCP multicast use cases. Detailed example message flows can 341 also be found in Appendix A. 343 In the diagrams below, participation of the Home Gateway is optional, 344 depending on whether it is operating in bridged or routed mode. Note 345 that devices behind the Home Gateway may require the Home Gateway to 346 operate in routed mode to ensure that they can obtain access to non- 347 IPTV multicast services. 349 3.1. NAS Initiated Multicast Replication Control Use Case 351 3.1.1. Goals 353 One option for multicast handling is for the subscriber to 354 communicate the "join/leave" information to the NAS. This can be 355 done for instance by terminating all subscriber IGMP ([RFC3376]) or 356 MLD ([RFC2710], [RFC3810]) signaling on the NAS. Another example 357 could be a subscriber using some form of application level signaling, 358 which is redirected to the NAS. In any case, this option is 359 transparent to the access and aggregation network. In this scenario, 360 the NAS uses ANCP to create and remove replication state in the AN 361 for efficient multicast replication. Thus, the NAS only sends a 362 single copy of the multicast stream towards the AN, which in turn 363 performs replication to multiple subscribers as instructed by the NAS 364 via ANCP. The NAS performs conditional access and admission control 365 when processing multicast join requests, and only creates replication 366 state in the AN if admission succeeds. 368 3.1.2. Message Flow 370 With the NAS-initiated use case, a Multicast Replication Control 371 Message is sent by the NAS to the AN with a directive to either join 372 or leave one (or more) multicast flow(s). In the example message 373 flow, the AN uses a Generic Response message to convey the outcome of 374 the directive. Figure 1 illustrates such an ANCP message exchange as 375 well as the associated AN behavior. 377 +----------+ +-------+ +-----+ ANCP +-----+ 379 |Subscriber| | Home | | AN |<-------------------->| NAS | 380 +----------+ |Gateway| +-----+ +-----+ 381 | +-------+ | | 383 | | | (*) 384 | | | Multicast-Replication-Ctl | 385 | | | (Target, add, Flow 1) | 386 | | |<--------------------------| 387 | Mcast Flow 1 | | 388 |<===========+==============+ | 389 | | | Generic Response | 390 | | |-------------------------->| 391 | | | | 392 | | | | 393 ~ ~ ~ ~ 394 | | | | 395 | | | Multicast-Replication-Ctl | 396 | | | (Target,delete, Flow 1) | 397 | | |<--------------------------| 398 | | | | 399 | | Generic Response | 401 | | |-------------------------->| 403 (*) The NAS may optionally seek direction from an external 404 Authorization/Policy Server before admitting the flow. 406 Figure 1: NAS Initiated Multicast Replication Control 408 3.2. Conditional Access and Admission Control Use Case 410 3.2.1. Goals 412 One option for multicast handling is for the access/aggregation nodes 413 to participate in IGMP/MLD processing (e.g. via IGMP/MLD snooping). 414 In this scenario, on detecting a join/leave request from an end user 415 for a multicast flow (in the grey list), the AN uses ANCP to request 416 a conditional access and admission control decision from the NAS. In 417 turn, after conditional access and admission control checks, the NAS 418 uses ANCP to instruct the AN to change the replication states 419 accordingly. 421 3.2.2. Message Flow 423 For support of the conditional access and admission control use case, 424 on detection of an IGMP/MLD Join, the AN sends an Admission Control 425 message to the NAS to request a conditional access and admission 426 control check. In the case of a positive outcome, the NAS sends a 427 Multicast Replication Control Message to the AN with a directive to 428 replicate the multicast flow to the corresponding user. Similarly on 429 detection of an IGMP/MLD leave, an Admission Control message is sent 430 by the AN to the NAS to keep the NAS aware of user departure for the 431 flow. This message flow is illustrated in Figure 2. 433 +----------+ +-------+ +-----+ ANCP +-----+ 435 |Subscriber| | Home | | AN |<------------------->| NAS | 436 +----------+ |Gateway| +-----+ +-----+ 437 | +-------+ | | 438 | | | | 440 | Join(Gr-Flow1) | Admission-Control | 442 |------------+---------->| (Target,add,Gr-Flow1) | 444 | | |-------------------------->| 446 | | | (*) 447 | | | Multicast-Replication-Crl | 448 | | | (Target,add,Gr-Flow1) | 449 | | |<--------------------------| 450 | Mcast Gr-Flow1 | | 451 |<===========+===========+ | 453 | | | | 454 ~ ~ ~ ~ 455 | | | | 456 | Leave(Gr-Flow1) | Admission-Control | 458 |------------+---------->| (Target,delete,Gr-Flow1) | 460 | | |-------------------------->| 462 | | | 464 | | | | 466 Gr-Flow1: a multicast flow matching the grey list for that port 468 (*) The NAS may optionally seek direction from an external 469 Authorization/Policy Server before admitting the flow. 471 Figure 2: Multicast Conditional Access and Admission Control 473 3.3. Multicast Flow Reporting Use Case 474 3.3.1. Goals 476 The Multicast flow reporting use case allows the NAS to 477 asynchronously query the AN to obtain an instantaneous status report 478 related to multicast flows currently replicated by the AN. 480 3.3.2. Message Flow 482 The NAS sends a Multicast Flow Query Request message to the AN in 483 order to query the AN about information such as which multicast flows 484 are currently active on a given AN port or which ports are currently 485 replicating a given multicast flow. The AN conveys the requested 486 information to the NAS in a Multicast Flow Query Response message. 487 This message flow is illustrated in Figure 3. 489 +----------+ +-------+ +-----+ ANCP +-----+ 490 |Subscriber| | Home | | AN |<---------->| NAS | 491 +----------+ |Gateway| +-----+ +-----+ 492 | +-------+ | | 493 | | | Multicast Flow | 494 | | | Query Request | 495 | | |<------------------| 496 | | | | 497 | | | Multicast Flow | 498 | | | Query Response | 499 | | |------------------>| 500 | | | | 501 | | | | 503 Figure 3: Multicast Flow Reporting 505 3.4. Committed Bandwidth Reporting Use Case 507 3.4.1. Goals 509 The committed bandwidth reporting use case allows the NAS to maintain 510 current awareness of how much multicast bandwidth the AN has 511 committed to a given access line, so that the NAS can adjust its 512 forwarding scheduler to ensure the associated QoS. Note that this 513 involves a finer level of detail than provided by bandwidth 514 delegation, since the amount of delegated bandwidth is an upper limit 515 on the amount of bandwidth committed rather than an actual value. To 516 reduce the volume of messaging, reports from the AN may be buffered 517 so that one message reports on changes for multiple access lines. 519 3.4.2. Message Flow 521 The message flow associated with this use case is shown in Figure 4. 522 The figure assumes that a non-zero buffering interval was previously 523 provisioned on the AN. 525 +-----+ +-------+ +-----+ ANCP +-----+ 526 |Subs |+ | Home |+ | AN |<---------->| NAS | 527 |1,2 || |GW 1,2 || +-----+ +-----+ 528 +-----+| +-------+| | | 529 +|----+ +|------+ | | 530 | | | | | | 531 | |Join(Subs1, Ch1) | | 532 |----------+--------------->| Start buffering | 533 | | | Multicast flow | timer. Create | 534 |<======+===================| message with | 535 | | | | | initial contents | 536 | | | | | reporting new | 537 | | | | | Subs1 bandwidth. | 538 | | Join(Subs2, Ch2) | | 539 | |----------+------------->| Add report for | 540 | | | Multicast flow | new Subs2 b/w. | 541 | |<======+=================| | 542 | | | | | | 543 | |Leave(Subs1, Ch1) | | 544 |----------+--------------->| Replace report | 545 | | | | | for Subs1 with | 546 | | Stop replication X new value (which | 547 | | | | | happens to be | 548 | | | | | the same as the | 549 | | | | | starting value. | 550 | | | | | | 551 | | | | >|< TIMER expires | 552 | | | | | | 553 | | | | |Committed | 554 | | | | | Bandwidth Report | 555 | | | | |------------------>| 556 | | | | | (for latest | 557 | | | | | Subs1 and Subs2 | 558 | | | | | bandwidth) | 559 | | | | | | 561 Figure 4: Message Flow For Committed Bandwidth Reporting 563 4. ANCP Messages 565 This section defines new ANCP messages and new usage of existing ANCP 566 messages as well as procedures associated with the use of these 567 messages. 569 Unless stated otherwise, receivers MUST ignore message contents that 570 are not supported by the set of capabilities negotiated between the 571 NAS and the Access Node. 573 4.1. Provisioning Message 575 Section 4.1 of [RFC6320] defines the Provisioning message that is 576 sent by the NAS to the AN to provision information in the AN. 578 The present document specifies that the Provisioning message MAY be 579 used by the NAS to provision multicast-related information (e.g., 580 multicast service profiles). The ANCP Provisioning message payload 581 MAY contain: 583 o one or more instances of the Multicast-Service-Profile TLV. The 584 Multicast-Service-Profile TLV is defined in the present document 585 in Section 5.1. Each instance of the Multicast-Service-Profile 586 TLV contains a multicast service profile name and one or more list 587 actions. A list action consists of an action (add, delete, 588 replace), a list type (white, black, or grey), and list content 589 (multicast source and group addresses). 591 o an instance of the White-List-CAC TLV. The White-List-CAC TLV is 592 defined in Section 5.6. If present, this TLV indicates that the 593 AN is required to do admission control before replicating white- 594 listed flows. 596 o an instance of the MRepCtl-CAC TLV. The MRepCtl-CAC TLV is 597 defined in Section 5.7. If present, this TLV indicates that the 598 AN is required to do admission control before replicating flows 599 specified in Multicast Replication Control messages. 601 o an instance of the Report-Buffering-Time TLV. The Report- 602 Buffering- Time TLV is defined in Section 5.13. If present, this 603 TLV indicates Committed Bandwidth Report messages should be 604 buffered for the amount of time given by the TLV before being 605 transmitted to the NAS. 607 See Section 6 for information on which multicast capabilities require 608 support of these TLVs in the Provisioning message. 610 4.1.1. Sender Behaviour 612 When directed by the Policy Server or by management action, the NAS 613 sends the Provisioning message to initially provision or to update 614 the white, black, and/or grey multicast channel lists associated with 615 a set of named multicast service profiles, or to direct the AN to 616 perform admission control for specific classes of flows. 618 To provision or update a multicast service profile, the NAS MUST 619 include within the message one or more instances of the Multicast- 620 Service-Profile TLV specifying the content to be provisioned or 621 updated. The NAS MUST NOT include any list type (white, black, or 622 grey) that is not supported by the set of multicast capabilities 623 negotiated between the NAS and the AN. The NAS MUST NOT use the 624 Provisioning message to send instances of the Multicast-Service- 625 Profile TLV to the AN unless the Multicast-Service-Profile TLV is 626 supported by the set of multicast capabilities negotiated between the 627 NAS and the AN. 629 To require admission control to be performed at the AN on white- 630 listed flows, the NAS MUST include a copy of the White-List-CAC TLV 631 in the Provisioning message. The White-List-CAC TLV MUST NOT be 632 provided unless the negotiated set of capabilities includes 633 conditional access and admission control with white and black lists. 635 To require admission control to be performed at the AN on grey-listed 636 flows or on NAS-initiated flows, the NAS MUST include a copy of the 637 MRepCtl-CAC TLV in the Provisioning message. The MRepCtl-CAC TLV 638 MUST NOT be provided unless the negotiated set of capabilities 639 includes NAS-initiated replication control or conditional access and 640 admission control with grey lists. 642 To require buffering of Committed Bandwidth Report messages so that 643 reports for multiple access lines can be included in the same 644 message, the NAS MUST include a copy of the Report-Buffering-Time TLV 645 containing a non-zero time value in a Provisioning message sent to 646 the AN. The Report-Buffering-Time TLV MUST NOT be provided unless 647 the negotiated set of capabilities includes committed bandwidth 648 reporting. 650 4.1.2. Receiver Behaviour 652 The receiving AN provisions/updates the white, black, and/or grey 653 lists associated with the multicast service profile names contained 654 in the Multicast-Service-Profile TLV instances within the message 655 according to the contents of the associated List-Action TLVs. The AN 656 MUST process List-Action TLVs in the order in which they appear 657 within the message. In keeping with the general rule stated in 658 Section 4, the AN MUST ignore instances of the List-Action TLV 659 referring to any list type (white, black, or grey) that is not 660 supported by the set of multicast capabilities negotiated between the 661 NAS and the AN. 663 When a new multicast service profile is identified by a Multicast- 664 Service-Profile TLV, the initial state of all lists associated with 665 that profile according to the negotiated set of multicast 666 capabilities is empty until changed by the contents of Multicast- 667 Service-Profile TLVs. 669 The receipt of a Provisioning message containing updates to an 670 existing multicast service profile subsequent to startup will cause 671 the AN to review the status of active flows on all ports to which 672 that profile has been assigned. For further details, see Section 6. 674 If the White-List-CAC and/or MRepCtl-CAC TLV is present in the 675 Provisioning message and the respective associated capabilities have 676 been negotiated, the AN prepares (or continues) to do admission 677 control on the indicated class(es) of flow. If one or both of these 678 TLVs was present in an earlier Provisioning message but is absent in 679 the latest message received, the AN ceases to do admission control on 680 the indicated class(es) of flow. 682 The buffering time specified in an instance of the Report-Buffering- 683 Time TLV will not be applied until the current accumulation process 684 of Committed Bandwidth Report messages finishes. 686 As indicated in [RFC6320], the AN MUST NOT reply to the Provisioning 687 message if it processed it successfully. If an error prevents 688 successful processing of the message content, the AN MUST return a 689 Generic Response message as defined in [RFC6320], containing a 690 Status-Info TLV with the appropriate content describing the error. 691 For this purpose, the presence of a list type in a Multicast-Service- 692 Profile TLV which was ignored because it was not supported by the 693 negotiated set of capabilities is not considered to be an error. 695 4.2. Port Management Message 697 As specified in [RFC6320], the NAS may send DSL line configuration 698 information to the AN ("ANCP based DSL Line Configuration" use case) 699 using ANCP Port Management messages. See Section 7.3 of [RFC6320] 700 for the format of the Port Management message in that usage. 702 This document specifies that the Port Management message MAY be used 703 to convey either or both of the following TLVs: 705 o Multicast-Service-Profile-Name TLV (defined in Section 5.2). This 706 TLV associates a Multicast Service Profile with the access line 707 specified by the extension block, and in the case of white and 708 black lists, delegates conditional access to the AN for the 709 specified access line and channels. 711 o Bandwidth-Allocation TLV (defined in Section 5.5). This TLV 712 specifies the total multicast bandwidth available to the AN for 713 admission control at the access line. 715 When the Port Management message is used for this purpose: 717 o the Function field in the Port Management message MUST be set to 718 8, "Configure Connection Service Data". 720 o the message MUST include TLV(s) to identify the access line 721 concerned. If the access line is a DSL loop, the line-identifying 722 TLV(s) MUST be as specified in Section 5.1.2 of [RFC6320]. For 723 non-DSL access lines, the appropriate alternative line-identifying 724 TLV(s) MUST be present. Line configuration data other than the 725 two TLVs listed in the previous paragraph MAY be present. 727 4.2.1. Sender Behaviour 729 The NAS sends the Port Management message at startup time to 730 initialize parameters associated with the access line specified in 731 the message and with the multicast capabilities negotiated between 732 the NAS and the AN. The NAS MAY send additional Port Management 733 messages subsequent to startup, to update or, in the case of the 734 Bandwidth-Allocation TLV, reset these parameters. If the NAS 735 includes a Multicast-Service-Profile-Name TLV in the Port Management 736 message, the name MUST match a profile name provided in a Multicast- 737 Service-Profile TLV in a prior Provisioning message. The NAS MUST 738 NOT include a TLV unless it is supported by the set of multicast 739 capabilities negotiated between the NAS and the AN. See Section 6 740 for further information. 742 4.2.2. Receiver Behaviour 744 If the Port Management message contains a Multicast-Service-Profile- 745 Name TLV, the AN associates the named profile with the specified 746 access line. This association replaces any previous association. 747 That is, a given access line is associated with at most one multicast 748 service profile. The replacement of one multicast service profile 749 with another will cause the AN to review the status of all active 750 flows on the target port. For further details see Section 6. 752 If the Port Management message contains a Bandwidth-Allocation TLV, 753 the AN adopts this as the current value of its total multicast 754 bandwidth limit for the target port. If the AN has already committed 755 multicast bandwidth exceeding the amount given in the Bandwidth- 756 Allocation TLV, the AN SHOULD NOT discontinue any multicast streams 757 in order to bring bandwidth down to within the new limit, unless such 758 action is required by local policy. However, the AN MUST NOT admit 759 new multicast streams that are subject to admission control until it 760 can do so within the limit specified by the Bandwidth-Allocation TLV. 762 If the Port Management request cannot be processed due to error and 763 the Result field of the request is Nack (0x1) or AckAll (0x2), the AN 764 SHOULD add a Status-Info TLV to the Extension Value field in its 765 reply if this will provide useful information beyond what is provided 766 by the Result Code value returned in the response header. In 767 particular, if the name within the Multicast-Service-Profile-Name TLV 768 does not match a profile name given in a prior Provisioning message, 769 the AN SHOULD return a reply where the Result Code field in the 770 header indicates 0x55, "Invalid TLV contents", the Error Message 771 field in the Status-Info TLV contains the text "Multicast profile 772 name not provisioned", and the Status-Info TLV contains a copy of the 773 Multicast-Service-Profile-Name TLV. 775 4.3. Multicast Replication Control Message 777 This section defines a new message called the Multicast Replication 778 Control message. The Multicast Replication Control message is sent 779 by the NAS to the AN with one or more directives to add (join) or 780 delete (leave) a multicast flow on a target object identified in the 781 content of the message. 783 The Message Type for the Multicast Replication Control message is 784 144. 786 The ANCP Multicast Replication Control message payload contains the 787 following TLVs: 789 o Target TLV: The Target TLV is defined in Section 4.3 of [RFC6320]. 790 It MUST appear once and only once. It is encoded as specified in 791 [RFC6320] or extensions and identifies the AN port subject to the 792 request for admission or release. 794 o Command TLV: The Command TLV is defined in Section 4.4 of 795 [RFC6320]. It MUST be present. It MAY appear multiple times. 797 As [RFC6320] indicates, the contents of the Command Info field within 798 the Command TLV are specific to the message in which the TLV occurs. 800 For the Multicast Replication Control Message, these contents consist 801 of: 803 o a Command Code field; 805 o an Accounting field; 807 o an instance of the Multicast-Flow TLV. 809 Figure 5 illustrates the complete Command TLV with the contents 810 specific to the Multicast Replication Control message. 812 1 2 3 813 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | TLV Type = Command 0x0011 | Command TLV Length | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 |Command Code | Accounting | Reserved | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | Multicast-Flow TLV | 820 | ... | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | Other embedded TLV Type | Other embedded TLV Length | 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 | | 825 ~ Other embedded TLV data ~ 826 | | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 Figure 5: Contents of the Command TLV in the Multicast Replication 830 Control Message 832 Command Code: 833 Command directive: 835 1 "Add"; 837 2 "Delete"; 839 3 "Delete All"; 841 4 "Admission Control Reject"; 843 5 "Conditional Access Reject"; 845 6 "Admission Control and Conditional Access Reject". 847 Directives 4 through 6 are used as described in 848 Section 4.4.2. 850 Accounting: 851 Meaningful only when the Command Code is "Add" (1). In 852 that case, 0 indicates flow accounting is disabled, 1 853 indicates that octet accounting for the flow is requested. 854 The sender MUST set the Accounting field to 0 and the 855 receiver MUST ignore the Accounting field for other Command 856 Code values. 858 Reserved: 859 Reserved for future use. MUST be set to zeroes by the 860 sender and ignored by the receiver. 862 Multicast-Flow TLV: 863 An instance of the Multicast-Flow TLV (Section 5.12) 864 specifying the flow to be added or deleted. The Multicast- 865 Flow TLV is omitted if the Command Code has value "Delete 866 All" (3). 868 Other embedded TLV: 869 No other embedded TLVs are currently specified within the 870 Multicast Replication Control message/Command TLV. 871 However, see the description of the Multicast Admission 872 Control message (Section 4.4). Unrecognized embedded TLVs 873 SHOULD be silently discarded. 875 The figure below is an example of a Multicast Replication Control 876 message that would result in a swap from multicast Source-Specific 877 Multicast (SSM) flows 2001:DB8::1, FF34::2, to 2001:DB8::2, FF34::3 878 on the Target identified by the "Access Loop Circuit ID": 880 1 2 3 881 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | Type (0x880C) | Length | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | Version | MsgType=144 | Res=2 | Result Code = 0 | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | Partition ID | Transaction Identifier = 18 | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 |I| SubMessage Number | Length | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | TLV Type = Target 0x1000 | Target TLV Length | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | | 896 ~ Access Loop Circuit ID ~ 897 | | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | TLV Type = Command 0x0011 | Command TLV Length = 44 | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | Cmd Code = 2 | Acctg = 0 | Reserved = 0x0000 | 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | Type = Multicast-Flow 0x0019 | TLV Length = 36 | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | Flow Type = 2 | AddrFam = 2 | Reserved = 0x0000 | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | | 908 ~ Multicast Group Address ~ 909 | = FF34::2 | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | | 912 ~ Source Address ~ 913 | = 2001:DB8::1 | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | TLV Type = Command 0x0011 | Command-TLV Length = 44 | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | Cmd Code = 1 | Acctg = 1 | Reserved = 0x0000 | 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | Type = Multicast-Flow 0x0019 | TLV Length = 36 | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | Flow Type = 2 | AddrFam = 2 | Reserved = 0x0000 | 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 | | 924 ~ Multicast Group Address ~ 925 | = FF34::3 | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | | 928 ~ Source Address ~ 929 | = 2001:DB8::2 | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 4.3.1. Sender Behaviour 934 The NAS MAY issue a Multicast Replication Control message to the AN 935 to convey one or more directives to add (join) or delete (leave) one 936 or more multicast flows. 938 The NAS MAY send this message on its own initiative to support the 939 NAS initiated Multicast Control use case presented in [RFC5851] and 940 summarized in Section 3.1. In that case, the NAS MUST set the Result 941 field to AckAll (0x2) or Nack (0x1) according to its requirements. 943 The NAS MAY also send this message in response to a Multicast 944 Admission Control message (defined in Section 4.4) received from the 945 AN to support the conditional access and admission control use case 946 presented in [RFC5851] and summarized in Section 3.2. In that case, 947 the NAS MUST set the Result field to NAck (0x1). 949 In either case, the sender MUST populate the Result Code field with 950 the value 0 and the ANCP Transaction Identifier field with a unique 951 value, as described in Section 3.6.1.6 of [RFC6320]. 953 Each Multicast Replication Control Message MUST contain one or more 954 commands, each encapsulated in its own Command TLV. The sender MUST 955 use a separate Command TLV for each distinct multicast flow. 957 When the order of processing of two commands does not matter, the 958 commands MUST be transmitted in separate Multicast Replication 959 Control messages. 961 4.3.2. Receiver Behaviour 963 When successive commands (in the same or different messages) relate 964 to the same Target and multicast flow, the state of each feature 965 controlled or affected by attributes received in the Multicast 966 Replication Control message, SHALL be as set by the last command or 967 message referring to that target and flow and containing the 968 controlling attribute. As an example, successive Multicast 969 Replication Control messages containing add commands for a given port 970 and flow but differing only in the Accounting field, update the state 971 of the accounting feature to what is set in the final command 972 received, but all other features are unaffected by the second 973 message. 975 If more than one Command TLV is present in a Multicast Replication 976 Control message, the AN MUST act on the commands in the order in 977 which they are presented in the message. The AN SHALL assign a 978 sequence number to each command in a given Multicast Replication 979 Control message, starting from 1 for the first command. 981 If a Command TLV adds one or more flows and the AN is performing 982 admission control for Multicast Replication Control messages, then 983 the AN MUST perform admission control before replicating the flows. 984 If the admission control check fails, the AN MUST treat the failure 985 as an error as described below. The appropriate Result Code value 986 for the response is 0x13 "Out of resources". 988 If the AN processes the complete Multicast Replication Control 989 message successfully and the Result field of the Multicast 990 Replication Control message was set to AckAll (0x2), the AN MUST 991 respond with a Generic Response message where the Result field is set 992 to Success (0x3), the Result Code field is set to 0, and the 993 Transaction Identifier field is copied from the Multicast Replication 994 Control message. The body of the response MAY be empty or MAY be 995 copied from the Multicast Replication Control message. 997 If the AN processes the complete Multicast Replication Control 998 message successfully and the Result field of the Multicast 999 Replication Control message was set to Nack (0x1), the AN MUST NOT 1000 respond to the message. 1002 The processing/execution of multiple commands contained in a single 1003 Multicast Control message MUST be interrupted at the first error 1004 encountered, and the remaining commands in the Multicast Replication 1005 Control message discarded. Similarly, if a given command specifies 1006 multiple Single-Source Multicast (SSM) flows and a error occurs, 1007 processing MUST be interrupted at that point and the remainder of the 1008 Command TLV discarded. 1010 If the AN detects an error in a received Multicast Replication 1011 Control message and the Result field in that message was set to Nack 1012 (0x1) or AckAll(0x2), the AN MUST generate a Generic Response message 1013 providing error information to the NAS. This specification 1014 identifies the following new Result Code values beyond those 1015 specified in [RFC6320], which MAY be used in a Generic Response sent 1016 in reply to a Multicast Replication Control message: 1018 0x64 Command error. 1020 Where detected: ANCP agent at the AN. 1022 Further description: an invalid command code has been received. 1024 Required additional information in the message: see below. 1026 Target: ANCP agent at the NAS. 1028 Action RECOMMENDED for the receiving ANCP agent: Report the 1029 error to the control application with an indication of the 1030 erroneous information associated with the invalid TLV(s). 1032 0x65 Invalid flow address. 1034 Where detected: ANCP agent at the AN. 1036 Further description: either inconsistent flow address 1037 information has been provided or the address family is 1038 unsupported. 1040 Required additional information in the message: see below. 1042 Target: ANCP agent at the NAS. 1044 Action RECOMMENDED for the receiving ANCP agent: Report the 1045 error to the control application with an indication of the 1046 erroneous information associated with the invalid TLV(s). 1048 0x66 Multicast flow does not exist. 1050 Where detected: control application at the AN. 1052 Further description: the NAS has attempted to delete a flow 1053 that is not active on the given access line. 1055 Required additional information in the message: see below. 1057 Target: control application at the NAS. 1059 Action RECOMMENDED for the receiving ANCP agent: report the 1060 error to the control application with an indication of the 1061 erroneous information associated with the invalid TLV(s). 1063 A Generic Response message responding to the Multicast Replication 1064 Control message and containing one of the above Result Code values 1065 MUST include a Status-Info TLV which includes one or two embedded 1066 TLVs as follows: 1068 o a Sequence-Number TLV as described in Section 5.4, giving the 1069 sequence number of the failed command, MUST be included; 1071 o the failed Command TLV itself SHOULD be included. 1073 Note that the Error Message field of the Status-Info TLV MAY be 1074 used to report more details than implied by the Result Code value 1075 in the message header. For example, the Result Code value could 1076 be 0x65 and the Error Message field could contain the text: 1077 "Source address present for ASM flow". 1079 4.4. Multicast Admission Control Message 1081 This section defines a new message called the Multicast Admission 1082 Control message. The Multicast Admission Control message is sent by 1083 the AN to the NAS to request admission of a multicast flow, or to 1084 notify of the removal of a multicast flow, for a given target. 1086 The Message Type for the Multicast Admission Control message is 145. 1088 The ANCP Multicast Admission Control message payload contains two 1089 TLVs: 1091 o Target TLV: The Target TLV is defined in [RFC6320]. It MUST 1092 appear once and only once in the Multicast Admission Control 1093 message. It is encoded as specified in [RFC6320] or extensions 1094 and identifies the AN port subject to the request for admission or 1095 release. 1097 o Command TLV: The Command TLV is defined in [RFC6320]. It MUST be 1098 present. If it appears more than once, only the first instance is 1099 considered meaningful in the present version of this specification 1100 and the other instances are ignored. 1102 Note: 1104 In the future, the specification of the Admission Control message 1105 may be extended to allow transport of more than a single directive 1106 (e.g., to carry both a leave from one group and a join to another 1107 group for the same Target). It is expected that this would 1108 support a similar notion of strict sequenced processing as 1109 currently defined for handling multiple directives in the 1110 Multicast Replication Control message whereby all directives 1111 following the first directive that cannot be executed are not 1112 executed either. When the strict sequenced processing of the 1113 directives is not required the directives are distributed across 1114 separate messages. 1116 The Command TLV has the same contents as were described above for the 1117 Multicast Replication Control message, with the following additions: 1119 o a Request-Source-IP TLV MAY be appended to the Command TLV as an 1120 additional embedded TLV; 1122 o similarly, a Request-Source-MAC TLV MAY be appended to the Command 1123 TLV as an additional embedded TLV. 1125 o Finally and preferably, a Request-Source-Device-Id TLV MAY be 1126 appended to the Command TLV as an additional embedded TLV. 1128 Note that the Command TLV length includes the length of any embedded 1129 TLVs, including the embedded TLV headers. 1131 4.4.1. Sender Behaviour 1133 The AN sending the Multicast Admission Control message MUST set the 1134 Result field to Ignore (0x0). 1136 The AN MUST populate the ANCP Transaction Identifier field with a 1137 unique value, as described in Section 3.6.1.6 of [RFC6320]. 1139 The AN MUST encode the Command TLV as specified in Section 4.3 with 1140 the following additional rules: 1142 o the Accounting field MUST be set to 0; 1144 o the Command Code field MUST be set to "Add" (1) when the message 1145 conveys a Join , to "Delete" (2) when the message conveys a Leave 1146 and to "Delete All" (3) when the message conveys a Leave of all 1147 channels (on the target); 1149 o The Multicast-Flow TLV within the Command TLV identifies the 1150 multicast flow subject to the request for admission or release. 1151 When the Command Code is 3, the Multicast-Flow TLV is omitted. 1153 o The Request-Source-IP embedded TLV MAY be included by the AN to 1154 convey the IP address of the sender of the join/leave message 1155 (e.g., IGMP/MLD Join/Leave) that triggered the AN to include the 1156 corresponding Command TLV in the Admission Control message. If it 1157 appears more than once, only the first instance is considered 1158 meaningful and the other instances are ignored. 1160 o The Request-Source-MAC embedded TLV MAY be included by the AN to 1161 convey the MAC address of the sender of the join/leave message 1162 (e.g., IGMP/MLD Join/Leave) that triggered the AN to include the 1163 corresponding Command TLV in the Admission Control message. If it 1164 appears more than once, only the first instance is considered 1165 meaningful and the other instances are ignored. 1167 o As a third alternative, the Request-Source-Device-Id embedded TLV 1168 MAY be included by the AN to convey a local identifier of the 1169 sender of the join/leave message (e.g., IGMP/MLD Join/Leave) that 1170 triggered the AN to include the corresponding Command TLV in the 1171 Admission Control message. If it appears more than once, only the 1172 first instance is considered meaningful and the other instances 1173 are ignored. 1175 The inclusion of Request-Source-IP or Request-Source-MAC in the 1176 Multicast Admission Control message is typically done to allow the 1177 application of policies applicable to specific devices within the 1178 customer's network. However, transmission of either of these fields 1179 beyond the AN introduces potential privacy issues. Instead of 1180 transmitting either of these identifiers, it is RECOMMENDED that the 1181 AN map the required identifier to a local value known to the AN and 1182 AAA but not to the NAS, as discussed in Section 8. The local 1183 identifier is transmitted using the Request-Source-Device-Id TLV. 1185 4.4.2. Receiver Behaviour 1187 On receipt of an Multicast Admission Control message, the NAS: 1189 o MUST ignore the Result field; 1191 o if the directive in the Multicast Admission Control message is 1192 "Delete" (2) or "Delete All" (3) and is processed correctly by the 1193 NAS, the NAS MUST NOT generate any ANCP message in response to the 1194 Multicast Admission Control message; 1196 o if the directive in the Multicast Admission Control message is 1197 "Add" (1) and is accepted by the NAS, the NAS MUST generate a 1198 Multicast Replication Control in response to the Multicast 1199 Admission Control message. The Multicast Replication Control 1200 message: 1202 * MUST contain a Result set to Nack (0x1); 1204 * MUST contain a Transaction ID with a unique value, as described 1205 in Section 3.6.1.6 of [RFC6320]; 1207 * MUST contain the directive as accepted by the NAS. The NAS MAY 1208 modify the Accounting field if flow accounting is required. 1210 o if the directive in the Multicast Admission Control message is 1211 "Add" (1) and is processed correctly but not accepted by the NAS 1212 (i.e., it does not pass the conditional access and admission 1213 control check), the NAS MAY generate a Multicast Replication 1214 Control message in response to the Multicast Admission Control 1215 message. This optional message can be used by the AN to maintain 1216 statistics about admission control rejections. When used in this 1217 situation, the Multicast Replication Control message: 1219 * MUST contain a Result set to 0x0; 1221 * MUST contain a Transaction ID with a unique value, as described 1222 in Section 3.6.1.6 of [RFC6320]; 1224 * MUST contain the directive rejected by the NAS (i.e., Target 1225 TLV and Command TLV) but with a Command Code set to "Admission 1226 Control Reject" (4), "Conditional Access Reject" (5), or 1227 "Admission Control and Conditional Access Reject" (6) as 1228 applicable. 1230 o if the Multicast Admission Control message cannot be processed 1231 correctly by the NAS (e.g. the message is malformed, the multicast 1232 flow does not exist etc.), the NAS MUST generate a Generic 1233 Response message (defined in Section 4.2 of [RFC6320]) with 1234 appropriate content indicating the reason for the failure. 1236 4.5. Bandwidth Reallocation Request Message 1238 The Bandwidth Reallocation Request message is used when the bandwidth 1239 delegation capability is included in the negotiated set. It MAY be 1240 sent either by the NAS or by the AN to request an adjustment in the 1241 amount of delegated bandwidth. It will be sent by the NAS typically 1242 to reduce the multicast bandwidth allocated to the AN in order for 1243 the NAS to satisfy a request to add one or more flows. Conversely, 1244 the AN will send a Bandwidth Reallocation Request to obtain 1245 additional bandwidth to satisfy a request to add a multicast channel. 1246 In each case, the requestor has a minimum requirement for additional 1247 bandwidth, and MAY ask for additional bandwidth beyond this amount 1248 (e.g., to handle anticipated future requests). 1250 The Bandwidth Reallocation Request message contains two TLVs: 1252 o the Target TLV (Section 4.3 of [RFC6320] or an extension), 1253 specifying a single access line; 1255 o the Bandwidth-Request TLV (Section 5.8), specifying the required 1256 and preferred amounts of delegated bandwidth. 1258 The Message Type for the Bandwidth Reallocation Request message is 1259 146. 1261 4.5.1. Sender Behaviour 1263 The Result field in the header of the Bandwidth Reallocation Request 1264 message is not used and the sender MUST set it to Ignore (0x0). 1266 The bandwidth values in the Bandwidth-Request TLV are expressed in 1267 terms of total multicast bandwidth allocated to the AN. 1269 The choice of "total bandwidth" rather than "incremental 1270 bandwidth" was made so that it would be easier for the AN and NAS 1271 to keep their respective views of the current amount of delegated 1272 bandwidth synchronized. 1274 Because the values are totals rather than desired increments/ 1275 decrements, the relationship between the required amount and the 1276 preferred amount will differ depending on whether the Bandwidth 1277 Reallocation Request message is issued by the NAS or the AN. 1279 o If the NAS is making the request, the preferred amount MUST be 1280 less than or equal to the required amount. The required amount 1281 MUST be less than the current amount of delegated bandwidth. 1283 o If the AN is making the request, the preferred amount MUST be 1284 greater than or equal to the required amount. The required amount 1285 MUST be greater than the current amount of delegated bandwidth. 1287 4.5.2. Receiver Behaviour 1289 When the peer receives a valid Bandwidth Reallocation Request 1290 message, it SHOULD determine whether it can satisfy the request from 1291 its existing allocation of unused video bandwidth. If it decides 1292 that it can reallocate bandwidth to the peer, it MAY choose to return 1293 any amount between the required and the preferred amounts indicated 1294 in the Bandwidth Reallocation Request message. 1296 The peer MUST return a Bandwidth Transfer message (Section 4.6) 1297 indicating its decision. If the request is met, the Result field of 1298 the Bandwidth Transfer message MUST be set to Success (0x3), the 1299 Result Code field MUST be set to 0x000, and the Bandwidth-Allocation 1300 TLV (Section 5.5) MUST contain the new value of total multicast 1301 bandwidth. This new value MUST lie between the required and 1302 preferred values, inclusive, from the request message. If the 1303 request is not met, the Result field of the Bandwidth Transfer 1304 message MUST be set to Failure (0x4), the Result Code field MUST be 1305 set to 0, and the Bandwidth Allocation TLV MUST contain the value of 1306 the currently allocated amount of delegated bandwidth as the 1307 responder views it. 1309 The following cases indicate that the sender holds a different view 1310 of the amount of delegated bandwidth from the receiver: 1312 o the NAS receives a request where the required amount is less than 1313 its view of the current amount of delegated bandwidth; 1315 o the AN receives a request where the required amount is greater 1316 than its view of the current amount of delegated bandwidth. 1318 If one of these cases occurs, the receiver with one exception MUST 1319 send a Bandwidth Transfer message indicating Success. 1321 o If the NAS received the request, the allocated amount in the NAS's 1322 response MUST be at least equal to NAS's view of the current 1323 amount of delegated bandwidth. 1325 o If the AN received the request, the allocated amount in the AN's 1326 response MUST be no greater than the AN's view of the current 1327 amount of delegated bandwidth. 1329 The exception is when the NAS receives a request while it has a 1330 request of its own outstanding. Handling of that case is described 1331 below. 1333 While the cases just described are an error condition, the success 1334 response achieves a graceful recovery. 1336 To avoid deadlock due to race conditions, the following rules MUST be 1337 applied: 1339 a. If the NAS receives a Bandwidth Reallocation Request message 1340 while it has a Bandwidth Reallocation Request message of its own 1341 outstanding for the same access line, the NAS MUST provide an 1342 immediate failure response to the request from the AN, with a 1343 Result Code value set to 0x68 "Inconsistent views of delegated 1344 bandwidth amount" or 0x69 "Bandwidth request conflict" as 1345 applicable. (See below for more information). 1347 b. If the AN receives a Bandwidth Reallocation Request message while 1348 it has a Bandwidth Reallocation Request message of its own 1349 outstanding for the same access line, the AN MUST release any 1350 bandwidth it has already committed to an outstanding Join request 1351 while it is awaiting a response from the NAS. It MUST decide 1352 upon and send its response to the NAS taking the released 1353 bandwidth into account. 1355 If the receiver is unable to process the Bandwidth Reallocation 1356 Request message due to an error, then the receiver MUST return a 1357 Bandwidth Transfer message where: 1359 o the Result field is set to Failure (0x4), 1361 o the Result Code field is set appropriately to indicate the type of 1362 error that was detected, 1364 o the Bandwidth Allocation TLV contains the value of the current 1365 amount of delegated bandwidth as the responder views it, and 1367 o a Status-Info TLV MAY follow the Bandwidth Allocation TLV giving 1368 further information about the error. 1370 This specification provides three new Result Code values applicable 1371 specifically to the contents of the Bandwidth-Request TLV. These 1372 Result Code values by their nature MUST only be used when the error 1373 is being reported in a Bandwidth Transfer message rather than a 1374 Generic Response message. 1376 0x67 Invalid preferred bandwidth amount. 1378 Where detected: control application at the receiver of the 1379 Bandwidth Reallocation Request message. 1381 Further description: the preferred and required amounts of 1382 bandwidth in the TLV do not have the numerical relationship 1383 described above. 1385 Required additional information in the message: as described 1386 above. 1388 Target: control application at the sender of the Bandwidth 1389 Reallocation Request message. 1391 Action RECOMMENDED for the receiving ANCP agent: report the 1392 error to the control application with the returned value of the 1393 Bandwidth-Allocation TLV. See also Section 4.6.2.2. 1395 0x68 Inconsistent views of delegated bandwidth amount. 1397 Where detected: control application at the NAS. 1399 Further description: the NAS has an outstanding Bandwidth 1400 Reallocation Request, so it is rejecting a similar request from 1401 the AN. In the AN request, the required amount was less than 1402 the NAS's view of the current amount of delegated bandwidth. 1404 Required additional information in the message: as described 1405 above. 1407 Target: control application at the AN. 1409 Action RECOMMENDED for the receiving ANCP agent: report the 1410 error to the AN control application with the returned value of 1411 the Bandwidth-Allocation TLV. See also Section 4.6.2.2. 1413 0x69 Bandwidth request conflict. 1415 Where detected: control application at the NAS. 1417 Further description: the NAS has an outstanding Bandwidth 1418 Reallocation Request, so it is rejecting a similar, valid 1419 request from the AN. 1421 Required additional information in the message: as described 1422 above. 1424 Target: control application at the AN. 1426 Action RECOMMENDED for the receiving ANCP agent: report the 1427 error to the AN control application with the returned value of 1428 the Bandwidth-Allocation TLV. See also Section 4.6.2.2. 1430 4.6. Bandwidth Transfer Message 1432 The Bandwidth Transfer message is used to transfer video bandwidth 1433 from the sender to the peer for a specific access line. This message 1434 MAY be sent either from the AN or from the NAS. As described in the 1435 previous section, it is the required response to a valid Bandwidth 1436 Reallocation Request message. 1438 The Bandwidth Transfer message MAY also be used to transfer bandwidth 1439 autonomously from one peer to another. One example of this usage is 1440 to release bandwidth borrowed earlier by means of the Bandwidth 1441 Reallocation Request message. When the message is used in this way, 1442 the Result field in the Bandwidth Transfer message MUST be set to 1443 Ignore (0x0). 1445 This allows the receiver to distinguish between an autonomous 1446 transfer and a response to a previous Bandwidth Reallocation 1447 Request, for purposes of validation. 1449 The Message Type for the Bandwidth Transfer message is 147. The 1450 Bandwidth Transfer message contains the following TLVs: 1452 o the Target TLV, designating the access line concerned; 1454 o an instance of the Bandwidth-Allocation TLV (Section 5.5). The 1455 bandwidth value in the Bandwidth- Allocation TLV is the new amount 1456 of delegated bandwidth allocated to the target. 1458 4.6.1. Sender Behaviour 1460 When sending a Bandwidth Transfer message where the Result value is 1461 Ignore (0x0) or Success (0x3), the following relationships MUST hold: 1463 o if the message is sent by the NAS, the bandwidth value in the 1464 Bandwidth-Allocation TLV MUST be greater than or equal to the 1465 sender's view of the current amount of delegated bandwidth for the 1466 access line concerned; 1468 o if the message is sent by the AN, the bandwidth value in the 1469 Bandwidth-Allocation TLV MUST be less than or equal to the 1470 sender's view of the current amount of delegated bandwidth for the 1471 access line concerned. 1473 Further sender behaviour is specified above, in Section 4.5.2. 1475 4.6.2. Receiver Behaviour 1477 4.6.2.1. Behaviour of the NAS 1479 If the amount of delegated bandwidth provided in the Bandwidth- 1480 Allocation TLV is not greater than the NAS's view of the current 1481 amount of delegated bandwidth, the NAS MUST update its view of the 1482 current amount of delegated bandwidth to the amount indicated in the 1483 Bandwidth Transfer message. This is required regardless of whether 1484 the Result field of that message indicates Success or Failure. 1486 If the amount of delegated bandwidth provided in the Bandwidth- 1487 Allocation TLV is greater than the NAS's view of the current amount 1488 of delegated bandwidth, the NAS MAY accept the given value as its new 1489 value of delegated bandwidth. Alternatively, the NAS MAY force the 1490 AN to modify its view of the amount of delegated bandwidth to that 1491 held by the NAS, by sending a Port Management message for the target 1492 access line concerned, containing a Bandwidth-Allocation TLV with a 1493 value equal to the amount of delegated bandwidth the NAS wishes to 1494 enforce. 1496 4.6.2.2. Behaviour of the AN 1498 If the amount of delegated bandwidth provided in the Bandwidth- 1499 Allocation TLV of the Bandwidth Transfer message differs from the 1500 AN's view of the current amount of delegated bandwidth, the AN MUST 1501 update its view of the current amount of delegated bandwidth to the 1502 amount indicated in the Bandwidth Transfer message. This is required 1503 with the exception of a Bandwidth Transfer message with a Result 1504 field equal to Failure (0x4) and a Result Code field equal to 0x68 1505 "Inconsistent views of delegated bandwidth amount" or 0x69 "Bandwidth 1506 request conflict". If Result Code value 0x68 is received, the AN 1507 MUST issue a Delegated Bandwidth Query Request message to determine 1508 the NAS's current view of the amount of delegated bandwidth. The AN 1509 MUST update its own view based on the value returned in the Delegated 1510 Bandwidth Query Response. If Result Code value 0x69 is received, the 1511 AN SHOULD carry out this procedure unless it can account for the 1512 discrepancy as a result of a transfer of bandwidth to the NAS that 1513 was carried out just before the incoming Bandwidth Transfer message 1514 was processed. 1516 The two Result Code values indicate a race condition where the AN 1517 may have just completed a transfer of bandwidth to the NAS. As a 1518 result, the value given in the Bandwidth Transfer message may be 1519 outdated, and the AN needs to query the NAS to find its latest 1520 view. The procedure assumes that ordering is preserved between 1521 the Bandwidth Transfer message sent by the AN in response to the 1522 NAS's request and the subsequent Delegated Bandwidth Query Request 1523 message. 1525 If as the result of the procedures just described the AN determines 1526 that it has over-committed multicast bandwidth, it MUST NOT terminate 1527 any currently-active programs, but MUST NOT honour any more "join" 1528 requests until it is possible to do so within the limit set by its 1529 current value of delegated bandwidth. 1531 4.7. Delegated Bandwidth Query Request Message 1533 The Message Type for the Delegated Bandwidth Query Request (and 1534 Response) messages is 148. 1536 The Delegated Bandwidth Query Request message MAY be sent either by 1537 the NAS or by the AN to retrieve the peer's view of the amount of 1538 delegated bandwidth. The request contains one TLV: 1540 o a Target TLV designating the access line for which the information 1541 is requested. 1543 4.7.1. Sender Behaviour 1545 The sender MUST set the Result field in the header of the Delegated 1546 Bandwidth Query Request message to AckAll (0x2). The Result Code 1547 value MUST be set to 0. The sender MUST populate the ANCP 1548 Transaction Identifier field with a unique value, as described in 1549 Section 3.6.1.6 of [RFC6320]. 1551 4.7.2. Receiver Behaviour 1553 If the AN or NAS receives a valid Delegated Bandwidth Query Request 1554 message, it MUST respond with a Delegated Bandwidth Query Response 1555 message. The Result field in the header of the response MUST be set 1556 to Success (0x3). The Result Code field MUST be set to 0. The 1557 Transaction- Id field MUST be copied from the request message. The 1558 body of the response MUST contain the Target TLV, copied from the 1559 request message. Finally, the body of the response MUST contain a 1560 Bandwidth-Allocation TLV, containing the current amount of delegated 1561 bandwidth from the point of view of the receiver of the request. 1563 If the contents of the Delegated Bandwidth Query Request message are 1564 in error, the receiver MUST return a Delegated Bandwidth Query 1565 Response message with the Result field in the header set to Failure 1566 (0x3). The Result Code field MUST be set to the value that indicates 1567 the nature of the error (e.g., 0x500 "One or more of the specified 1568 ports do not exist"). The Transaction-Id field MUST be copied from 1569 the request. The body of the response MUST contain the Target TLV 1570 copied from the request. This MAY be followed by a Status-Info TLV 1571 giving further information about the error. 1573 4.8. Delegated Bandwidth Query Response Message 1575 The Delegated Bandwidth Query Response message is sent in reply to a 1576 Delegated Bandwidth Query Request. The response to a valid request 1577 contains two TLVs: 1579 o the Target TLV, copied from the request; 1581 o a Bandwidth-Allocation TLV, giving the responder's view of the 1582 current amount of multicast bandwidth delegated to the AN. 1584 The Message Type for the Delegated Bandwidth Query Response message 1585 is 148. 1587 4.8.1. Sender Behaviour 1589 Sender behaviour for the Delegated Bandwidth Query Response message 1590 is specified in Section 4.7.2. 1592 4.8.2. Receiver Behaviour 1594 If the Delegated Bandwidth Query Response message indicates Success 1595 (0x3), the following actions apply. 1597 4.8.2.1. Behaviour at the NAS 1599 If the amount of delegated bandwidth provided in the Bandwidth- 1600 Allocation TLV is less than the NAS's view of the current amount of 1601 delegated bandwidth, the NAS MUST update its view of the current 1602 amount of delegated bandwidth to the amount indicated in the 1603 Delegated Bandwidth Query Response message. 1605 If the amount of delegated bandwidth provided in the Bandwidth- 1606 Allocation TLV is greater than the NAS's view of the current amount 1607 of delegated bandwidth, the NAS MAY accept the given value as its new 1608 value of delegated bandwidth. Alternatively, the NAS MAY force the 1609 AN to modify its view of the amount of delegated bandwidth to that 1610 held by the NAS, by sending a Port Management message for the target 1611 access line concerned, containing a Bandwidth-Allocation TLV with a 1612 value equal to the amount of delegated bandwidth the NAS wishes to 1613 enforce. 1615 4.8.2.2. Behaviour at the AN 1617 The AN SHOULD accept the value returned in the Bandwidth-Allocation 1618 TLV of the Delegated Bandwidth Query Response message as the correct 1619 value of the current amount of delegated bandwidth. If the AN has 1620 currently committed more than this amount to active programs, it MUST 1621 NOT cease replicating the flows concerned, but MUST NOT honour any 1622 more Join requests until possible to do so within the new limit. 1624 A race condition is possible, where the AN sends a query, the NAS 1625 requests more bandwidth, then receives and responds to the query, 1626 then receives the Bandwidth Transfer message responding to its 1627 request. It is up to the AN to take appropriate action in this 1628 case. The best action appears to be not to act on the result of 1629 the first query, but to repeat the query after sending the 1630 Bandwidth Transfer message. Similar considerations apply to a 1631 race between queries from both sides. 1633 4.9. Multicast Flow Query Request and Response Messages 1635 This section defines two new messages called the Multicast Flow Query 1636 Request and Multicast Flow Query Response. The Multicast Flow Query 1637 Request is sent by the NAS to request information about the multicast 1638 flows that are active on the AN. The Multicast Flow Query Response 1639 is sent in response by the AN to provide the requested information to 1640 the NAS. 1642 The Message Type for the Multicast Flow Query Request and Multicast 1643 Flow Query Response messages is 149. 1645 The contents of the Multicast Flow Query Request and Response depend 1646 on the nature of the query, as described below. 1648 4.9.1. Sender Behaviour 1650 The sender of a Multicast Flow Query Request message MUST set the 1651 Result field to AckAll (0x2). The Result Code field MUST be set to 1652 0x000. The sender MUST populate the ANCP Transaction Identifier 1653 field with a unique value, as described in section 3.6.1.6 of 1654 [RFC6320]. 1656 The Multicast Flow Query Request MAY be used by the NAS to retrieve: 1658 o the AN's view of which multicast flows are currently active on a 1659 specified set of access ports; or 1661 o the AN's view of the access ports on which a specified set of 1662 multicast flows are currently active; or 1664 o the AN's view of all the multicast flows currently active on each 1665 access port of the AN. 1667 To retrieve the AN's view of which multicast flows are currently 1668 active on a given port of the AN, the NAS MUST include a Target TLV 1669 in the Multicast Flow Query Request payload identifying that port. 1670 The Target TLV is encoded as specified in [RFC6320]. 1672 To retrieve the AN's view of the ports currently receiving a given 1673 multicast flow, the NAS MUST include a Multicast-Flow TLV in the 1674 Multicast Flow Query Request payload identifying that flow. The 1675 Multicast-Flow TLV is encoded as specified in Section 5.12. 1677 The NAS MAY include multiple Target TLVs or multiple Multicast-Flow 1678 TLVs in the Multicast Flow Query Request, but MUST NOT include both 1679 Target and Multicast-Flow TLVs in the same message. 1681 To retrieve the AN's view of all of the multicast flows currently 1682 active on each port of the AN, the NAS MUST send a Multicast Flow 1683 Query Request which does not contain any instance of the Target TLV 1684 or the Multicast-Flow TLV. 1686 4.9.2. Receiver Behaviour 1688 The AN MUST respond to a Multicast Flow Query Request message that 1689 has a valid format and a valid content with a Multicast Flow Query 1690 Response message. The Result field in the response MUST be set to 1691 Success (0x3). The Result Code field MUST be set to 0. The 1692 Transaction- Id field MUST be copied from the request. 1694 If the Multicast Flow Query Request contained one (or more) Target 1695 TLVs, the AN MUST include, for each of these Target TLVs, the 1696 following set of TLVs: 1698 o Target TLV. This MUST be identical to the Target TLV in the 1699 received Multicast Flow Query Request message. 1701 o Multicast-Flow TLV(s). The Multicast-Flow TLV MUST appear once 1702 per multicast flow that is currently active on the AN port 1703 identified in the preceding Target TLV. 1705 The Target TLVs MUST appear in the response from the AN in the same 1706 order as in the query from the NAS. 1708 If the Multicast Flow Query Request contained one (or more) 1709 Multicast-Flow TLVs, the AN MUST include, for each of these 1710 Multicast-Flow TLVs, the following set of TLVs: 1712 o Multicast-Flow TLV. This MUST be identical to the Multicast-Flow 1713 TLV in the received Multicast Flow Query Request message. 1715 o Target TLV(s). The Target TLV MUST appear once per AN port on 1716 which the multicast flow identified in the preceding Multicast- 1717 Flow TLV is active. 1719 The Multicast-Flow TLVs MUST appear in the response from the AN in 1720 the same order as in the query from the NAS. 1722 If the Multicast Flow Query Request contained no Target TLV and no 1723 Multicast Flow TLV, the AN MUST include, for each AN port currently 1724 receiving multicast flow(s), the following set of TLVs: 1726 o Target TLV. This MUST identify one AN port. 1728 o Multicast-Flow TLV(s). The Multicast-Flow TLV MUST appear once 1729 per Multicast Flow that is currently active on the AN port 1730 identified in the preceding Target TLV. 1732 If the contents of the Multicast Flow Query Request are in error, the 1733 AN MUST reply with a Multicast Flow Query Response message with the 1734 Result field set to Failure (0x4) and the Result Code field set to 1735 indicate the nature of the error. If the request contained multiple 1736 instances of the Target TLV or the Multicast-Flow TLV and one of 1737 these is in error, the response message MUST contain the results for 1738 the preceding instances of the TLV as if there had been no error. 1739 These successful results MUST be followed by the TLV in error, copied 1740 from the request. The AN MUST NOT do further processing of the 1741 request. The AN MAY add a Status-Info TLV to provide further 1742 information on the nature of the error. 1744 4.10. Committed Bandwidth Report Message 1746 This section describes the Committed Bandwidth Report message, which 1747 is sent from the AN to the NAS to report the most recent amount of 1748 multicast bandwidth usage committed to one or more access lines. 1750 The Message Type for the Committed Bandwidth Report message is 150. 1752 The Committed Bandwidth Report message contains one or more instances 1753 of the Committed-Bandwidth TLV, as described in Section 5.14. 1755 4.10.1. Sender Behaviour 1757 The sender of a Committed Bandwidth Report message MUST set the 1758 Result field to Ignore (0x0). The Result Code field MUST be set to 1759 0x000. The sender MUST populate the ANCP Transaction Identifier 1760 field with a unique value, as described in section 3.6.1.6 of 1761 [RFC6320]. 1763 Each instance of the Committed-Bandwidth TLV included in the message 1764 MUST identify an access line for which the amount of committed 1765 multicast bandwidth has changed since the previous Committed 1766 Bandwidth Report message was sent and MUST report the latest amount 1767 of multicast bandwidth committed to that line. There MUST be only 1768 one instance of the Committed-Bandwidth TLV present in the message 1769 for any given access line. The message MUST include an instance of 1770 the Committed-Bandwidth TLV for every access line for which committed 1771 multicast bandwidth has changed since the previous Committed 1772 Bandwidth Report message was sent. 1774 Further behaviour at the AN is specified in Section 6.2.2. 1776 4.10.2. Receiver Behaviour 1778 The usage of the contents of a Committed Bandwidth Report message 1779 received by the NAS is implementation-dependent. One example is that 1780 the NAS uses the reports of multicast bandwidth commitments to adjust 1781 its forwarding scheduler operation to provide the intended level of 1782 QoS. 1784 The NAS MUST NOT reply to a valid Committed Bandwidth Report message. 1785 The NAS MAY send a Generic Response message indicating the nature of 1786 any errors detected in a Committed Bandwidth Report message that it 1787 has received. 1789 5. ANCP TLVs For Multicast 1791 This section defines new ANCP TLVs for the control of multicast 1792 flows. 1794 5.1. Multicast-Service-Profile TLV 1796 This document defines the new Multicast-Service-Profile TLV. 1798 The Multicast-Service-Profile TLV MAY be included in a Provisioning 1799 message as specified in Section 4.1. 1801 The Multicast-Service-Profile TLV is illustrated in Figure 6. It 1802 consists of a TLV header encapsulating a single instance of the 1803 Multicast-Service-Profile-Name TLV and one or more instances of the 1804 List-Action TLV. 1806 1 2 3 1807 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1809 | Mcast-Service-Profile 0x0013 | TLV Length | 1810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1811 | Multicast-Service-Profile-Name TLV | 1812 | | 1813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1814 | List-Action TLV | 1815 | | 1816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1817 | ... | 1818 | | 1819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1820 | List-Action TLV | 1821 | | 1822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1824 Figure 6: Multicast-Service-Profile TLV 1826 The Multicast-Service-Profile TLV has the following fields: 1828 o The Multicast-Service-Profile TLV Type is 0x0013. 1830 o The TLV length is determined by the contents following the TLV 1831 header. 1833 o The Multicast-Service-Profile-Name TLV is described in 1834 Section 5.2. The Multicast-Service-Profile-Name TLV MUST contain 1835 an identifier which is unique over all profiles provisioned to the 1836 same AN partition. This identifier will be used to refer to the 1837 profile when activating it for a given target within a Port 1838 Management message (see Section 4.2). 1840 o The List-Action TLV is described in Section 5.3. The List-Action 1841 TLV(s) provide the content of a newly defined multicast service 1842 profile or modify the existing content. If more than one List- 1843 Action TLV is present, the order of the TLVs may be significant, 1844 since List-Action TLVs are processed in the order in which they 1845 appear. 1847 5.2. Multicast-Service-Profile-Name TLV 1849 The Multicast-Service-Profile-Name TLV carries the identifier of a 1850 multicast service profile provisioned on the AN. It is illustrated 1851 in Figure 7. 1853 1 2 3 1854 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1856 | Mcast-Svc-Profile-Name 0x0018 | TLV Length | 1857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1858 | Multicast service profile identifier | 1859 | | 1860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1862 Figure 7: Multicast-Service-Profile-Name TLV 1864 The Multicast-Service-Profile-Name TLV has the following fields: 1866 o The Multicast-Service-Profile-Name TLV Type is 0x0018. 1868 o TLV Length: up to 255 octets. 1870 o Multicast service profile identifier: an opaque sequence of octets 1871 identifying a specific multicast service profile. 1873 The identifier could have the form of human-readable text or an 1874 arbitrary binary value, depending on the operator's practices. 1876 5.3. List-Action TLV 1878 The List-Action TLV identifies multicast flows to be added to or 1879 removed from a list of white-, black-, or grey-listed flows. It is 1880 meaningful only in association with a Multicast-Service-Profile-Name 1881 TLV identifying the profile to which the List-Action TLV applies. 1882 Such an association can be achieved by placing both TLVs in the same 1883 base message payload or as embedded TLVs of another TLV such as the 1884 Multicast-Service-Profile. The List-Action TLV is shown in Figure 8. 1886 1 2 3 1887 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1889 | TLV Type = List-Action 0x0021 | TLV Length | 1890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1891 | Operation | List Type | Reserved | 1892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1893 | Address Family | Number of flow fields | 1894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1895 | Multicast flow fields | 1896 ...... 1897 | | 1898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1899 | Address Family | Number of flow fields | 1900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1901 | Multicast flow fields | 1902 ...... 1903 | | 1904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1906 Figure 8: List-Action TLV 1908 The List-Action TLV contains the following fields: 1910 o The List-Action TLV Type is 0x0021. 1912 o TLV Length: length of the subsequent contents. 1914 o Operation: operation to be performed upon the white, black, or 1915 grey list identified by the List Type field within the profile 1916 identified by the associated Multicast-Service-Profile-Name 1917 embedded TLV. The possible values are: 1919 * 1 "Add": the multicast flow fields are to be added to the list. 1921 * 2 "Delete": the multicast flow fields are to be removed from 1922 the list. Each multicast flow field in the List-Action MUST 1923 match exactly an existing entry in the list concerned. Thus to 1924 remove part of the range provided by a wildcarded list entry, 1925 it is necessary to remove the entire entry and add back the 1926 remaining partial range(s). 1928 * 3 "Replace": the multicast flow fields replace the existing 1929 contents of the list. 1931 o List Type: the list type being modified by this List-Action. The 1932 possible values are 1 "White", 2 "Black", or 3 "Grey". 1934 o Reserved: a sender MUST set this field to zeroes. A receiver MUST 1935 ignore the contents of this field. 1937 o Address Family: the IP version of the set of multicast flow fields 1938 that follow, encoded according to [PIMreg]. Possible values are 1 1939 "IPv4" or 2 "IPv6". Either an IPv4 list or an IPv6 list or both 1940 MAY be present in the List-Action TLV. 1942 o Number of flow fields: the number of multicast flow fields of the 1943 given address family which follow. 1945 o Multicast flow field: a field identifying one or more multicast 1946 flows. It consists of an 8-bit group address prefix length, an 1947 8-bit source address prefix length, a 0-16 octet group prefix, and 1948 a 0-16 octet source prefix, as shown in Figure 9. 1950 Each multicast flow field refers either to a Source-Specific 1951 Multicast (SSM) channel or to an Any Source Multicast (ASM) group. 1952 The scope of the designation may be broadened to multiple channels or 1953 groups through use of prefix length values smaller than the total 1954 address length for the given address family. Multicast flow fields 1955 MUST be placed consecutively within the embedded TLV without 1956 intervening padding except to round out individual addresses to the 1957 nearest octet boundary. 1959 A multicast flow field consists of two single-octet prefix lengths 1960 followed by zero to two prefix values as shown in Figure 9: 1962 +-+-+-+-+-+-+-+-+ 1963 | Group PrefLen | 1964 +-+-+-+-+-+-+-+-+ 1965 | Source PrefLen| 1966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1967 | Group Prefix (multicast) (0 to 16 octets) | 1968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1969 | Source Prefix (unicast, SSM only) (0 to 16 octets) | 1970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1972 Figure 9: Organization of a Single Multicast Flow Field 1974 The prefix length has its usual meaning. It is the number of most- 1975 significant bits specified within the corresponding prefix. The 1976 prefix length MAY vary from 0 to 32 in the IPv4 sub-list, and from 0 1977 to 128 in the IPv6 sub-list. 1979 A value of 0 for either the Group PrefLen (prefix length) or the 1980 Source PrefLen indicates that any value of the corresponding address 1981 will match (wild card). If the value 0 is provided for a particular 1982 prefix length, the corresponding prefix MUST be omitted from the 1983 field contents. 1985 The length of a Source or Group Prefix field is equal to (PrefLen + 1986 7)/8 octets, truncated to the nearest integer. Unused bits at the 1987 end of the prefix MUST be set to zeroes. 1989 5.4. Sequence-Number TLV 1991 The Sequence-Number TLV conveys a sequence number of some sort. The 1992 specific meaning of the sequence number is message-specific. Within 1993 this specification, the Sequence-Number TLV is used as a embedded TLV 1994 in a Status-Info TLV, in a Generic Response reporting a failed 1995 command in a Multicast Replication Control or Multicast Admission 1996 Request message. It identifies the sequence number within the 1997 message of the command that failed. 1999 The Sequence-Number TLV has the format shown in Figure 10. 2001 1 2 3 2002 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2004 | Type = Sequence-Number 0x0022 | TLV Length = 4 | 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2006 | Sequence number | 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2009 Figure 10: Sequence-Number TLV 2011 The Sequence-Number TLV has the following fields: 2013 o The Sequence-Number TLV Type is 0x0022. 2015 o TLV length is 4. 2017 o Sequence number: the sequence number of a specific entity within a 2018 series, where numbering starts from 1 for the first entity in the 2019 series. Represented as a 32-bit binary number, most significant 2020 bit first. 2022 5.5. Bandwidth-Allocation TLV 2024 The Bandwidth-Allocation TLV is used to indicate the total amount of 2025 video bandwidth delegated to the AN for multicast admission control 2026 for a given access line, in kilobits per second. The TLV has the 2027 format shown in Figure 11. 2029 1 2 3 2030 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2032 | Bandwidth-Allocation 0x0015 | TLV Length = 4 | 2033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2034 | Delegated amount (kbits/s) | 2035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2037 Figure 11: The Bandwidth-Allocation TLV 2039 The Bandwidth-Allocation TLV has the following fields: 2041 o The Bandwidth-Allocation TLV Type is 0x0015. 2043 o TLV length is 4. 2045 o Delegated amount: the bandwidth amount delegated to the AN for 2046 admission of multicast video on a given port, kilobits per second. 2047 Presented as a 32-bit binary value, most significant bit first. 2049 5.6. White-List-CAC TLV 2051 The White-List-CAC TLV is used to indicate that the NAS wishes the AN 2052 to do admission control for white-listed flows. Details on when the 2053 White-List-CAC TLV may be provisioned are specified in Section 6. 2054 The White-List-CAC TLV is illustrated in Figure 12. 2056 1 2 3 2057 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2059 | Type = White-List-CAC 0x0024 | TLV Length = 0 | 2060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2062 Figure 12: White-List-CAC TLV 2064 The White-List-CAC TLV contains the following fields: 2066 o The White-List-CAC TLV Type is 0x0024. 2068 o TLV length is 0, since the TLV contains no data other than the TLV 2069 header. 2071 5.7. MRepCtl-CAC TLV 2073 The MRepCtl-CAC TLV is used to indicate that the NAS wishes the AN to 2074 do admission control for flows added by the Multicast Replication 2075 Control message. Details on when the MRepCtl-CAC TLV may be 2076 provisioned are specified in Section 6. The MRepCtl-CAC TLV is 2077 illustrated in Figure 13. 2079 1 2 3 2080 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2082 |TLV Type = MRepCtl-CAC 0x0025 | TLV Length = 0 | 2083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2085 Figure 13: MRepCtl-CAC TLV 2087 The MRepCtl-CAC TLV contains the following fields: 2089 o The MRepCtl-CAC TLV Type is 0x0025. 2091 o TLV length is 0, since the TLV contains no data other than the TLV 2092 header. 2094 5.8. Bandwidth-Request TLV 2096 The Bandwidth-Request TLV is used to request an adjustment of the 2097 total amount of video bandwidth allocated to the AN for multicast 2098 admission control for a given line. The "Required amount" field 2099 indicates the minimum adjustment required to meet the request. The 2100 "Preferred amount" field indicates the adjustment the requestor would 2101 prefer to have, if possible. Section 4.5 discusses the required 2102 relationships between the "Required amount", "Preferred amount", and 2103 current values of total bandwidth allocated to the AN. 2105 The Bandwidth-Request TLV has the format shown in Figure 14. 2107 1 2 3 2108 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2110 | Type=Bandwidth-Request 0x0016 | TLV Length = 8 | 2111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2112 | Required amount (kbits/s) | 2113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2114 | Preferred amount (kbits/s) | 2115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2117 Figure 14: The Bandwidth-Request TLV 2119 The Bandwidth-Request TLV has the following fields: 2121 o The Bandwidth-Request TLV Type is 0x0016. 2123 o The TLV length is 8 octets. 2125 o Required amount: the minimum or maximum amount, depending on 2126 whether the sender is the AN or the NAS respectively, of delegated 2127 video bandwidth that is being requested, in kilobits per second. 2128 Presented as a 32-bit binary value, most significant bit first. 2130 o Preferred amount: the preferred amount of delegated video 2131 bandwidth that is being requested, in kilobits per second. 2132 Presented as a 32-bit binary value, most significant bit first. 2134 5.9. Request-Source-IP TLV 2136 The Request-Source-IP TLV provides the IP address of the entity that 2137 originated a specific request to join or leave a multicast channel. 2138 The TLV is illustrated in Figure 15. 2140 1 2 3 2141 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2143 | TLV Type = Request-Source-IP | TLV length = 4 or 16 | 2144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2145 | Unicast Address | 2146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2148 Figure 15: Request-Source-IP TLV 2150 The Request-Source-IP TLV contains the following fields: 2152 o The Request-Source-IP TLV Type is 0x0092. 2154 o TLV length is 4 for an IPv4 address or 16 for an IPv6 address. 2156 o Unicast address: IP address of the source of a multicast flow join 2157 request, in network byte order. 2159 5.10. Request-Source-MAC TLV 2161 The Request-Source-MAC TLV provides the MAC address of the entity 2162 that originated a specific request to join or leave a multicast 2163 channel. The TLV is illustrated in Figure 16. 2165 1 2 3 2166 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2168 |TLV Type=Request-Source-MAC | TLV Length = 6 or 8 | 2169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2170 | | 2171 +-+-+- IEEE MAC Address +-+-+-+ 2172 | | 2173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2175 Figure 16: Request-Source-MAC TLV 2177 The Request-Source-MAC TLV contains the following fields: 2179 o The Request-Source-MAC TLV Type is 0x0093. 2181 o TLV length is either 6 octets (MAC-48 or EUI-48) or 8 octets 2182 (EUI-64). 2184 o IEEE MAC Address: MAC address of the device originating the 2185 request to join a multicast flow. Within the address, bytes and 2186 bits respectively shall be ordered from most to least significant, 2187 consistently with [IEEE48] for MAC-48 and EUI-48, and with 2188 [IEEE64] for EUI-64. 2190 EUI-48 and EUI-64 are registered trademarks of the IEEE. 2192 5.11. Request-Source-Device-Id TLV 2194 The Request-Source-Device-Id TLV provides a local identifier of the 2195 entity that originated a specific request to join or leave a 2196 multicast channel. The TLV is illustrated in Figure 17. 2198 1 2 3 2199 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2201 | Request-Source-Device-Id | TLV length = 4 | 2202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2203 | Identifier value | 2204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2206 Figure 17: Request-Source-Device- Id TLV 2208 The Request-Source-Device-Id TLV contains the following fields: 2210 o The Request-Source-IP TLV Type is 0x0096. 2212 o TLV length is 4. 2214 o Local device identifier value, known to the AN and AAA. Given 2215 that the scope of the identifier is a single customer network, 32 2216 bits is a more than sufficient numbering space. 2218 5.12. Multicast-Flow TLV 2220 IGMPv3 [RFC3376] and MLDv2 [RFC3801] allow multicast listeners to 2221 specify multiple source addresses for the same multicast group. 2222 Similarly the Multicast-Flow TLV specifies a multicast flow in terms 2223 of its multicast group address and, if applicable, one or more 2224 unicast source addresses. The Multicast-Flow TLV is illustrated in 2225 Figure 18. 2227 1 2 3 2228 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2230 | Type = Multicast-Flow 0x0019 | TLV Length | 2231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2232 | Flow Type | Addr Family | Number of source addresses | 2233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2234 | Multicast Group Address | 2235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 2236 | Unicast Source Address (for SSM flows only) | 2237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2239 Figure 18: Multicast-Flow TLV 2241 The Multicast-Flow TLV has the following fields: 2243 o The Multicast-Flow TLV Type is 0x0019. 2245 o TLV Length: ranges from a minimum of 8 (for an ASM IPv4 flow) 2246 upwards. Total length is 4 + 4*(Number of Source Addresses +1) 2247 for IPv4 or 4 + 16*(Number of Source Addresses + 1) for IPv6. 2249 o Flow Type: 1 "Any Source Multicast (ASM)", 2 "Source-Specific 2250 Multicast (SSM)". 2252 o Addr Family: address family of the multicast source and group 2253 addresses, encoded in accordance with the IANA PIM Address Family 2254 registry ([PIMreg]). 1 indicates IPv4, 2 indicates IPv6. 2256 o Number of Source Addresses: 0 for ASM, 1 or more for SSM. 2258 o Multicast Group Address: a multicast group address within the 2259 given address family. The group address MUST always be present. 2261 o Unicast Source Address: unicast address within the given address 2262 family. If the Flow Type is "ASM" (1), a source address MUST NOT 2263 be present. If the Flow Type is "SSM" (2), the number of source 2264 addresses given by the Number of Source Addresses field MUST be 2265 present. 2267 5.13. Report-Buffering-Time TLV 2269 The Report-Buffering-Time TLV provides the time for which a Committed 2270 Bandwidth Report message must be held with the intention of 2271 accumulating multiple reports of changed committed multicast 2272 bandwidth in one report, to reduce the volume of messages sent to the 2273 NAS. For further information see Section 6.2.2. The TLV is 2274 illustrated in Figure 19. 2276 1 2 3 2277 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2279 | Report-Buffering-Time 0x0094 | TLV Length = 4 | 2280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2281 | Buffering Time (ms) | 2282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2284 Figure 19: Report-Buffering-Time TLV 2286 The Report-Buffering-Time TLV contains the following fields: 2288 o The Report-Buffering-Time TLV Type is 0x0094. 2290 o TLV length is 4 octets. 2292 o Buffering Time is a 32-bit unsigned integer containing a time 2293 value in ms. 2295 5.14. Committed-Bandwidth TLV 2297 The Committed-Bandwidth TLV identifies an access line and provides 2298 the current amount of multicast bandwidth that the AN has committed 2299 to it. The TLV is illustrated in Figure 20. 2301 1 2 3 2302 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2304 | Committed-Bandwidth 0x0095 | TLV Length (variable) | 2305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2306 | Committed Multicast Bandwidth (kbits/s) | 2307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2308 | | 2309 ~ Target TLV ~ 2310 | | 2311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2313 Figure 20: Committed-Bandwidth TLV 2315 The Committed-Bandwidth TLV contains the following fields: 2317 o The Committed-Bandwidth TLV Type is 0x0095. 2319 o TLV length is 4 octets plus the length of the Target TLV including 2320 its header and any padding. 2322 o Committed Multicast Bandwidth is a 32-bit unsigned integer 2323 providing a bandwidth amount in kbits/s. 2325 o The Target TLV identifies the access line to which this amount of 2326 multicast bandwidth is currently committed. 2328 6. Multicast Capabilities 2330 Section 3.5 of [RFC6320] defines a capability negotiation mechanism 2331 as well as a number of capabilities. This section defines five new 2332 capabilities in support of different modes of multicast operation: 2334 o NAS-initiated replication (capability type 3); 2336 o committed multicast bandwidth reporting (capability type 5); 2338 o conditional access and admission control with white and black 2339 lists (capability type 6); 2341 o conditional access and admission control with grey lists 2342 (capability type 7); 2344 o bandwidth delegation (capability type 8). 2346 The "Capability Data" field within the Capability TLV for all of 2347 these capabilities is empty. All of these capabilities are 2348 independent of the access technology. 2350 The remainder of this section consists of three sub-sections. 2351 Section 6.1 specifies the protocol elements that must be implemented 2352 in order to support each capability. Section 6.2 specifies the 2353 procedures that apply to each capability on its own. Section 6.3 2354 specifies how the capabilities interact if more than one multicast 2355 capability is included in the set of capabilities negotiated between 2356 the AN and the NAS. 2358 6.1. Required Protocol Support 2360 This section specifies the protocol elements that MUST be implemented 2361 to support each of the four multicast capabilities. Support of 2362 multiple multicast capabilities requires implementation of the union 2363 of the sets of protocol elements applying to each of the individual 2364 capabilities in the supported set. 2366 In addition to the elements listed below, implementation of the 2367 Target TLV (Section 4.3 of [RFC6320]) is REQUIRED for all of the 2368 capabilities specified in this document. 2370 6.1.1. Protocol Requirements For NAS-Initiated Replication 2372 Table 1 specifies the protocol elements within Section 4 and 2373 Section 5 that MUST be implemented to support the NAS-initiated 2374 replication multicast capability. Additionally, implementation of 2375 the Multicast Replication Control message requires implementation of 2376 the Command TLV (Section 4.4 of [RFC6320] with additional details in 2377 Section 4.3 of this document). 2379 +--------------+----------------------------------------------------+ 2380 | Reference | Protocol Element | 2381 +--------------+----------------------------------------------------+ 2382 | Section 4.1 | Provisioning message with MRepCtl-CAC TLV; | 2383 | | | 2384 | Section 4.2 | Port Management message with Bandwidth-Allocation | 2385 | | TLV; | 2386 | | | 2387 | Section 4.3 | Multicast Replication Control message; | 2388 | | | 2389 | Section 4.9 | Multicast Flow Query Request and Response | 2390 | | messages; | 2391 | | | 2392 | Section 5.4 | Sequence Number TLV; | 2393 | | | 2394 | Section 5.5 | Bandwidth-Allocation TLV; | 2395 | | | 2396 | Section 5.7 | MRepCtl-CAC TLV; | 2397 | | | 2398 | Section 5.12 | Multicast-Flow TLV. | 2399 +--------------+----------------------------------------------------+ 2401 Table 1: Protocol Requirements For NAS-Initiated Replication 2403 6.1.2. Protocol Requirements For Committed Multicast Bandwidth 2404 Reporting 2406 Table 2 specifies the protocol elements within Section 4 and 2407 Section 5 that MUST be implemented to support the committed multicast 2408 bandwidth reporting capability. 2410 +--------------+----------------------------------------------------+ 2411 | Reference | Protocol Element | 2412 +--------------+----------------------------------------------------+ 2413 | Section 4.1 | Provisioning message with Report-Buffering-Time | 2414 | | TLV; | 2415 | | | 2416 | Section 4.10 | Committed Bandwidth Report message; | 2417 | | | 2418 | Section 4.9 | Multicast Flow Query Request and Response | 2419 | | messages; | 2420 | | | 2421 | Section 5.13 | Report-Buffering-Timer TLV; | 2422 | | | 2423 | Section 5.14 | Committed-Bandwidth TLV; | 2424 | | | 2425 | Section 5.12 | Multicast-Flow TLV. | 2426 +--------------+----------------------------------------------------+ 2428 Table 2: Protocol Requirements For Committed Multicast Bandwidth 2429 Reporting 2431 6.1.3. Protocol Requirements For Conditional Access and Admission 2432 Control With White and Black Lists 2434 Table 3 specifies the protocol elements within Section 4 and 2435 Section 5 that MUST be implemented to support the conditional access 2436 and admission control with white and black lists multicast 2437 capability. 2439 +--------------+----------------------------------------------------+ 2440 | Reference | Protocol Element | 2441 +--------------+----------------------------------------------------+ 2442 | Section 4.1 | Provisioning message with Multicast-Service- | 2443 | | Profile TLV, white and black lists only, and | 2444 | | White-List-CAC TLV; | 2445 | | | 2446 | Section 4.2 | Port Management message with Multicast-Service- | 2447 | | Profile-Name and Bandwidth-Allocation TLVs; | 2448 | | | 2449 | Section 4.9 | Multicast Flow Query Request and Response | 2450 | | messages; | 2451 | | | 2452 | Section 5.1 | Multicast-Service-Profile TLV; | 2453 | | | 2454 | Section 5.2 | Multicast-Service-Profile-Name TLV; | 2455 | | | 2456 | Section 5.3 | List-Action TLV, white and black lists only; | 2457 | | | 2458 | Section 5.5 | Bandwidth-Allocation TLV; | 2459 | | | 2460 | Section 5.6 | White-List-CAC TLV; | 2461 | | | 2462 | Section 5.12 | Multicast-Flow TLV. | 2463 +--------------+----------------------------------------------------+ 2465 Table 3: Protocol Requirements For Conditional Access and Admission 2466 Control with White and Black Lists 2468 6.1.4. Protocol Requirements For Conditional Access and Admission 2469 Control With Grey Lists 2471 Table 4 specifies the protocol elements within Section 4 and 2472 Section 5 that MUST be implemented to support the conditional access 2473 and admission control with grey lists multicast capability. 2474 Additionally, implementation of the Multicast Replication Control 2475 message requires implementation of the Command TLV (Section 4.4 of 2476 [RFC6320] with additional details in Section 4.3 of this document). 2478 +--------------+----------------------------------------------------+ 2479 | Reference | Protocol Element | 2480 +--------------+----------------------------------------------------+ 2481 | Section 4.1 | Provisioning message with Multicast-Service- | 2482 | | Profile TLV, grey lists only, and MRepCtl-CAC TLV; | 2483 | | | 2484 | Section 4.2 | Port Management message with Multicast-Service- | 2485 | | Profile-Name and Bandwidth-Allocation TLVs; | 2486 | | | 2487 | Section 4.3 | Multicast Replication Control message; | 2488 | | | 2489 | Section 4.4 | Multicast Admission Control message; | 2490 | | | 2491 | Section 4.9 | Multicast Flow Query Request and Response | 2492 | | messages; | 2493 | | | 2494 | Section 5.1 | Multicast-Service-Profile TLV, grey lists only; | 2495 | | | 2496 | Section 5.2 | Multicast-Service-Profile-Name TLV; | 2497 | | | 2498 | Section 5.3 | List-Action TLV, grey lists only; | 2499 | | | 2500 | Section 5.4 | Sequence Number TLV; | 2501 | | | 2502 | Section 5.5 | Bandwidth-Allocation TLV; | 2503 | | | 2504 | Section 5.7 | MRepCtl-CAC TLV; | 2505 | | | 2506 | Section 5.9 | Request-Source-IP TLV; | 2507 | | | 2508 | Section 5.10 | Request-Source-MAC TLV; | 2509 | | | 2510 | Section 5.11 | Request-Source-Device-Id TLV; | 2511 | | | 2512 | Section 5.12 | Multicast-Flow TLV. | 2513 +--------------+----------------------------------------------------+ 2515 Table 4: Protocol Requirements For Conditional Access and Admission 2516 Control with Grey Lists 2518 6.1.5. Protocol Requirements For Delegated Bandwidth 2520 Table 5 specifies the protocol elements within Section 4 and 2521 Section 5 that MUST be implemented to support the delegated bandwidth 2522 multicast capability. 2524 +--------------+----------------------------------------------------+ 2525 | Reference | Protocol Element | 2526 +--------------+----------------------------------------------------+ 2527 | Section 4.2 | Port Management message with Bandwidth-Allocation | 2528 | | TLV; | 2529 | | | 2530 | Section 4.5 | Bandwidth Reallocation Request message; | 2531 | | | 2532 | Section 4.6 | Bandwidth Transfer message; | 2533 | | | 2534 | Section 4.7 | Delegated Bandwidth Query Request message; | 2535 | | | 2536 | Section 4.8 | Delegated Bandwidth Query Response message | 2537 | | | 2538 | Section 4.9 | Multicast Flow Query Request and Response | 2539 | | messages; | 2540 | | | 2541 | Section 5.5 | Bandwidth-Allocation TLV; | 2542 | | | 2543 | Section 5.8 | Bandwidth-Request TLV; | 2544 | | | 2545 | Section 5.12 | Multicast-Flow TLV. | 2546 +--------------+----------------------------------------------------+ 2548 Table 5: Protocol Requirements For Delegated Bandwidth 2550 6.2. Capability-Specific Procedures for Providing Multicast Service 2552 This section describes multicast service procedures for each 2553 capability as if it were the only multicast capability within the 2554 negotiated set. Procedures involving combinations of multicast 2555 capabilities are described in Section 6.3. 2557 The use of the Multicast Flow Query Request and Response messages to 2558 determine the association between multicast flows and ports is common 2559 to all multicast capabilities. No additional text is required here, 2560 beyond that already given in Section 4.9 to describe the use of those 2561 messages. 2563 6.2.1. Procedures For NAS-Initiated Replication 2565 NAS-initiated replication may be negotiated to support a mode of 2566 operation where IGMP/MLD requests are terminated on the NAS. 2567 Alternatively, it may be negotiated to allow the NAS to respond to 2568 requests sent by other means (e.g., through application signalling) 2569 that require the replication of multicast channels to a given access 2570 line. 2572 6.2.1.1. Provisioning 2574 The NAS MAY perform admission control for NAS-initiated replication. 2575 In this case, it MUST NOT include the MRepCtl-CAC TLV in a 2576 Provisioning message sent to the AN. Alternatively, the NAS MAY 2577 enable admission control at the AN for NAS-initiated replication. To 2578 do this, it MUST include the MRepCtl-CAC TLV in a Provisioning 2579 message sent to the AN and it MUST also include a Bandwidth- 2580 Allocation TLV in a Port Management message for each access line. 2582 6.2.1.2. Multicast Service Procedures 2584 The procedures associated with NAS-initiated replication are 2585 straightforward. To initiate replication, the NAS MUST send a 2586 Multicast Replication Control message to the AN, containing one or 2587 more commands adding flows, as described in Section 4.3.1. To 2588 terminate replication the NAS MUST send a Multicast Replication 2589 Control message where the commands delete instead of adding the 2590 flows. The AN acts upon these messages as specified in 2591 Section 4.3.2. 2593 6.2.2. Procedures For Committed Bandwidth Reporting 2595 Committed bandwidth reporting may be negotiated if the NAS requires 2596 current knowledge of the amount of multicast bandwidth committed to 2597 each access line and cannot obtain this information by other means. 2599 6.2.2.1. Provisioning 2601 The default buffering time when committed bandwidth reporting is 2602 enabled is zero (immediate reporting). To change this, the NAS MAY 2603 send an instance of the Report-Buffering-Time TLV containing a non- 2604 zero time value to the AN in a Provisioning message. If the NAS 2605 subsequently wishes to change the buffering time again, it MAY do so 2606 in another Provisioning message. 2608 6.2.2.2. Multicast Service Procedures 2610 If the buffering time for committed bandwidth reporting is zero, the 2611 AN MUST send a Committed Bandwidth Report message to the NAS each 2612 time the amount of multicast bandwidth committed to any access line 2613 under its control changes. 2615 If a non-zero value is provided in the Report-Buffering-Time TLV, the 2616 AN at any given moment is in one of two states: not-buffering, or 2617 buffering. The AN enters buffering state if it is in not-buffering 2618 state and the multicast bandwidth amount committed to some access 2619 line changes. It leaves buffering state when the AN sends a 2620 Committed Bandwidth Report. 2622 Upon entry to the buffering state, the AN MUST start a buffering 2623 timer and create a Committed Bandwidth Report message containing a 2624 Committed-Bandwidth TLV for the triggering access line, but MUST NOT 2625 send it. If a multicast bandwidth change occurs for another access 2626 line, the AN MUST add a new Committed-Bandwidth TLV to the message 2627 for that additional line. If a multicast bandwidth change occurs for 2628 a line for which a Committed-Bandwidth TLV is already present in the 2629 buffered report, the AN MUST update the corresponding Committed- 2630 Bandwidth TLV to contain the new bandwidth value, rather than adding 2631 another Committed-Bandwidth TLV for the same access line. 2633 The buffering timer expires after the period provided by the Report- 2634 Buffering-Time TLV. When it expires, the AN MUST send the Committed 2635 Bandwidth Report message that it has been accumulating to the NAS. 2636 Exceptionally, the AN MAY choose to send the message before the timer 2637 expires, in which case it MUST clear the buffering timer when the 2638 message is sent. In either case, the AN enters the not- buffering 2639 state as a result. 2641 Report buffering implies that NAS reaction to changes in multicast 2642 bandwidth usage is delayed by the amount of the buffering period. 2643 The choice of buffering period must take this into consideration. 2645 6.2.3. Procedures For Conditional Access and Admission Control With 2646 Black and White Lists 2648 6.2.3.1. Provisioning 2650 The NAS provisions named multicast service profiles containing white 2651 and black lists on the AN using the Provisioning message containing 2652 one or more Multicast-Service-Profile TLVs. The NAS MAY update the 2653 contents of these profiles from time to time as required, by sending 2654 additional Provisioning messages with Multicast-Service-Profile TLVs 2655 containing incremental modifications to the existing white and black 2656 lists or replacements for them. 2658 The NAS assigns a specific multicast service profile to an individual 2659 access line using the Port Management message containing a Multicast- 2660 Service-Profile-Name TLV. The NAS MAY change the multicast service 2661 profile for a given access line at any time by sending a Port 2662 Management message identifying a new multicast service profile. 2664 The NAS MAY choose to enable admission control at the AN for white- 2665 listed flows. To do this, it MUST send a Provisioning message as 2666 described in Section 4.1, which includes the White-List-CAC TLV and 2667 it MUST provide a multicast bandwidth allocation for each access line 2668 by including a Bandwidth-Allocation TLV in a Port Management message. 2670 6.2.3.2. Multicast Service Procedures 2672 The conditional access with white and black lists capability assumes 2673 that IGMP/MLD requests are terminated on the AN. When the AN 2674 receives a "join" request, it MUST check to see whether the requested 2675 flow is white-listed or black-listed as described below. Requests 2676 for black-listed flows MUST be discarded. If the NAS has enabled 2677 admission control on the AN as described in the previous section, but 2678 a white-listed flow would cause the amount of committed multicast 2679 bandwidth to exceed the provisioned limit, the request MUST be 2680 discarded. The AN replicates flows passing these checks to the 2681 access line. 2683 To determine if a requested flow is white-listed, the AN searches for 2684 a best match to the flow in the applicable multicast service profile. 2685 Matching is done on the prefixes specified in the profile, ignoring 2686 the address bits of lower order than those in the prefix. 2688 If the requested multicast flow matches multiple lists associated 2689 with the access line, then the most specific match will be considered 2690 by the AN. If the most specific match occurs in multiple lists, the 2691 black list entry takes precedence over the white list. In this 2692 context, the most specific match is defined as: 2694 o first, most specific match (longest prefix length) on the 2695 multicast group address (i.e., on G of ) 2697 o then, most specific match (longest prefix length) on the unicast 2698 source address (i.e. on S of ) 2700 If the requested multicast flow is not part of any list, the join 2701 message SHOULD be discarded by the AN. This default behavior can 2702 easily be changed by means of a "catch-all" statement in the white 2703 list. For instance, adding () in the white List would make 2704 the default behavior to accept join messages for a multicast flow 2705 that has no other match on any list. 2707 When the AN receives a "leave" request, it terminates replication of 2708 the multicast flow. 2710 If the AN receives a Provisioning message which updates an existing 2711 multicast service profile, the AN MUST review the status of active 2712 flows on all ports to which the updated profile is currently 2713 assigned. Similarly, if a Port Management message assigns a new 2714 multicast service profile to a given port, the AN MUST review all 2715 active flows on that port. If the most specific match for any flow 2716 is a black list entry, the flow MUST be terminated immediately. If 2717 any of the remaining flows do not match an entry in the white list, 2718 they also MUST be terminated immediately. White listed flows MUST be 2719 allowed to continue. 2721 6.2.4. Procedures For Conditional Access and Admission Control With 2722 Grey Lists 2724 6.2.4.1. Provisioning 2726 The NAS provisions named multicast service profiles containing grey 2727 lists on the AN using the Provisioning message containing one or more 2728 Multicast-Service-Profile TLVs. The NAS MAY update the contents of 2729 these profiles from time to time as required, by sending additional 2730 Provisioning messages with Multicast-Service-Profile TLVs containing 2731 incremental modifications to the existing grey lists or replacements 2732 for them. 2734 The NAS assigns a specific multicast service profile to an individual 2735 access line using the Port Management message containing a Multicast- 2736 Service-Profile-Name TLV. The NAS MAY change profiles on the line by 2737 sending a subsequent Port Management message identifying a new 2738 profile. 2740 The NAS MAY perform admission control for grey-listed flows. In that 2741 case, the NAS MUST NOT include the MRepCtl-CAC TLV in a Provisioning 2742 message sent to the AN. Alternatively, the NAS MAY enable admission 2743 control at the AN for grey-listed flows. To do this, it MUST include 2744 the MRepCtl-CAC TLV in a Provisioning message sent to the AN and MUST 2745 also provide a Bandwidth-Allocation TLV in a Port Management message 2746 for each access line. 2748 6.2.4.2. Multicast Service Procedures 2750 The conditional access and admission control with grey lists 2751 capability assumes that IGMP/MLD requests are terminated on the AN. 2752 When the AN receives a "join" request, it MUST determine whether 2753 there is a match to the requested flow in the grey list of the 2754 multicast service profile provisioned against the given access line. 2755 If there is no match, the request is discarded. Otherwise, the AN 2756 MUST send a Multicast Admission Control message to the NAS with 2757 content identifying the access line and the multicast flow to be 2758 added. As indicated in Section 4.4, the AN MAY add information 2759 identifying the requesting device. 2761 If the NAS decides to enable the flow, it MUST send a Multicast 2762 Replication Control request to the AN to replicate the flow to the 2763 access line with the Result field set to Nack (0x1), as described in 2764 Section 4.3.1. 2766 When the AN receives the Multicast Replication Control request, it 2767 performs admission control if that has been enabled as described in 2768 the previous section. If admitting the flow would cause the 2769 committed multicast bandwidth at the access line to exceed the 2770 provisioned limit, the AN reports an error to the NAS as described in 2771 Section 4.3.2. Otherwise it replicates the multicast flow as 2772 requested. 2774 If the NAS decides not to permit the flow, it MAY send a Multicast 2775 Replication Control message in response to the Multicast Admission 2776 Control message to allow the AN to update its internal records. The 2777 content of this message is described in Section 4.4.2. 2779 When the AN receives a "leave" request, it MUST terminate replication 2780 of the flow to the access line. It MUST then send a Multicast 2781 Admission Control message to the NAS indicating the deletion. The 2782 NAS updates its internal records but MUST NOT respond to the message. 2784 If the AN receives a Provisioning message which updates an existing 2785 multicast service profile, the AN MUST review the status of active 2786 flows on all ports to which the updated profile has been assigned. 2787 Similarly, if the AN receives a Port Management message that assigns 2788 a new profile to a given port, the AN MUST review all active flows on 2789 that port. In either case, if any flow does not match an entry in 2790 the grey list, it MUST be terminated immediately. 2792 6.2.5. Procedures For Delegated Bandwidth 2794 6.2.5.1. Provisioning 2796 The NAS SHOULD provision an initial amount of delegated multicast 2797 bandwidth for each access line using the Port Management message 2798 containing the Bandwidth-Allocation TLV. 2800 If it fails to do so and a value has not been provisioned on the 2801 AN by other means, the AN will be forced to request a bandwidth 2802 allocation as soon as it receives a "join" request. 2804 The NAS MAY at any time force an update of the amount of delegated 2805 bandwidth by the same means. 2807 6.2.5.2. Multicast Service Procedures 2809 The delegated bandwidth capability assumes that IGMP/MLD requests are 2810 terminated on the AN. When the AN receives a "join" request, it 2811 checks whether it has sufficient remaining uncommitted multicast 2812 bandwidth on the access line to accommodate the new multicast flow. 2813 If not, it MAY send a request to the NAS for an increased allocation 2814 of delegated bandwidth, using the Bandwidth Reallocation Request 2815 message. The NAS MUST return a Bandwidth Transfer message indicating 2816 whether it has granted the request, and if so, what is the new amount 2817 of delegated bandwidth. 2819 If the AN has sufficient uncommitted multicast capacity to admit the 2820 request, either originally or as the result of a successful request 2821 to the NAS, it replicates the requested flow to the access line. 2822 Otherwise it discards the request. 2824 When the AN receives a "leave" request for an active flow, it ceases 2825 replication. 2827 The NAS or AN MAY at some point detect that their respective views of 2828 the amount of delegated bandwidth are inconsistent. If so, they can 2829 recover using procedures described in Section 4.5 and Section 4.6. 2830 As a further aid to synchronization, either the NAS or the AN MAY 2831 from time to time check the peer's view of the amount of delegated 2832 bandwidth using the Delegated Bandwidth Query message. 2834 The NAS or AN MAY at any time release bandwidth to the peer using an 2835 autonomous Bandwidth Transfer message. The contents of this message 2836 are described in Section 4.6. 2838 6.3. Combinations of Multicast Capabilities 2840 6.3.1. Combination of Conditional Access and Admission Control With 2841 White and Black Lists and Conditional Access and Admission 2842 Control With Grey Lists 2844 If conditional access with white and black lists is combined with 2845 conditional access with grey lists, provisioning of the multicast 2846 service profiles is as described in Section 6.2.3.1 except that 2847 multicast service profiles will also include grey lists. Admission 2848 control is enabled independently on the AN for white lists by 2849 including the White-List-CAC TLV in the Provisioning message and for 2850 grey lists by including the MRepCtl-CAC TLV in the Provisioning 2851 message. The Bandwidth-Allocation TLV provisions an amount that 2852 applies to both white- and grey- listed flows if admission control is 2853 enabled for both. 2855 With regard to multicast service procedures, one point of difference 2856 from the individual capabilities must be noted. This is an 2857 interaction during the profile matching procedure. The AN MUST seek 2858 the best match amongst multiple lists as described in 2859 Section 6.2.3.2. However, if there are multiple matches of equal 2860 precision, the order of priority is black list first, grey list 2861 second, and white list last. 2863 Once profile matching has been completed, processing of a "join" 2864 request is as described in Section 6.2.3.2 for white or black listed 2865 flows or Section 6.2.4.2 for grey listed flows. Requests that do not 2866 match any list SHOULD be discarded. 2868 When the AN receives a "leave" request, it MUST terminate replication 2869 of the flow to the access line. If the flow was grey-listed, the AN 2870 MUST then send a Multicast Admission Control message to the NAS 2871 indicating the deletion. 2873 If the AN receives a Provisioning message which updates an existing 2874 multicast service profile, the AN MUST review the status of active 2875 flows on all ports to which the updated profile is currently 2876 assigned. Similarly, if a Port Management message assigns a new 2877 multicast service profile to a given port, the AN MUST review all 2878 active flows on that port. If any flow has its most specific match 2879 in a black list entry, it MUST be terminated immediately. If any of 2880 the remaining flows do not match an entry in the white or grey list, 2881 they MUST also be terminated immediately. Finally, if any remaining 2882 flows were originally admitted because they were white-listed, but 2883 after the change they are grey-listed, the AN MUST generate a 2884 Multicast Flow Query response message autonomously as if it were 2885 responding to a Multicast Flow Query request, listing all such flows. 2886 These flows MUST be allowed to continue until the NAS or the 2887 subscriber terminates them. Flows with their most specific match in 2888 the white list MUST be allowed to continue. 2890 The autonomously-generated Multicast Flow Query response message MUST 2891 be formatted as if it were a successful response to a request 2892 containing no Target and no Multicast-Flow TLV, as described in 2893 Section 4.9.2, with the exception that the Transaction-Id MUST be set 2894 to all zeroes. 2896 The procedures in the previous paragraphs imply that the AN has to 2897 retain a memory of whether an admitted flow was white-listed or 2898 grey-listed at the time of its admission/readmission. 2900 6.3.2. Combination of Conditional Access and Admission Control With 2901 Delegated Bandwidth 2903 The provisioning and bandwidth management procedures of Section 6.2.5 2904 apply in addition to the procedures in Section 6.2.3, Section 6.2.4, 2905 or Section 6.3.1 as applicable. Conditional access follows the rules 2906 given in those sections in terms of matching flows against white and 2907 black and/or grey lists. When admission control is enabled at the 2908 AN, the amount of bandwidth used by the AN is negotiable as described 2909 in Section 6.2.5.2. 2911 6.3.3. Combination of NAS-Initiated Replication with Other Capabilities 2913 NAS-initiated replication can coexist with the other capabilities, 2914 but some means must exist to prevent double replication of flows. 2915 The simplest way to do this is to terminate all IGMP/MLD requests on 2916 the AN, so that NAS-initiated replication is stimulated only by 2917 signalling through other channels. Other arrangements are possible, 2918 but need not be discussed here. 2920 Assuming the necessary separation of responsibilities, the only point 2921 of interaction between NAS-initiated replication and the other 2922 multicast capabilities is in the area of admission control. 2923 Specifically, if the AN is to do admission control for flows added by 2924 Multicast Replication Control messages, regardless of whether they 2925 are part of NAS-initiated replication or grey list multicast service 2926 processing, the NAS includes the MRepCtl-CAC TLV in a Provisioning 2927 message and the Bandwidth-Allocation TLV in a Port Management 2928 message. If instead the NAS will do admission control for flows 2929 added by Multicast Replication Control messages, regardless of 2930 whether they are part of NAS-initiated replication or grey list 2931 multicast service processing, it does not send the MRepCtl-CAC TLV in 2932 a Provisioning messages to the AN. The NAS can independently enable 2933 admission control for white flows on the AN by including the White- 2934 List-CAC TLV in the Provisioning message. 2936 6.3.4. Combinations of Committed Bandwidth Reporting with Other 2937 Multicast Capabilities 2939 Committed bandwidth reporting can take place independently of which 2940 other multicast capabilities have been negotiated. However, some 2941 combinations do not make sense because of redundancy. In particular, 2942 the NAS obtains the same information that committed bandwidth 2943 reporting gives if the only other capabilities operating are NAS- 2944 initiated replication and/or conditional access and admission control 2945 with grey lists. 2947 7. Miscellaneous Considerations 2949 This section deals with two sets of considerations. "Report 2950 Buffering Considerations" considers requirements for configuration in 2951 support of some of the Committed Bandwidth Reporting capability. 2952 "Congestion Considerations" is a warning to implementors about the 2953 possibility of control plane congestion, with suggestions for 2954 mitigation. 2956 7.1. Report Buffering Considerations 2958 The Committed Bandwidth Reporting capability allows the provisioning 2959 of a report buffering period to reduce the number of messages the AN 2960 passes to the NAS. An appropriate value for this period, if 2961 buffering is allowed at all, depends first on the effect of delay in 2962 reporting bandwidth changes, and secondly on the rate at which 2963 bandwidth changes are expected to occur. 2965 Let us assume in the first instance that a delay in adjusting 2966 hierarchical scheduling at the NAS causes additional bandwidth demand 2967 to be served momentarily on a best-effort basis, introducing the 2968 possibility of jitter and, more crucially, packet loss. ITU-T 2969 Recommendation G.1080 [ITU-T_G.1080] Appendix IV indicates that the 2970 maximum tolerable duration of a loss episode is less than 16 ms. 2971 This would more likely apply in the middle of a programme rather than 2972 when it was starting up, but at least gives an (extremely 2973 conservative) order of magnitude for setting the buffering period. 2975 The next question is whether enough messaging is likely to be 2976 generated that multiple bandwidth changes would be observed within 2977 such an interval. Let us consider a reasonable example in a DSL 2978 environment, where during the busiest hour of the day subscribers 2979 start watching at the rate of one programme per subscriber per hour. 2980 Typically, because of programme scheduling, the new channel requests 2981 might be concentrated within a three-minute period, giving an 2982 effective request rate of 1/(3 minutes * 60 seconds * 1000 ms/second) 2983 * 16 ms = 0.00009 requests per buffering interval of 16 ms. With 2984 these figures, an AN serving 10,000 subscribers will report an 2985 average of 0.9 bandwidth changes per 16 ms buffering interval. It 2986 appears that buffering is worthwhile only for larger-scale 2987 deployments. 2989 Note that simple replacement of one channel with another -- channel 2990 surfing -- does not require reporting or adjustment at the NAS end. 2992 7.2. Congestion Considerations 2994 Implementors must beware of the possibility that a single channel- 2995 surfing subscriber could generate enough control messaging to 2996 overload the AN or the messaging channel between the AN and the NAS. 2997 The implementation problem is to strike the right balance between 2998 minimizing the processing of requests that have been overtaken by 2999 subsequent events and meeting requirements for what is termed 3000 "channel zapping delay". Nominally such a requirement is to be found 3001 in [ITU-T_G.1080] Section 8.1, but unfortunately no quantitative 3002 value was available at the time of publication of this document. 3003 Implementors will therefore have to base their work on discussions 3004 with customers until standardized requirements do become available. 3005 (It is possible that regional bodies or more specialized bodies have 3006 overtaken the ITU-T in this regard.) 3008 A typical strategy for minimizing the work associated with request 3009 processing includes deliberate buffering of Join requests for a short 3010 period in case matching Release requests are detected, followed by 3011 discard of both requests. More generally, processing of requests 3012 from individual subscribers may be rate limited, and the global rate 3013 of messaging to the NAS can also be limited. If the AN gets 3014 overloaded, deliberate dropping of stale requests can be implemented, 3015 for some definition of "stale". 3017 8. Security Considerations 3019 The security considerations of ANCP are discussed in [RFC6320] and in 3020 [RFC5713]. Multicast does not in principle introduce any new 3021 security considerations, although it does increase the attractiveness 3022 of the ANCP protocol as a means of denial of service (e.g., through 3023 direction of multicast streams onto the target) or theft of service. 3025 As mentioned in Section 4.4, the inclusion of the Request-Source-MAC 3026 or Request-Source-IP TLV in the Multicast Admission Control message 3027 presents privacy issues. An attacker able to get access to the 3028 contents of this message would, like the content provider, be able to 3029 track consumption of multicast content to the individual device and 3030 potentially to individual persons if they are associated with 3031 particular devices. To make the connection between devices and 3032 individuals, the attacker needs to get information from sources other 3033 than ANCP, of course, but let us assume that this has happened. 3035 The protection specified for ANCP in [RFC6320] will apply to the 3036 transmission of the Multicast Admission Control message across the 3037 access network to the NAS. Hence the attacker's potential points of 3038 access are between the subscriber and the AN, at the AN and at the 3039 NAS. Moreover, if the MAC or IP address are transmitted onwards from 3040 the NAS to AAA in a request for policy, that whole onward path has to 3041 be examined for vulnerability. 3043 The question is how many of these potential points of attack can be 3044 eliminated through operational practice. The segment from the 3045 subscriber through the AN itself seems out of scope of this 3046 discussion -- protection of this segment is basic to subscriber 3047 privacy in any event, and likely a business requirement. The segment 3048 from the AN to the NAS is covered by the basic ANCP protection 3049 specified in RFC 6320. This leaves the NAS and the path between the 3050 NAS and AAA for consideration. 3052 The operator can eliminate the path between the NAS and AAA as a 3053 point where the attacker can access per-device information by 3054 downloading per-device policy to the NAS for all identified user 3055 devices for the particular subscriber. The NAS then selects the 3056 applicable policy based on the particular device identifier it has 3057 received. This is as opposed to the NAS sending the identifier of 3058 the device in question to AAA and getting policy just for that 3059 device. 3061 The alternative is to protect the path between the NAS and AAA. If 3062 Diameter is used as the AAA protocol, Section 2.2 of [RFC6733] 3063 mandates use of IPsec, TLS/TCP, or DTLS/SCTP for that purpose. If 3064 RADIUS is used, the operator should deploy TLS transport as specified 3065 in [RFC6614]. 3067 This leaves the NAS itself as a point of attack. In theory the NAS 3068 could be eliminated if the AN remapped the requesting MAC or IP 3069 address to an identifier known to itself and AAA, but not the NAS. 3070 This would require local configuration on the AN, which may be 3071 possible under some circumstances. The Request-Source-Device-Id TLV 3072 specified in Section 5.11 is available to transmit such an identifier 3073 in place of the Request-Source-MAC or Request-Source-IP. 3075 9. IANA Considerations 3077 IANA NOTE: Please replace XXXX with the RFC number of this document. 3079 This document defines the following additional values within the ANCP 3080 Message Type Name Space registry: 3082 +--------------+--------------------------------+-----------+ 3083 | Message Type | Message Name | Reference | 3084 +--------------+--------------------------------+-----------+ 3085 | 144 | Multicast Replication Control | RFC XXXX | 3086 | | | | 3087 | 145 | Multicast Admission Control | RFC XXXX | 3088 | | | | 3089 | 146 | Bandwidth Reallocation Request | RFC XXXX | 3090 | | | | 3091 | 147 | Bandwidth Transfer | RFC XXXX | 3092 | | | | 3093 | 148 | Delegated Bandwidth Query | RFC XXXX | 3094 | | | | 3095 | 149 | Multicast Flow Query | RFC XXXX | 3096 | | | | 3097 | 150 | Committed Bandwidth Report | RFC XXXX | 3098 +--------------+--------------------------------+-----------+ 3100 This document defines the following additional values for the ANCP 3101 Result Code registry. In support of these assignments, IANA is 3102 requested to change the lower limit of 0x100 specified by [RFC6320] 3103 for assignments by IETF Consensus to 0x64. 3105 +------------+------------------------------------------+-----------+ 3106 | Result | One-Line Description | Reference | 3107 | Code | | | 3108 +------------+------------------------------------------+-----------+ 3109 | 0x64 | Command error. | RFC XXXX | 3110 | | | | 3111 | 0x65 | Invalid flow address. | RFC XXXX | 3112 | | | | 3113 | 0x66 | Multicast flow does not exist. | RFC XXXX | 3114 | | | | 3115 | 0x67 | Invalid preferred bandwidth amount. | RFC XXXX | 3116 | | | | 3117 | 0x68 | Inconsistent views of delegated | RFC XXXX | 3118 | | bandwidth amount. | | 3119 | | | | 3120 | 0x69 | Bandwidth request conflict. | RFC XXXX | 3121 +------------+------------------------------------------+-----------+ 3123 This document defines the following additional values for the ANCP 3124 Command Code registry: 3126 +----------------+--------------------------------------+-----------+ 3127 | Command Code | Command Code Directive Name | Reference | 3128 | Value | | | 3129 +----------------+--------------------------------------+-----------+ 3130 | 1 | Add | RFC XXXX | 3131 | | | | 3132 | 2 | Delete | RFC XXXX | 3133 | | | | 3134 | 3 | Delete All | RFC XXXX | 3135 | | | | 3136 | 4 | Admission Control Reject | RFC XXXX | 3137 | | | | 3138 | 5 | Conditional Access Reject | RFC XXXX | 3139 | | | | 3140 | 6 | Admission Control and Conditional | RFC XXXX | 3141 | | Access Reject | | 3142 +----------------+--------------------------------------+-----------+ 3144 This document defines the following additional values within the ANCP 3145 TLV Type Registry: 3147 +-----------+--------------------------------+-----------+ 3148 | Type Code | TLV Name | Reference | 3149 +-----------+--------------------------------+-----------+ 3150 | 0x0013 | Multicast-Service-Profile | RFC XXXX | 3151 | | | | 3152 | 0x0015 | Bandwidth-Allocation | RFC XXXX | 3153 | | | | 3154 | 0x0016 | Bandwidth-Request | RFC XXXX | 3155 | | | | 3156 | 0x0018 | Multicast-Service-Profile-Name | RFC XXXX | 3157 | | | | 3158 | 0x0019 | Multicast-Flow | RFC XXXX | 3159 | | | | 3160 | 0x0021 | List-Action | RFC XXXX | 3161 | | | | 3162 | 0x0022 | Sequence-Number | RFC XXXX | 3163 | | | | 3164 | 0x0024 | White-List-CAC | RFC XXXX | 3165 | | | | 3166 | 0x0025 | MRepCtl-CAC | RFC XXXX | 3167 | | | | 3168 | 0x0092 | Request-Source-IP | RFC XXXX | 3169 | | | | 3170 | 0x0093 | Request-Source-MAC | RFC XXXX | 3171 | | | | 3172 | 0x0094 | Report-Buffering-Time | RFC XXXX | 3173 | | | | 3174 | 0x0095 | Committed-Bandwidth | RFC XXXX | 3175 | | | | 3176 | 0x0096 | Request-Source-Device-Id | RFC XXXX | 3177 +-----------+--------------------------------+-----------+ 3179 This document defines the following additional values for the ANCP 3180 Capability Type registry: 3182 +-------+-------------------------+--------+------------+-----------+ 3183 | Value | Capability Type Name | Tech | Capability | Reference | 3184 | | | Type | Data? | | 3185 +-------+-------------------------+--------+------------+-----------+ 3186 | 3 | NAS-Initiated | 0 | No | RFC XXXX | 3187 | | Replication | | | | 3188 | | | | | | 3189 | 5 | Committed Bandwidth | 0 | No | RFC XXXX | 3190 | | Reporting | | | | 3191 | | | | | | 3192 | 6 | Conditional Access With | 0 | No | RFC XXXX | 3193 | | White and Black Lists | | | | 3194 | | | | | | 3195 | 7 | Conditional Access With | 0 | No | RFC XXXX | 3196 | | Grey Lists | | | | 3197 | | | | | | 3198 | 8 | Bandwidth Delegation | 0 | No | RFC XXXX | 3199 +-------+-------------------------+--------+------------+-----------+ 3201 10. Acknowledgements 3203 The authors would like to acknowledge Wojciech Dec for providing 3204 useful input to this document, Robert Rennison for his help in 3205 shaping the definition of the Multicast-Service-Profile TLV, Shridhar 3206 Rao for his comments and suggestions and Aniruddha A for his proposal 3207 that formed the base of the Multicast Flow Reporting solution. 3208 Philippe Champagne, Sanjay Wadhwa and Stefaan De Cnodder provided 3209 substantial contributions on the solution for the NAS initiated 3210 multicast control use case. Kristian Poscic provided the committed 3211 bandwidth reporting use case. 3213 Thanks to the Document Shepherd, Matthew Bocci, and Area Director, 3214 Ted Lemon, for points raised by their reviews following Working Group 3215 Last Call. 3217 Further thanks to Dacheng Zhang, Mehmet Ersue, and Christer Holmberg 3218 for their reviews on behalf of the Security, Operations, and Gen-Art 3219 directorates. Dacheng's comments led to changes at several points in 3220 the draft, while Mehmet's led to creation of the Miscellaneous 3221 Considerations section. Finally, thanks to Brian Haberman for 3222 stimulating a review of the architectural assumptions and their 3223 relationship to the ability of user devices to obtain access to non- 3224 IPTV multicast services. This also led to changes in the draft. 3226 11. References 3228 11.1. Normative References 3230 [PIMreg] IANA, "http://www.iana.org/assignments/pim-parameters/pim- 3231 parameters.xhtml", 2005. 3233 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3234 Requirement Levels", BCP 14, RFC 2119, March 1997. 3236 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 3237 Listener Discovery (MLD) for IPv6", RFC 2710, October 3238 1999. 3240 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 3241 Thyagarajan, "Internet Group Management Protocol, Version 3242 3", RFC 3376, October 2002. 3244 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 3245 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 3247 [RFC6320] Wadhwa, S., Moisand, J., Haag, T., Voigt, N., and T. 3248 Taylor, "Protocol for Access Node Control Mechanism in 3249 Broadband Networks", RFC 6320, October 2011. 3251 11.2. Informative References 3253 [IEEE48] IEEE, "http://standards.ieee.org/regauth/oui/tutorials/ 3254 EUI48.html", 2010. 3256 [IEEE64] IEEE, "http://standards.ieee.org/regauth/oui/tutorials/ 3257 EUI64.html", 2010. 3259 [ITU-T_G.1080] 3260 ITU-T, "ITU-T Recommendation G.1080: Quality of experience 3261 requirements for IPTV services", December 2008. 3263 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 3264 2", RFC 2236, November 1997. 3266 [RFC3801] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet 3267 Mail - version 2 (VPIMv2)", RFC 3801, June 2004. 3269 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 3270 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 3271 Protocol Specification (Revised)", RFC 4601, August 2006. 3273 [RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security 3274 Threats and Security Requirements for the Access Node 3275 Control Protocol (ANCP)", RFC 5713, January 2010. 3277 [RFC5851] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. 3278 Wadhwa, "Framework and Requirements for an Access Node 3279 Control Mechanism in Broadband Multi-Service Networks", 3280 RFC 5851, May 2010. 3282 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 3283 "Transport Layer Security (TLS) Encryption for RADIUS", 3284 RFC 6614, May 2012. 3286 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 3287 "Diameter Base Protocol", RFC 6733, October 2012. 3289 Appendix A. Example of Messages and Message Flows 3291 This appendix provides an example in which most of the possible 3292 message flows for multicast control are illustrated. This appendix 3293 is for informational purposes only. In case of discrepancy with text 3294 of the body of this document, the text in the body of the document is 3295 to be considered as the normative text. 3297 Assume the following, for a given access port: 3299 o The basic subscribed service is white-listed. The AN will be 3300 responsible for admission control for this service. 3302 o Some premium services are available, but requests for these 3303 services must be referred to the policy server for proper credit 3304 processing. For this reason they are grey-listed. The NAS will 3305 be responsible for admission control for these services. 3307 o The subscriber has asked that certain services be blocked so that 3308 his children cannot view them. These services are black-listed. 3310 o All of the above services are Source-Specific Multicast (SSM). In 3311 addition, by means which bypass the AN, the subscriber can signal 3312 intent to join an on-line game service which is Any Source 3313 Multicast (ASM). The NAS is responsible for admission control for 3314 this service. 3316 o Bandwidth delegation is in effect to share video bandwidth between 3317 the AN and the NAS. 3319 The stated conditions require the use of four of the five 3320 capabilities specified in this memo. 3322 A.1. Provisioning Phase 3324 Assume that capability negotiation has been completed between the AN 3325 and NAS and that the set of negotiated capabilities includes the 3326 following four multicast capabilities: NAS-initiated replication, 3327 conditional access with white and black list, conditional access with 3328 grey list, and bandwidth delegation. At this point, the NAS can 3329 provision the service profiles on the AN and enable admission control 3330 at the AN for white-listed flows. To do this, the NAS sends the AN a 3331 Provisioning message containing this information. An example message 3332 providing the profile for our assumed subscriber is shown in 3333 Figure 21. The message has the following contents: 3335 o Message type is 93. 3337 o The Result and Result Code fields in the header are set to zeroes, 3338 as specified [RFC6320]. 3340 o A transaction identifier is assigned by the NAS. 3342 o The Multicast-Service-Profile TLV (of which typically there would 3343 be multiple instances) contains a Multicast-Service-Profile-Name 3344 TLV (with a length of 20 octets assumed for the example) and three 3345 List-Action TLVs, one each for the white, grey, and black lists 3346 within the profile. The white list flows come in two sets of 3347 group addresses: 233.252.0.0/29, coming from a server at 3348 192.0.2.15, and 233.252.0.32/29, coming from a server at 3349 192.0.2.16. The grey-listed flows are in the band 233.252.0.64/ 3350 29, coming from a server at 192.0.2.21. Finally, the black list 3351 flows are two individual flows that happen to overlap with the 3352 grey list band: 233.252.0.65, and 233.252.0.69, also with source 3353 192.0.2.21. 3355 o The White-List-CAC TLV indicates that the AN does admission 3356 control on white-listed flows. 3358 1 2 3 3359 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3361 | Type (0x880C) | Length = 132 | 3362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3363 | Version | Msg Type = 93 | Res=0 | Result Code = 0 | 3364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3365 | Partition ID | Transaction Identifier | 3366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3367 |I| SubMessage Number | Length = 132 | 3368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3369 | Mcast-Service-Profile 0x0013 | TLV Length = 112 | 3370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3371 | Mcast-Svc-Profile-Name 0x0018 | Embedded TLV Length = 20 | 3372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3373 | Multicast service profile name | 3374 ~ = "Cust 0127-53681-0003" ~ 3375 | | 3376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3377 | TLV Type = List-Action 0x0021 | Embedded TLV Length = 28 | 3378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3379 | Operation = 1 | List Type = 1 | Reserved = 0x0000 | 3380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3381 | Address Family = 1 | List Length = 20 | 3382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3383 | G Preflen = 29| S Preflen = 32| Group prefix = | 3384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3385 | 233.252.0.0 | Source prefix = | 3386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3387 | 192.0.2.15 | G Preflen = 29| S Preflen = 32| 3388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3389 | Group prefix = 233.252.0.32 | 3390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3391 | Source prefix = 192.0.2.15 | 3392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3393 | TLV Type = List-Action 0x0021 | Embedded TLV Length = 18 | 3394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3395 | Operation = 1 | List Type = 3 | Reserved = 0x0000 | 3396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3397 | Address Family = 1 | List Length = 10 | 3398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3399 | G Preflen = 29| S Preflen = 32| Group prefix = / 3400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3401 / 233.252.0.64 | Source prefix = / 3402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3403 / 192.0.2.21 | Padding = 0x0000 | 3404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3405 | TLV Type = List-Action 0x0021 | Embedded TLV Length = 28 | 3406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3407 | Operation = 1 | List Type = 2 | Reserved = 0x0000 | 3408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3409 | Address Family = 1 | List Length = 20 | 3410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3411 | G Preflen = 32| S Preflen = 32| Group prefix = / 3412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3413 / 233.252.0.65 | Source prefix = / 3414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3415 / 192.0.2.21 | G Preflen = 32| S Preflen = 32| 3416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3417 | Group prefix = 233.252.0.69 | 3418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3419 | Source prefix = 192.0.2.21 | 3420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3421 | Type = White-List-CAC 0x0024 | TLV Length = 0 | 3422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3424 Figure 21: Example Provisioning Message 3426 Note that the padding after the middle List-Action TLV is counted as 3427 part of length of the Multicast-Service-Profile TLV, but is not 3428 included in the length of that List-Action TLV. Note also that the 3429 Length field in the message header, unlike those in the TLVs, 3430 includes the message header itself, as required by [RFC6320]. 3431 Finally, note that the Provisioning message does not include a 3432 MRepCtl-CAC TLV since in our example admission control for grey 3433 listed flows and for NAS-initiated replication is performed by the 3434 NAS. 3436 As soon as the AN port comes up, the AN sends an ANCP PORT_UP message 3437 to the NAS specifying the Access Loop Circuit ID. The NAS replies 3438 with an ANCP Port Management message that, together with the other 3439 parameters, includes the multicast service profile name to be 3440 associated to that port along with the initial amount of delegated 3441 bandwidth. The corresponding message flow is illustrated in 3442 Figure 22. 3444 +----------+ +---------+ +-----+ +-----+ 3445 |Subscriber| | Home | | AN | | NAS | 3446 +----------+ | Gateway | +-----+ +-----+ 3447 | +---------+ | | 3448 | | | | 3449 | | | | 3450 | | DSL Synch. | | 3451 | |---------------->| | 3452 | | |(M1)PORT_UP(Port ID) | 3453 | | |-------------------->| 3454 | | | (*) 3455 | | |(M2) PORT_MNGT | 3456 | | | (Port ID, | 3457 | | |Mcast S Profile Name,| 3458 | | |Bandwidth Allocation)| 3459 | | |<--------------------| 3461 (*) The NAS may optionally seek direction from an external 3462 Autorization/Policy Server 3464 Figure 22: Configuring an AN Port With Multicast Service Profile ID 3465 and Delegated Bandwidth Amount 3467 The Port Management message will typically contain other TLVs but our 3468 example (Figure 23) just shows the Target, Multicast-Service-Profile- 3469 Name, and Bandwidth-Allocation TLVs. The Target TLV identifies the 3470 subscriber line, the Multicast-Service-Profile-Name TLV is identical 3471 to the one contained in the Provisioning message, and the Bandwidth- 3472 Allocation TLV provides just enough bandwidth (2000 kbits/s) for one 3473 channel to start with. 3475 The following fields in the Port Management message header are shown 3476 with specific values either as directed by the base protocol document 3477 or for the sake of our example: 3479 o Message Type is 32. 3481 o Result is set to Nack (0x1) for this example. 3483 o Result Code is 0. 3485 o A transaction identifier is assigned by the NAS. 3487 o Port is set to 0. 3489 o Event Sequence Number, the R flag and the other bits marked x, 3490 Duration, the Event Flags, and the Flow Control Flags are all 3491 irrelevant for this function and are set to 0. 3493 o Function is set to "Configure Connection Service Data" (8). 3495 o X-Function is set to 0. 3497 o Tech Type is "DSL" (5). 3499 o Block lengths are calculated assuming a Circuit-Id length of 4 in 3500 our example. Recall that the example Multicast-Service-Profile- 3501 Name TLV length is 20. 3503 1 2 3 3504 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3506 | Type (0x880C) | Length = 84 | 3507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3508 | Version | Msg Type = 32 | Res=1 | Result Code = 0 | 3509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3510 | Partition ID | Transaction Identifier | 3511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3512 |I| SubMessage Number | Length = 84 | 3513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3514 | Port = 0 | 3515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3516 | Port Session Number | 3517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3518 | Event Sequence Number = 0 | 3519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3520 |R|x|x|x|x|x|x|x| Duration = 0 | Function = 0x8| X-Function = 0| 3521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3522 | Event Flags | Flow Control Flags | 3523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3524 |x|x|x|x|x|x|x|x| Msg Type = 32 | Tech Type=5 | Blk Len = 56 | 3525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3526 | # of TLVs = 3 | Extension Block length = 44 | 3527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3528 | TLV Type = Target 0x1000 | Target TLV Length = 8 | 3529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3530 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3532 | Access Loop Circuit ID | 3533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3534 | Mcast-Svc-Profile-Name 0x0018 | TLV Length = 20 | 3535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3536 | Multicast service profile name | 3537 ~ = "Cust 0127-53681-0003" ~ 3538 | | 3539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3540 | Bandwidth-Allocation 0x0015 | TLV Length = 4 | 3541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3542 | Bandwidth value = 2000 (kbits/s) | 3543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3545 Figure 23: Example Port Management Message 3547 A.2. Handling a Grey-Listed Flow 3549 Suppose now that the subscriber chooses to watch the premium channel 3550 characterized by source 192.0.2.21, group 233.252.0.67. Upon 3551 receiving the Join request, the AN matches it against the multicast 3552 service profile for the port and determines that it is a grey-listed 3553 flow. Figure 24 illustrates the resulting ANCP message flow for the 3554 case of a simple join and leave, when admission control for grey- 3555 listed flows is not activated on the AN. 3557 To start the flow, the AN sends a Multicast Admission Control request 3558 (M1) to the NAS. The NAS decides whether flow can be admitted, 3559 applying both policy and bandwidth criteria. It returns its decision 3560 (positive in this example) in a Multicast Replication Control message 3561 (M2). Later, when the subscriber leaves the flow, the AN informs the 3562 NAS by sending another Multicast Admission Control message. 3564 +----------+ +-------+ +-----+ ANCP +-----+ 3565 |Subscriber| | Home | | AN |<---------->| NAS | 3566 +----------+ |Gateway| +-----+ +-----+ 3567 | +-------+ | | 3568 | | | Multicast | 3569 | Join(Grey-Fl) | Admission | 3570 |-----------+---------->| Control (M1) | 3571 | | |------------------>| 3572 | | | | (NAS performs 3573 | | | Multicast | admission 3574 | | | Replication (*) control) 3575 | | | Control (M2) | 3576 | Mcast Grey Flow |<------------------| 3577 |<======================+ | 3578 | | | | 3579 ~ ~ ~ ~ 3580 | | | Multicast | 3581 | Leave(Grey-Fl) | Admission | 3582 |-----------+---------->| Control (M3) | 3583 | | |------------------>| 3584 | | | | 3586 Grey-Fl : Multicast Flow matching an entry in grey List 3588 (*) The NAS may optionally seek direction from an external 3589 Authorization/Policy Server 3591 Figure 24: Successful Join/Leave Operations, Grey-Listed Flow 3593 The Multicast Admission Control message M1 contains: 3595 o an ANCP Header with: 3597 * Message Type is 145; 3599 * Result = Ignore (0x0); 3601 * a transaction identifier assigned by the AN. 3603 o a Target TLV identifying the AN Port 3605 o a Command TLV containing: 3607 * Command Code = "Add" (1); 3609 * Accounting = "No" (0); 3611 * a Multicast-Flow embedded TLV indicating the multicast flow for 3612 which the AN received the IGMP Join: flow type "SSM" (2), 3613 address family "IPv4" (1), Group address = 233.252.0.67, Source 3614 Address = 192.0.2.21; 3616 * a Request-Source-Device-Id embedded TLV containing the IGMP 3617 join source local device identifier value 5. 3619 The Multicast Admission Control message M1 is illustrated in 3620 Figure 25: 3622 1 2 3 3623 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3625 | Type (0x880C) | Length = 98 | 3626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3627 | Version | Msg Type=145 | Res=0 | Result Code = 0 | 3628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3629 | Partition ID | Transaction Identifier | 3630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3631 |I| SubMessage Number | Length = 98 | 3632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3633 | TLV Type = Target 0x1000 | Target TLV Length = 8 | 3634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3635 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3637 | Access Loop Circuit ID | 3638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3639 | TLV Type = Command 0x0011 | TLV Length = 28 | 3640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3641 | Cmd Code = 1 | Acctg = 0 | Reserved = 0x0000 | 3642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3643 | Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 | 3644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3645 | Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 | 3646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3647 | Multicast Group Address = 233.252.0.67 | 3648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3649 | Unicast Source Address = 192.0.2.21 | 3650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 3651 |Request-Source-Device-Id 0x0092| Embedded TLV length = 4 | 3652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3653 | Value = 5 | 3654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3656 Figure 25: Multicast Admission Control Message Seeking To Add A Flow 3658 The Multicast Replication Control message M2 contains: 3660 o an ANCP Header with: 3662 * Message Type = "Multicast Replication Control" (144); 3664 * Result= 0x1 (NAck); 3666 * a transaction identifier assigned by the NAS; 3668 o a Target TLV identifying the AN Port; 3669 o a Command TLV containing: 3671 * Command Code = "Add" (1); 3673 * Accounting = "Yes" (1), since in our example the operator wants 3674 accounting on this flow. 3676 * a Multicast-Flow embedded TLV indicating the multicast flow 3677 that the NAS is admitting for this access line: flow type "SSM" 3678 (2), address family "IPv4" (1), Group address = 233.252.0.67, 3679 Source Address = 192.0.2.21. 3681 The Multicast Admission Control message M2 is illustrated in 3682 Figure 26. 3684 1 2 3 3685 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3687 | Type (0x880C) | Length = 48 | 3688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3689 | Version | Msg Type=144 | Res=1 | Result Code = 0 | 3690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3691 | Partition ID | Transaction Identifier | 3692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3693 |I| SubMessage Number | Length = 48 | 3694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3695 | Target Type = 0x1000 | Target TLV Length = 8 | 3696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3697 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3699 | Access Loop Circuit ID | 3700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3701 | TLV Type = Command 0x0011 | TLV Length = 20 | 3702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3703 | Cmd Code = 1 | Acctg = 1 | Reserved = 0x0000 | 3704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3705 | Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 | 3706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3707 | Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 | 3708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3709 | Multicast Group Address = 233.252.0.67 | 3710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3711 | Unicast Source Address = 192.0.2.21 | 3712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3714 Figure 26: Multicast Replication Control Message Admitting A Flow 3716 The Multicast Admission Control message M3 advising the NAS that the 3717 flow has been terminated contains: 3719 o an ANCP Header with: 3721 * Message Type is 145; 3723 * Result = Ignore (0x0) 3725 * a transaction identifier assigned by the AN; 3727 o a Target TLV identifying the access line; 3729 o a Command TLV containing: 3731 * a Command Code = "Delete" (2); 3733 * Accounting = "No" (0); 3735 * a Multicast-Flow embedded TLV indicating the multicast flow for 3736 which the AN received the IGMP leave: flow type "SSM" (2), 3737 address family "IPv4" (1), Group address = 233.252.0.67, Source 3738 Address = 192.0.2.21. 3740 * a Request-Source-Device-Id embedded TLV containing the IGMP 3741 leave request source, the device identified by the local value 3742 5. 3744 The Multicast Admission Control message M3 is illustrated in 3745 Figure 27. 3747 1 2 3 3748 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3750 | Type (0x880C) | Length | 3751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3752 | Version | Msg Type=145 | Res=0 | Result Code = 0 | 3753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3754 | Partition ID | Transaction Identifier | 3755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3756 |I| SubMessage Number | Length | 3757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3758 | TLV Type = Target 0x1000 | Target TLV Length = 8 | 3759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3760 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3762 | Access Loop Circuit ID | 3763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3764 | TLV Type = Command 0x0011 | TLV Length = 28 | 3765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3766 | Cmd Code = 2 | Acctg = 0 | Reserved = 0x0000 | 3767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3768 | Multicast-Flow Type = 0x0019 | Embedded TLV Length = 12 | 3769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3770 | Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 | 3771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3772 | Multicast Group Address = 233.252.0.67 | 3773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3774 | Unicast Source Address = 192.0.2.21 | 3775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3776 |Request-Source-Device-Id 0x0092| Embedded TLV length = 4 | 3777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3778 | Value = 5 | 3779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3781 Figure 27: Multicast Admission Control Message Signalling Flow 3782 Termination 3784 A.3. Handling White-Listed Flows 3786 The NAS has enabled white list admission control on the AN, and the 3787 bandwidth delegation capability has been negotiated. White listed 3788 flows in themselves require no messages to the NAS, either upon 3789 admission or upon termination, but the AN may request an increase in 3790 the amount of delegated bandwidth if it needs the increase to admit a 3791 flow. 3793 Consider an example where the AN has already admitted one white- 3794 listed flow, thereby using up the initially provisioned amount of 3795 delegated bandwidth (2000 kbits/s). A request is received to join a 3796 new flow in the white list range. The AN chooses to send a Bandwidth 3797 Reallocation Request message to the NAS, requesting that the 3798 delegated bandwidth allocation be increased to 4000 kbits/s at a 3799 minimum, and preferably to 6000 kbits/s. 3801 In our example, the NAS is managing bandwidth tightly, as witnessed 3802 by its minimal initial allocation of just enough for one flow. It is 3803 willing to provide the minimum additional amount only, and therefore 3804 returns a Bandwidth Transfer message where the delegated bandwidth 3805 value is given as 4000 kbits/s. With this amount, the AN is able to 3806 admit the second white-listed flow. The AN could send a similar 3807 Bandwidth Transfer message back to the NAS bringing the delegated 3808 bandwidth amount back down to 2000 kbits/s when one of the flows is 3809 terminated, but this shows nothing new and is omitted. 3811 As one more point of illustration, suppose that the NAS chooses to 3812 audit the current amount of delegated bandwidth to ensure it is 3813 synchronized with the AN. It sends a Delegated Bandwidth Query 3814 request message to the AN, and receives a Delegated Bandwidth Query 3815 response message with the current allocation as the AN sees it. 3817 The complete message flow is shown in Figure 28. 3819 +----------+ +-------+ +-----+ ANCP +-----+ 3820 |Subscriber| | Home | | AN |<---------->| NAS | 3821 +----------+ |Gateway| +-----+ +-----+ 3822 | +-------+ | | 3823 | | | | 3824 | Join(White-F1) | | 3825 |-----------+---------->| | 3826 | | |AN performs | 3827 | Mcast White Flow 1 | admission control | 3828 |<======================+ | 3829 | | | | 3830 | Join(White-F2) | | 3831 |-----------+---------->|No bandwidth left | 3832 | | | | 3833 | | |Bandwidth | 3834 | | | Reallocation Req | 3835 | | |------------------>|(M1) 3836 | | | | 3837 | | | (*) 3838 | | |Bandwidth Transfer | 3839 | AN can now |<------------------|(M2) 3840 | admit flow | | 3841 | Mcast White Flow 2 | | 3842 |<======================+ | 3843 | | | | 3844 ~ ~ ~ ~ 3845 | | |Delegated Bandwidth| 3846 | | | Query request | 3847 | | |<------------------|(M3) 3848 | | | | 3849 | | |Delegated Bandwidth| 3850 | | | Query response | 3851 | | |------------------>|(M4) 3852 | | | | 3854 (*) The NAS may optionally seek direction from an external 3855 Authorization/Policy Server 3857 Figure 28: Successful Join/Leave Operations, White-Listed Flow 3859 The Bandwidth Reallocation Request message (M1) is shown in 3860 Figure 29. The contents require little explanation. The Message 3861 Type for the Bandwidth Reallocation Request is 146. The Result field 3862 is set to Ignore (0x0). Besides the Target, the message has one 3863 other TLV, the Bandwidth-Request, with a TLV Type of 0x0016. The TLV 3864 contains Required Amount and Preferred Amount fields, set to 4000 and 3865 6000 kbits/s respectively. 3867 1 2 3 3868 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3870 | Type (0x880C) | Length = 36 | 3871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3872 | Version | Msg Type=146 | Res=0 | Result Code = 0 | 3873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3874 | Partition ID | Transaction Identifier | 3875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3876 |I| SubMessage Number | Length = 36 | 3877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3878 | TLV Type = Target 0x1000 | Target TLV Length = 8 | 3879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3880 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3882 | Access Loop Circuit ID | 3883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3884 | Bandwidth-Request 0x0016 | TLV Length = 8 | 3885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3886 | Required Amount = 4000 (kbits/s) | 3887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3888 | Preferred Amount = 6000 (kbits/s) | 3889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3891 Figure 29: Bandwidth Reallocation Request Message 3893 The Bandwidth Transfer message (M2) is shown in Figure 30. Again, 3894 the contents are easily understood. The Message Type for the 3895 Bandwidth Transfer message is 147. The Result field is set to 3896 Success (0x3). The message contains the Target TLV and the 3897 Bandwidth-Allocation TLV. The latter has a TLV Type of 0x0015 and 3898 contains a Delegated Amount field, set to 4000 kbits/s. 3900 1 2 3 3901 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3903 | Type (0x880C) | Length = 32 | 3904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3905 | Version | Msg Type=147 | Res=3 | Result Code = 0 | 3906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3907 | Partition ID | Transaction Identifier | 3908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3909 |I| SubMessage Number | Length = 32 | 3910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3911 | TLV Type = Target 0x1000 | Target TLV Length = 8 | 3912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3913 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3915 | Access Loop Circuit ID | 3916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3917 | Bandwidth-Allocation 0x0015 | TLV Length = 4 | 3918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3919 | Delegated Amount = 4000 (kbits/s) | 3920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3922 Figure 30: NAS Response, Bandwidth Transfer Message 3924 The Delegated Bandwidth Query request message (M3) is shown in 3925 Figure 31. The Message Type for the Delegated Bandwidth Query 3926 request message is 148. The Result field is set to AckAll (0x2). 3927 The message contains the Target TLV only. 3929 1 2 3 3930 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3932 | Type (0x880C) | Length = 24 | 3933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3934 | Version | Msg Type=148 | Res=2 | Result Code = 0 | 3935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3936 | Partition ID | Transaction Identifier | 3937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3938 |I| SubMessage Number | Length = 24 | 3939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3940 | TLV Type = Target 0x1000 | Target TLV Length = 8 | 3941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3942 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3944 | Access Loop Circuit ID | 3945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3947 Figure 31: Delegated Bandwidth Query Request Message 3949 Finally, the Delegated Bandwidth Query response message (M4) is shown 3950 in Figure 32. The Message Type for the Delegated Bandwidth Query 3951 response message is 148. The Result field is set to Success (0x3). 3952 The message contains the Target TLV and the Bandwidth-Allocation TLV 3953 with the Delegated Amount field set to 4000 kbits/s. 3955 1 2 3 3956 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3958 | Type (0x880C) | Length = 32 | 3959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3960 | Version | Msg Type=148 | Res=2 | Result Code = 0 | 3961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3962 | Partition ID | Transaction Identifier (copied from request) | 3963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3964 |I| SubMessage Number | Length = 32 | 3965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3966 | TLV Type = Target 0x1000 | Target TLV Length = 8 | 3967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3968 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3970 | Access Loop Circuit ID | 3971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3972 | Bandwidth-Allocation 0x0015 | TLV Length = 4 | 3973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3974 | Delegated Amount = 4000 (kbits/s) | 3975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3977 Figure 32: Delegated Bandwidth Query Response Message 3979 A.4. Handling Of Black-Listed Join Requests 3981 This section introduces no new messages, since requests for flows in 3982 the black list are simply ignored. The one thing to point out is the 3983 overlap in our example between the set of flows in the grey list and 3984 the flows in the black list. This does not create any ambiguity, 3985 since not only does the black list have priority for equally good 3986 matches, but also the black list entries are more specific (group 3987 prefix lengths of 32 versus 29 in the grey list) than the grey list 3988 flow prefixes. 3990 A.5. Handling Of Requests To Join and Leave the On-Line Game 3992 The final class of multicast control actions in our example allows 3993 the subscriber to enter and leave the on-line game. As described at 3994 the beginning of this example, the game uses Any Source Multicast 3995 (ASM). Subscriber signalling bypasses the AN, going directly to the 3996 NAS (e.g., through a web interface). 3998 When the subscriber requests to join the game, the NAS (after 3999 applying policy and bandwidth checks) sends a Multicast Replication 4000 Control message to the AN to enable the flow on the port concerned. 4001 The AN knows not to apply admission control, since it has not 4002 received an MRepCtl-CAC TLV in the Provisioning message. When the 4003 subscriber leaves, the NAS sends another Multicast Replication 4004 Control message to delete the flow. This message sequence is shown 4005 in Figure 33. 4007 It is possible that the NAS finds that there is not enough bandwidth 4008 available to accommodate the subscriber's request. In this case, the 4009 NAS could send a Bandwidth Reallocation Request message to the AN, 4010 asking it to release some of the bandwidth delegated to it. This is 4011 not shown in the present example, since the messages are the same as 4012 those already presented with the exception that the Preferred Amount 4013 in the request will be *less than* or equal to the Required amount, 4014 rather than *greater than* or equal to it. 4016 +----------+ +-------+ +-----+ ANCP +-----+ 4017 |Subscriber| | Home | | AN |<---------->| NAS | 4018 +----------+ |Gateway| +-----+ +-----+ 4019 | +-------+ | | 4020 | | | | 4021 | Join game | | 4022 |-----------+------------------------------>| 4023 | | | Multicast | NAS performs 4025 | | | Replication (*) admission 4026 | | | Control (M1) | control 4027 | Mcast Game Flow |<------------------| 4028 |<=====================>+ | 4029 | | | | 4030 ~ ~ ~ ~ 4031 | | | | 4032 | Leave game | | 4033 |-----------+------------------------------>| 4034 | | | Multicast | 4035 | | | Replication | 4036 | | | Control (M2) | 4037 | Mcast Game Flow |<------------------| 4038 | discontinued | | 4039 | | | | 4041 (*) The NAS may optionally seek direction from an external 4042 Authorization/Policy Server 4044 Figure 33: NAS-Initiated Flows For On-Line Gaming 4046 Multicast Replication Control message (M1) in Figure 34 looks like 4047 the message in Figure 26 with two exceptions. The first is that the 4048 NAS has the option to set the Result field to AckAll (0x02) if it 4049 needs positive reassurance that the flow has been enabled. This was 4050 not done here to save having to depict a response differing only in 4051 the Result field. The larger difference in this example is that the 4052 flow description in the Multicast-Flow embedded TLV is that of an ASM 4053 multicast group (Flow Type = 1) with IPv4 (1) group address 4054 233.252.0.100. 4056 1 2 3 4057 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 4058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4059 | Type (0x880C) | Length = 44 | 4060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4061 | Version | Msg Type=144 | Res=1 | Result Code = 0 | 4062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4063 | Partition ID | Transaction Identifier | 4064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4065 |I| SubMessage Number | Length = 44 | 4066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4067 | TLV Type = Target 0x1000 | Target TLV Length = 8 | 4068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4069 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 4070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4071 | Access Loop Circuit ID | 4072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4073 | TLV Type = Command 0x0011 | TLV Length = 16 | 4074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4075 | Cmd Code = 1 | Acctg = 1 | Reserved = 0x0000 | 4076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4077 | Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 | 4078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4079 | Flow Type = 1 | Addr Fam = 1 | Reserved = 0x0000 | 4080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4081 | Multicast Group Address = 233.252.0.100 | 4082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 4084 Figure 34: Enabling The Subscriber To Join An On-Line Game 4086 Message M2 terminating the flow when the subscriber leaves the game 4087 looks the same as the message in Figure 34 with two exceptions: the 4088 Command Code becomes "Delete" (2), and Accounting is set to "No" (0) 4089 to turn off flow accounting. Of course, the Transaction Identifier 4090 values will differ between the two messages. 4092 A.6. Example Flow For Multicast Flow Reporting 4094 The example in this section is independent of the example in the 4095 preceding sections. 4097 Figure 35 illustrates a message flow in a case where the NAS queries 4098 the AN about which multicast flows are active on port 10, on port 11 4099 and on port 20 of the AN. 4101 +----------+ +-------+ +-----+ ANCP +-----+ 4102 |Subscriber| | Home | | AN |<---------->| NAS | 4103 +----------+ |Gateway| +-----+ +-----+ 4104 | +-------+ | | 4105 | | | Multicast Flow | 4106 | | | Query Request | 4107 | | | (M1) | 4108 | | |<------------------| 4109 | | | | 4110 | | | Multicast Flow | 4111 | | | Query Response | 4112 | | | (M2) | 4113 | | |------------------>| 4114 | | | | 4115 | | | | 4117 Figure 35: Per-Port Multicast Flow Reporting 4119 The Multicast Flow Query Request message (M1) is illustrated in 4120 Figure 36. The Message Type is 149. The Result field is set to 4121 AckAll (0x2). Three Target TLVs are present, identifying port 10, 4122 port 20, and port 11 respectively. 4124 0 1 2 3 4125 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 4126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4127 | Type (0x880C) | Length | 4128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4129 | Version | Msg Type = 149| Res=1 | Result Code = 0 | 4130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4131 | Partition ID | Transaction Identifier | 4132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4133 |I| SubMessage Number | Length | 4134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4135 | TLV Type = Target 0x1000 | Target TLV Length | 4136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4137 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 4138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4139 | | 4140 ~ Access Loop Circuit ID (port10) ~ 4141 | | 4142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4143 | TLV Type = Target 0x1000 | Target TLV Length | 4144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4145 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 4146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4147 | | 4148 ~ Access Loop Circuit ID (port20) ~ 4149 | | 4150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4151 | TLV Type = Target 0x1000 | Target TLV Length | 4152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4153 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 4154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4155 | | 4156 ~ Access Loop Circuit ID (port11) ~ 4157 | | 4158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4160 Figure 36: Multicast Flow Query Request Message For Per-Port 4161 Multicast Flow Reporting 4163 The Multicast Flow Query Response message (M2) is illustrated in 4164 Figure 37. It indicates that there is one active multicast flow 4165 [(192.0.2.1, 233.252.0.4)] on port 10, no active multicast flow on 4166 port 20 and two active multicast flows [(192.0.2.1, 233.252.0.4) and 4167 (192.0.2.2, 233.252.0.10)] on port 11. 4169 0 1 2 3 4170 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 4171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4172 | Type (0x880C) | Length | 4173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4174 | Version | Msg Type = 149|Rslt=3 | Result Code = 0 | 4175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4176 | Partition ID | Transaction Identifier | 4177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4178 |I| SubMessage Number | Length | 4179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4180 | TLV Type = Target 0x1000 | Target TLV Length | 4181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4182 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 4183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4184 | | 4185 ~ Access Loop Circuit ID (port10) ~ 4186 | | 4187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4188 | Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 | 4189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4190 | Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 | 4191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4192 | Multicast Group Address = 233.252.0.4 | 4193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4194 | Unicast Source Address = 192.0.2.1 | 4195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 4196 | TLV Type = Target 0x1000 | Target TLV Length | 4197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4198 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 4199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4200 | | 4201 ~ Access Loop Circuit ID (port20) ~ 4202 | | 4203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4204 | TLV Type = Target 0x1000 | Target TLV Length | 4205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4206 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 4207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4208 | | 4209 ~ Access Loop Circuit ID (port11) ~ 4210 | | 4211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4212 | Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 | 4213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4214 | Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 | 4215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4216 | Multicast Group Address = 233.252.0.4 | 4217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4218 | Unicast Source Address = 192.0.2.1 | 4219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 4220 | Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 | 4221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4222 | Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 | 4223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4224 | Multicast Group Address: 233.252.0.10 | 4225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4226 | Unicast Source Address = 192.0.2.2 | 4227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 4229 Figure 37: Multicast Flow Query Response message For Per- Port 4230 Multicast Flow Reporting 4232 Authors' Addresses 4234 Francois Le Faucheur 4235 Cisco Systems 4236 Greenside, 400 Avenue de Roumanille 4237 Sophia Antipolis 06410 4238 France 4240 Phone: +33 4 97 23 26 19 4241 Email: flefauch@cisco.com 4243 Roberta Maglione 4244 Cisco Systems 4245 181 Bay Street 4246 Toronto, ON M5J 2T3 4247 Canada 4249 Email: robmgl@cisco.com 4251 Tom Taylor 4252 Huawei Technologies 4253 Ottawa 4254 Canada 4256 Email: tom.taylor.stds@gmail.com