idnits 2.17.1 draft-ietf-ancp-mc-extensions-13.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 (December 10, 2013) is 3789 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'TR-146' 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: June 13, 2014 T. Taylor 7 Huawei 8 December 10, 2013 10 Multicast Control Extensions for ANCP 11 draft-ietf-ancp-mc-extensions-13.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 with white and black lists; 25 o conditional access with grey lists; 27 o bandwidth delegation; 29 o committed bandwidth reporting. 31 These capabilities may be combined according to the rules given in 32 this specification. 34 This document updates RFC 6320 by assigning capability type 3 to a 35 capability specified in this document and by changing the starting 36 point for IANA allocation of result codes determined by IETF 37 Consensus from 0x100 to 0x64. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on June 13, 2014. 56 Copyright Notice 58 Copyright (c) 2013 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 3. Multicast Use Cases . . . . . . . . . . . . . . . . . . . . . 6 76 3.1. NAS Initiated Multicast Replication Control Use Case . . 7 77 3.1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 7 78 3.1.2. Message Flow . . . . . . . . . . . . . . . . . . . . 7 79 3.2. Conditional Access and Admission Control Use Case . . . . 8 80 3.2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 8 81 3.2.2. Message Flow . . . . . . . . . . . . . . . . . . . . 8 82 3.3. Multicast Flow Reporting Use Case . . . . . . . . . . . . 9 83 3.3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 9 84 3.3.2. Message Flow . . . . . . . . . . . . . . . . . . . . 10 85 3.4. Committed Bandwidth Reporting Use Case . . . . . . . . . 10 86 3.4.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 10 87 3.4.2. Message Flow . . . . . . . . . . . . . . . . . . . . 11 88 4. ANCP Messages . . . . . . . . . . . . . . . . . . . . . . . . 11 89 4.1. Provisioning Message . . . . . . . . . . . . . . . . . . 12 90 4.1.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 12 91 4.1.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 13 92 4.2. Port Management Message . . . . . . . . . . . . . . . . . 14 93 4.2.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 15 94 4.2.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 15 95 4.3. Multicast Replication Control Message . . . . . . . . . . 16 96 4.3.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 19 97 4.3.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 20 98 4.4. Multicast Admission Control Message . . . . . . . . . . . 22 99 4.4.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 23 100 4.4.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 24 101 4.5. Bandwidth Reallocation Request Message . . . . . . . . . 25 102 4.5.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 25 103 4.5.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 26 104 4.6. Bandwidth Transfer Message . . . . . . . . . . . . . . . 29 105 4.6.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 29 106 4.6.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 30 107 4.7. Delegated Bandwidth Query Request Message . . . . . . . . 31 108 4.7.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 31 109 4.7.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 32 110 4.8. Delegated Bandwidth Query Response Message . . . . . . . 32 111 4.8.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 32 112 4.8.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 32 113 4.9. Multicast Flow Query Request and Response Messages . . . 33 114 4.9.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 34 115 4.9.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 34 116 4.10. Committed Bandwidth Report Message . . . . . . . . . . . 36 117 4.10.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 36 118 4.10.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 36 119 5. ANCP TLVs For Multicast . . . . . . . . . . . . . . . . . . . 37 120 5.1. Multicast-Service-Profile TLV . . . . . . . . . . . . . . 37 121 5.2. Multicast-Service-Profile-Name TLV . . . . . . . . . . . 38 122 5.3. List-Action TLV . . . . . . . . . . . . . . . . . . . . . 39 123 5.4. Sequence-Number TLV . . . . . . . . . . . . . . . . . . . 41 124 5.5. Bandwidth-Allocation TLV . . . . . . . . . . . . . . . . 42 125 5.6. White-List-CAC TLV . . . . . . . . . . . . . . . . . . . 42 126 5.7. MRepCtl-CAC TLV . . . . . . . . . . . . . . . . . . . . . 43 127 5.8. Bandwidth-Request TLV . . . . . . . . . . . . . . . . . . 43 128 5.9. Subs-Session-Id TLV . . . . . . . . . . . . . . . . . . . 44 129 5.10. Multicast-Flow TLV . . . . . . . . . . . . . . . . . . . 45 130 5.11. Report-Buffering-Time TLV . . . . . . . . . . . . . . . . 46 131 5.12. Committed-Bandwidth TLV . . . . . . . . . . . . . . . . . 46 132 6. Multicast Capabilities . . . . . . . . . . . . . . . . . . . 47 133 6.1. Required Protocol Support . . . . . . . . . . . . . . . . 48 134 6.1.1. Protocol Requirements For NAS-Initiated Replication . 48 135 6.1.2. Protocol Requirements For Committed Multicast 136 Bandwidth Reporting . . . . . . . . . . . . . . . . . 49 137 6.1.3. Protocol Requirements For Conditional Access With 138 White and Black Lists . . . . . . . . . . . . . . . . 50 139 6.1.4. Protocol Requirements For Conditional Access With 140 Grey Lists . . . . . . . . . . . . . . . . . . . . . 51 141 6.1.5. Protocol Requirements For Delegated Bandwidth . . . . 52 142 6.2. Capability-Specific Procedures for Providing Multicast 143 Service . . . . . . . . . . . . . . . . . . . . . . . . . 53 144 6.2.1. Procedures For NAS-Initiated Replication . . . . . . 53 145 6.2.2. Procedures For Committed Bandwidth Reporting . . . . 54 146 6.2.3. Procedures For Conditional Access With Black and 147 White Lists . . . . . . . . . . . . . . . . . . . . . 55 148 6.2.4. Procedures For Conditional Access With Grey Lists . . 57 149 6.2.5. Procedures For Delegated Bandwidth . . . . . . . . . 58 150 6.3. Combinations of Multicast Capabilities . . . . . . . . . 59 151 6.3.1. Combination of Conditional Access With White and 152 Black Lists and Conditional Access With Grey Lists . 59 153 6.3.2. Combination of Conditional Access With Delegated 154 Bandwidth . . . . . . . . . . . . . . . . . . . . . . 60 155 6.3.3. Combination of NAS-Initiated Replication with Other 156 Capabilities . . . . . . . . . . . . . . . . . . . . 61 157 6.3.4. Combinations of Committed Bandwidth Reporting with 158 Other Multicast Capabilities . . . . . . . . . . . . 61 159 7. Security Considerations . . . . . . . . . . . . . . . . . . . 61 160 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 161 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 65 162 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 65 163 10.1. Normative References . . . . . . . . . . . . . . . . . . 65 164 10.2. Informative References . . . . . . . . . . . . . . . . . 66 165 Appendix A. Example of Messages and Message Flows . . . . . . . 66 166 A.1. Provisioning Phase . . . . . . . . . . . . . . . . . . . 67 167 A.2. Handling a Grey-Listed Flow . . . . . . . . . . . . . . . 72 168 A.3. Handling White-Listed Flows . . . . . . . . . . . . . . . 78 169 A.4. Handling Of Black-Listed Join Requests . . . . . . . . . 83 170 A.5. Handling Of Requests To Join and Leave the On-Line Game . 83 171 A.6. Example Flow For Multicast Flow Reporting . . . . . . . . 85 172 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 89 174 1. Introduction 176 [RFC5851] defines a framework and requirements for an Access Node 177 control mechanism between a Network Access Server (NAS) and an Access 178 Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)) in a 179 multi-service reference architecture in order to perform QoS-related, 180 service-related and subscriber-related operations. [RFC6320] 181 specifies a protocol for Access Node Control in broadband networks in 182 line with this framework. 184 [RFC6320] supports three use cases defined in [RFC5851], specifically 185 for DSL access: the DSL Topology Discovery use case, the DSL Line 186 Configuration use case and the DSL Remote Connectivity Test use case. 187 However, it does not support the multicast use cases defined in 188 [RFC5851]. The present document specifies the extensions to the 189 Access Node Control Protocol required for support of these multicast 190 use cases. In addition, it supports the Committed Bandwidth 191 Reporting use case, described below. In terms of the ANCP protocol, 192 these use cases are organized into five capabilities: 194 o NAS-initiated multicast replication; 196 o conditional access with white and black lists; 198 o conditional access with grey lists; 200 o bandwidth delegation; 202 o committed bandwidth reporting. 204 NAS-initiated multicast replication assumes that multicast "join" and 205 "leave" requests are terminated on the NAS, or that the NAS receives 206 requests to establish multicast sessions through other means (e.g., 207 application-level signalling). The NAS sends commands to the AN to 208 start or stop replication of specific multicast flows on specific 209 subscriber ports. This use case is described briefly in the next-to- 210 last paragraph of Section 3.4 of [RFC5851]. 212 Conditional access is described in Section 3.4.1 and Section 3.4.2.3 213 of [RFC5851], with the latter section particularly applicable to 214 operation with white and black lists only. In case of "conditional 215 access with white and black lists", multicast join and leave requests 216 are terminated at the AN and accepted or ignored in accordance with 217 the direction provided by white and black lists respectively. The 218 white and black lists are provisioned per port at startup time and 219 may be modified thereafter. The NAS may enable admission control of 220 white-listed flows by appropriate provisioning. 222 Conditional access with grey lists is similar to conditional access 223 with white lists, except that before accepting any request matching a 224 grey list entry, the AN sends a request to the NAS for permission to 225 replicate the flow. Again, the NAS can enable admission control of 226 grey-listed flows at the AN. 228 Bandwidth delegation is described in Section 3.4.2.1 of [RFC5851]. 229 It allows flexible sharing of total video bandwidth on an access line 230 between the AN and the NAS. One application of such bandwidth 231 sharing is where the AN does multicast admission control, while the 232 NAS or Policy Server does unicast admission control. In that case, 233 bandwidth delegation allows dynamic sharing of bandwidth between 234 unicast and multicast video traffic on each access line. 236 Committed bandwidth reporting is described below, in Section 3.4. 237 The AN reports the amount of multicast bandwidth it has granted to a 238 given access line each time that value changes. These reports may be 239 buffered for a NAS-provisionable interval so that reports for 240 multiple access lines can be bundled into the same message. 242 The formal specification of the behaviours associated with each of 243 these capabilities, singly and in combination, is given in Section 6. 245 In addition to the multicast service processing behaviour just 246 sketched, the definition of each capability includes support for the 247 multicast accounting and reporting services described in 248 Section 3.4.3 of [RFC5851]. Because of this common content and 249 because of other protocol overlaps between the different 250 capabilities, the protocol descriptions for the multicast extensions 251 specified in this document are merged into a single non-redundant 252 narrative. Tables in Section 6 then indicate the specific sub- 253 sections of the protocol description that have to be implemented to 254 support each capability. 256 This document updates RFC 6320 by assigning capability type 3 to the 257 NAS-initiated multicast replication capability and by changing the 258 starting point for IANA allocation of result codes determined by IETF 259 Consensus from 0x100 to 0x64. 261 2. Terminology 263 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 264 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 265 document are to be interpreted as described in [RFC2119]. 267 Within this document, the term "conditional access and admission 268 control (CAC)" refers to the complete decision process for allowing 269 or disallowing a subscriber request for a new flow. This process 270 consists of two parts: policy-based admission control and resource- 271 based admission control. The NAS can delegate policy-based admission 272 control to the Access Node if both devices support conditional access 273 with white and black lists. It can delegate resource-based admission 274 control to the Access Node if both devices support any of the 275 capabilities described in this document besides or other than 276 committed bandwidth reporting. The delegation is performed on a per- 277 subscriber basis using the Provisioning (Section 4.1) and Port 278 Management (Section 4.2) messages. 280 The expression "delegated bandwidth" is used as a shorter way of 281 saying: "the total amount of video bandwidth delegated to the AN for 282 multicast resource-based admission control". 284 3. Multicast Use Cases 286 Quoting from [RFC5851]: 288 "... the Access Node, aggregation node(s) and the NAS must all be 289 involved in the multicast replication process. This avoids that 290 several copies of the same stream are sent within the access/ 291 aggregation network. In case of an Ethernet-based access/aggregation 292 network, this may, for example, be achieved by means of IGMP snooping 293 or IGMP proxy in the Access Node and aggregation node(s). By 294 introducing IGMP processing in the access/aggregation nodes, the 295 multicast replication process is now divided between the NAS, the 296 aggregation node(s) and Access Nodes. In order to ensure backward 297 compatibility with the ATM-based model, the NAS, aggregation node and 298 Access Node need to behave as a single logical device. This logical 299 device must have exactly the same functionality as the NAS in the ATM 300 access/aggregation network. The Access Node Control Mechanism can be 301 used to make sure that this logical/functional equivalence is 302 achieved by exchanging the necessary information between the Access 303 Node and the NAS." 305 [RFC5851] describes the use cases for ANCP associated with such 306 multicast operations, and identifies the associated ANCP 307 requirements. The present section describes a subset of these use 308 cases as background to facilitate reading of this document, but the 309 reader is referred to [RFC5851] for a more exhaustive description of 310 the ANCP multicast use cases. Detailed example message flows can 311 also be found in Appendix A. 313 3.1. NAS Initiated Multicast Replication Control Use Case 315 3.1.1. Goals 317 One option for multicast handling is for the subscriber to 318 communicate the "join/leave" information to the NAS. This can be 319 done for instance by terminating all subscriber IGMP ([RFC3376]) or 320 MLD ([RFC2710], [RFC3810]) signaling on the NAS. Another example 321 could be a subscriber using some form of application level signaling, 322 which is redirected to the NAS. In any case, this option is 323 transparent to the access and aggregation network. In this scenario, 324 the NAS uses ANCP to create and remove replication state in the AN 325 for efficient multicast replication. Thus, the NAS only sends a 326 single copy of the multicast stream towards the AN, which in turn 327 performs replication to multiple subscribers as instructed by the NAS 328 via ANCP. The NAS performs conditional access and admission control 329 when processing multicast join requests, and only creates replication 330 state in the AN if admission succeeds. 332 3.1.2. Message Flow 334 With the NAS-initiated use case, a Multicast Replication Control 335 Message is sent by the NAS to the AN with a directive to either join 336 or leave one (or more) multicast flow(s). In the example message 337 flow, the AN uses a Generic Response message to convey the outcome of 338 the directive. Figure 1 illustrates such an ANCP message exchange as 339 well as the associated AN behavior. 341 +----------+ +-------+ +-----+ ANCP +-----+ 342 |Subscriber| | Home | | AN |<-------------------->| NAS | 343 +----------+ |Gateway| +-----+ +-----+ 344 | +-------+ | | 345 | | | (*) 346 | | | Multicast-Replication-Ctl | 347 | | | (Target,add, Flow 1) | 348 | | |<--------------------------| 349 | Mcast Flow 1 | | 350 |<==========================+ | 351 | | | Generic Response | 352 | | |-------------------------->| 353 | | | | 354 | | | | 355 ~ ~ ~ ~ 356 | | | | 357 | | | Multicast-Replication-Ctl | 358 | | | (Target,delete, Flow 1) | 359 | | |<--------------------------| 360 | | | | 361 | | Generic Response | 363 | | |-------------------------->| 365 (*) The NAS may optionally seek direction from an external 366 Authorization/Policy Server before admitting the flow. 368 Figure 1: NAS Initiated Multicast Replication Control 370 3.2. Conditional Access and Admission Control Use Case 372 3.2.1. Goals 374 One option for multicast handling is for the access/aggregation nodes 375 to participate in IGMP/MLD processing (e.g. via IGMP/MLD snooping). 376 In this scenario, on detecting a join/leave request from an end user 377 for a multicast flow (in the grey list), the AN uses ANCP to request 378 a conditional access and admission control decision from the NAS. In 379 turn, after conditional access and admission control checks, the NAS 380 uses ANCP to instruct the AN to change the replication states 381 accordingly. 383 3.2.2. Message Flow 384 For support of the conditional access and admission control use case, 385 on detection of an IGMP/MLD Join, the AN sends an Admission Control 386 message to the NAS to request a conditional access and admission 387 control check. In the case of a positive outcome, the NAS sends a 388 Multicast Replication Control Message to the AN with a directive to 389 replicate the multicast flow to the corresponding user. Similarly on 390 detection of an IGMP/MLD leave, an Admission Control message is sent 391 by the AN to the NAS to keep the NAS aware of user departure for the 392 flow. This message flow is illustrated in Figure 2. 394 +----------+ +-------+ +-----+ ANCP +-----+ 395 |Subscriber| | Home | | AN |<------------------->| NAS | 396 +----------+ |Gateway| +-----+ +-----+ 397 | +-------+ | | 398 | | | | 399 | Join(Gr-Flow1) | Admission-Control | 400 |------------+---------->| (Target,add,Gr-Flow1) | 401 | | |-------------------------->| 402 | | | (*) 403 | | | Multicast-Replication-Crl | 404 | | | (Target,add,Gr-Flow1) | 405 | | |<--------------------------| 406 | Mcast Gr-Flow1 | | 407 |<=======================+ | 408 | | | | 409 ~ ~ ~ ~ 410 | | | | 411 | Leave(Gr-Flow1) | Admission-Control | 412 |------------+---------->| (Target,delete,Gr-Flow1) | 413 | | |-------------------------->| 414 | | | 416 | | | | 418 Gr-Flow1: a multicast flow matching the grey list for that port 420 (*) The NAS may optionally seek direction from an external 421 Authorization/Policy Server before admitting the flow. 423 Figure 2: Multicast Conditional Access and Admission Control 425 3.3. Multicast Flow Reporting Use Case 427 3.3.1. Goals 428 The Multicast flow reporting use case allows the NAS to 429 asynchronously query the AN to obtain an instantaneous status report 430 related to multicast flows currently replicated by the AN. 432 3.3.2. Message Flow 434 The NAS sends a Multicast Flow Query Request message to the AN in 435 order to query the AN about information such as which multicast flows 436 are currently active on a given AN port or which ports are currently 437 replicating a given multicast flow. The AN conveys the requested 438 information to the NAS in a Multicast Flow Query Response message. 439 This message flow is illustrated in Figure 3. 441 +----------+ +-------+ +-----+ ANCP +-----+ 442 |Subscriber| | Home | | AN |<---------->| NAS | 443 +----------+ |Gateway| +-----+ +-----+ 444 | +-------+ | | 445 | | | Multicast Flow | 446 | | | Query Request | 447 | | |<------------------| 448 | | | | 449 | | | Multicast Flow | 450 | | | Query Response | 451 | | |------------------>| 452 | | | | 453 | | | | 455 Figure 3: Multicast Flow Reporting 457 3.4. Committed Bandwidth Reporting Use Case 459 3.4.1. Goals 461 The committed bandwidth reporting use case allows the NAS to maintain 462 current awareness of how much multicast bandwidth the AN has 463 committed to a given access line, so that the NAS can adjust its 464 forwarding scheduler to ensure the associated QoS. Note that this 465 involves a finer level of detail than provided by bandwidth 466 delegation, since the amount of delegated bandwidth is an upper limit 467 on the amount of bandwidth committed rather than an actual value. To 468 reduce the volume of messaging, reports from the AN may be buffered 469 so that one message reports on changes for multiple access lines. 471 3.4.2. Message Flow 473 The message flow associated with this use case is shown in Figure 4. 474 The figure assumes that a non-zero buffering interval was previously 475 provisioned on the AN. 477 +-----+ +-------+ +-----+ ANCP +-----+ 478 |Subs |+ | Home |+ | AN |<---------->| NAS | 479 |1,2 || |GW 1,2 || +-----+ +-----+ 480 +-----+| +-------+| | | 481 +|----+ +|------+ | | 482 | | | | | | 483 | |Join(Subs1, Ch1) | | 484 |----------+--------------->| Start buffering | 485 | | | Multicast flow | timer. Create | 486 |<==========================| message with | 487 | | | | | initial contents | 488 | | | | | reporting new | 489 | | | | | Subs1 bandwidth. | 490 | | Join(Subs2, Ch2) | | 491 | |----------+------------->| Add report for | 492 | | | Multicast flow | new Subs2 b/w. | 493 | |<========================| | 494 | | | | | | 495 | |Leave(Subs1, Ch1) | | 496 |----------+--------------->| Replace report | 497 | | | | | for Subs1 with | 498 | | Stop replication X new value (which | 499 | | | | | happens to be | 500 | | | | | the same as the | 501 | | | | | starting value. | 502 | | | | | | 503 | | | | >|< TIMER expires | 504 | | | | | | 505 | | | | |Committed | 506 | | | | | Bandwidth Report | 507 | | | | |------------------>| 508 | | | | | (for latest | 509 | | | | | Subs1 and Subs2 | 510 | | | | | bandwidth) | 511 | | | | | | 513 Figure 4: Message Flow For Committed Bandwidth Reporting 515 4. ANCP Messages 516 This section defines new ANCP messages and new usage of existing ANCP 517 messages as well as procedures associated with the use of these 518 messages. 520 Unless stated otherwise, receivers MUST ignore message contents that 521 are not supported by the set of capabilities negotiated between the 522 NAS and the Access Node. 524 4.1. Provisioning Message 526 Section 4.1 of [RFC6320] defines the Provisioning message that is 527 sent by the NAS to the AN to provision information in the AN. 529 The present document specifies that the Provisioning message MAY be 530 used by the NAS to provision multicast-related information (e.g., 531 multicast service profiles). The ANCP Provisioning message payload 532 MAY contain: 534 o one or more instances of the Multicast-Service-Profile TLV. The 535 Multicast-Service-Profile TLV is defined in the present document 536 in Section 5.1. Each instance of the Multicast-Service-Profile 537 TLV contains a multicast service profile name and one or more list 538 actions. A list action consists of an action (add, delete, 539 replace), a list type (white, black, or grey), and list content 540 (multicast source and group addresses). 542 o an instance of the White-List-CAC TLV. The White-List-CAC TLV is 543 defined in Section 5.6. If present, this TLV indicates that the 544 AN is required to do resource-based admission control before 545 replicating white-listed flows. 547 o an instance of the MRepCtl-CAC TLV. The MRepCtl-CAC TLV is 548 defined in Section 5.7. If present, this TLV indicates that the 549 AN is required to do resource-based admission control before 550 replicating flows specified in Multicast Replication Control 551 messages. 553 o an instance of the Report-Buffering-Time TLV. The Report- 554 Buffering-Time TLV is defined in Section 5.11. If present, this 555 TLV indicates Committed Bandwidth Report messages should be 556 buffered for the amount of time given by the TLV before being 557 transmitted to the NAS. 559 See Section 6 for information on which multicast capabilities require 560 support of these TLVs in the Provisioning message. 562 4.1.1. Sender Behaviour 563 When directed by the Policy Server or by management action, the NAS 564 sends the Provisioning message to initially provision or to update 565 the white, black, and/or grey multicast channel lists associated with 566 a set of named multicast service profiles, or to direct the AN to 567 perform resource-based admission control for specific classes of 568 flows. 570 To provision or update a multicast service profile, the NAS MUST 571 include within the message one or more instances of the Multicast- 572 Service-Profile TLV specifying the content to be provisioned or 573 updated. The NAS SHOULD NOT include any list type (white, black, or 574 grey) that is not supported by the set of multicast capabilities 575 negotiated between the NAS and the AN. The NAS MUST NOT use the 576 Provisioning message to send instances of the Multicast-Service- 577 Profile TLV to the AN unless the Multicast-Service-Profile TLV is 578 supported by the set of multicast capabilities negotiated between the 579 NAS and the AN. 581 To require resource-based admission control to be performed at the AN 582 on white-listed flows, the NAS MUST include a copy of the White-List- 583 CAC TLV in the Provisioning message. The White-List-CAC TLV MUST NOT 584 be provided unless the negotiated set of capabilities includes 585 conditional access with white and black lists. 587 To require resource-based admission control to be performed at the AN 588 on grey-listed flows or on NAS-initiated flows, the NAS MUST include 589 a copy of the MRepCtl-CAC TLV in the Provisioning message. The 590 MRepCtl-CAC TLV MUST NOT be provided unless the negotiated set of 591 capabilities includes NAS-initiated replication control or 592 conditional access with grey lists. 594 To require buffering of Committed Bandwidth Report messages so that 595 reports for multiple access lines can be included in the same 596 message, the NAS MUST include a copy of the Report-Buffering-Time TLV 597 containing a non-zero time value in a Provisioning message sent to 598 the AN. The Report-Buffering-Time TLV MUST NOT be provided unless 599 the negotiated set of capabilities includes committed bandwidth 600 reporting. 602 4.1.2. Receiver Behaviour 604 The receiving AN provisions/updates the white, black, and/or grey 605 lists associated with the multicast service profile names contained 606 in the Multicast-Service-Profile TLV instances within the message 607 according to the contents of the associated List-Action TLVs. The AN 608 MUST process List-Action TLVs in the order in which they appear 609 within the message. In keeping with the general rule stated in 610 Section 4, the AN MUST ignore instances of the List-Action TLV 611 referring to any list type (white, black, or grey) that is not 612 supported by the set of multicast capabilities negotiated between the 613 NAS and the AN. 615 When a new multicast service profile is identified by a Multicast- 616 Service-Profile TLV, the initial state of all lists associated with 617 that profile according to the negotiated set of multicast 618 capabilities is empty until changed by the contents of Multicast- 619 Service-Profile TLVs. 621 The receipt of a Provisioning message containing updates to an 622 existing multicast service profile subsequent to startup will cause 623 the AN to review the status of active flows on all ports to which 624 that profile has been assigned. For further details, see Section 6. 626 If the White-List-CAC and/or MRepCtl-CAC TLV is present in the 627 Provisioning message and the respective associated capabilities have 628 been negotiated, the AN prepares (or continues) to do resource-based 629 admission control on the indicated class(es) of flow. If one or both 630 of these TLVs was present in an earlier Provisioning message but is 631 absent in the latest message received, the AN ceases to do resource- 632 based admission control on the indicated class(es) of flow. 634 The buffering time specified in an instance of the Report-Buffering- 635 Time TLV applies only to Committed Bandwidth Report messages 636 initiated after the new buffering time is received at the AN, not to 637 any message already in the process of accumulation. 639 As indicated in [RFC6320], the AN MUST NOT reply to the Provisioning 640 message if it processed it successfully. If an error prevents 641 successful processing of the message content, the AN MUST return a 642 Generic Response message as defined in [RFC6320], containing a 643 Status-Info TLV with the appropriate content describing the error. 644 For this purpose, the presence of a list type in a Multicast-Service- 645 Profile TLV which was ignored because it was not supported by the 646 negotiated set of capabilities is not considered to be an error. 648 4.2. Port Management Message 650 As specified in [RFC6320], the NAS may send DSL line configuration 651 information to the AN ("ANCP based DSL Line Configuration" use case) 652 using ANCP Port Management messages. See Section 7.3 of [RFC6320] 653 for the format of the Port Management message in that usage. 655 This document specifies that the Port Management message MAY be used 656 to convey either or both of the following TLVs: 658 o Multicast-Service-Profile-Name TLV (defined in Section 5.2). This 659 TLV associates a Multicast Service Profile with the access line 660 specified by the extension block, and in the case of white and 661 black lists, delegates policy-based admission control to the AN 662 for the specified access line and channels. 664 o Bandwidth-Allocation TLV (defined in Section 5.5). This TLV 665 specifies the total multicast bandwidth available to the AN for 666 resource-based admission control at the access line. 668 When the Port Management message is used for this purpose: 670 o the Function field in the Port Management message MUST be set to 671 8, "Configure Connection Service Data". 673 o the message MUST include TLV(s) to identify the access line 674 concerned. If the access line is a DSL loop, the line-identifying 675 TLV(s) MUST be as specified in Section 5.1.2 of [RFC6320]. For 676 non-DSL access lines, the appropriate alternative line-identifying 677 TLV(s) MUST be present. Line configuration data other than the 678 two TLVs listed in the previous paragraph MAY be present. 680 4.2.1. Sender Behaviour 682 The NAS sends the Port Management message at startup time to 683 initialize parameters associated with the access line specified in 684 the message and with the multicast capabilities negotiated between 685 the NAS and the AN. The NAS MAY send additional Port Management 686 messages subsequent to startup, to update or, in the case of the 687 Bandwidth-Allocation TLV, reset these parameters. If the NAS 688 includes a Multicast-Service-Profile-Name TLV in the Port Management 689 message, the name MUST match a profile name provided in a Multicast- 690 Service-Profile TLV in a prior Provisioning message. The NAS MUST 691 NOT include a TLV unless it is supported by the set of multicast 692 capabilities negotiated between the NAS and the AN. See Section 6 693 for further information. 695 4.2.2. Receiver Behaviour 697 If the Port Management message contains a Multicast-Service-Profile- 698 Name TLV, the AN associates the named profile with the specified 699 access line. This association replaces any previous association. 700 That is, a given access line is associated with at most one multicast 701 service profile. The replacement of one multicast service profile 702 with another will cause the AN to review the status of all active 703 flows on the target port. For further details see Section 6. 705 If the Port Management message contains a Bandwidth-Allocation TLV, 706 the AN adopts this as the current value of its total multicast 707 bandwidth limit for the target port. If the AN has already committed 708 multicast bandwidth exceeding the amount given in the Bandwidth- 709 Allocation TLV, the AN SHOULD NOT discontinue any multicast streams 710 in order to bring bandwidth down to within the new limit, unless such 711 action is required by local policy. However, the AN MUST NOT admit 712 new multicast streams that are subject to admission control until it 713 can do so within the limit specified by the Bandwidth-Allocation TLV. 715 If the Port Management request cannot be processed due to error and 716 the Result field of the request is Nack (0x1) or AckAll (0x2), the AN 717 SHOULD add a Status-Info TLV to the Extension Value field in its 718 reply if this will provide useful information beyond what is provided 719 by the Result Code value returned in the response header. In 720 particular, if the name within the Multicast-Service-Profile-Name TLV 721 does not match a profile name given in a prior Provisioning message, 722 the AN SHOULD return a reply where the Result Code field in the 723 header indicates 0x55, "Invalid TLV contents", the Error Message 724 field in the Status-Info TLV contains the text "Multicast profile 725 name not provisioned", and the Status-Info TLV contains a copy of the 726 Multicast-Service-Profile-Name TLV. 728 4.3. Multicast Replication Control Message 730 This section defines a new message called the Multicast Replication 731 Control message. The Multicast Replication Control message is sent 732 by the NAS to the AN with one or more directives to add (join) or 733 delete (leave) a multicast flow on a target object identified in the 734 content of the message. 736 The Message Type for the Multicast Replication Control message is 737 144. 739 The ANCP Multicast Replication Control message payload contains the 740 following TLVs: 742 o Target TLV: The Target TLV is defined in Section 4.3 of [RFC6320]. 743 It MUST appear once and only once. It is encoded as specified in 744 [RFC6320] or extensions and identifies the AN port subject to the 745 request for admission or release. 747 o Command TLV: The Command TLV is defined in Section 4.4 of 748 [RFC6320]. It MUST be present. It MAY appear multiple times. 750 As [RFC6320] indicates, the contents of the Command Info field within 751 the Command TLV are specific to the message in which the TLV occurs. 752 For the Multicast Replication Control Message, these contents consist 753 of: 755 o a Command Code field; 757 o an Accounting field; 759 o an instance of the Multicast-Flow TLV. 761 Figure 5 illustrates the complete Command TLV with the contents 762 specific to the Multicast Replication Control message. 764 1 2 3 765 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 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | TLV Type = Command 0x0011 | Command TLV Length | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 |Command Code | Accounting | Reserved | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | Multicast-Flow TLV | 772 | ... | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | Other embedded TLV Type | Other embedded TLV Length | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | | 777 ~ Other embedded TLV data ~ 778 | | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 Figure 5: Contents of the Command TLV in the Multicast Replication 782 Control Message 784 Command Code: 785 Command directive: 787 1 "Add"; 789 2 "Delete"; 791 3 "Delete All"; 793 4 "Admission Control Reject"; 795 5 "Conditional Access Reject"; 797 6 "Admission Control and Conditional Access Reject". 799 Directives 4 through 6 are used as described in 800 Section 4.4.2. 802 Accounting: 803 Meaningful only when the Command Code is "Add" (1). In 804 that case, 0 indicates flow accounting is disabled, 1 805 indicates that octet accounting for the flow is requested. 806 The sender MUST set the Accounting field to 0 and the 807 receiver MUST ignore the Accounting field for other Command 808 Code values. 810 Reserved: 811 Reserved for future use. MUST be set to zeroes by the 812 sender and ignored by the receiver. 814 Multicast-Flow TLV: 815 An instance of the Multicast-Flow TLV (Section 5.10) 816 specifying the flow to be added or deleted. The Multicast- 817 Flow TLV is omitted if the Command Code has value "Delete 818 All" (3). 820 Other embedded TLV: 821 No other embedded TLVs are currently specified within the 822 Multicast Replication Control message/Command TLV. 823 However, see the description of the Multicast Admission 824 Control message (Section 4.4). Unrecognized embedded TLVs 825 SHOULD be silently discarded. 827 The figure below is an example of a Multicast Replication Control 828 message that would result in a swap from multicast Source-Specific 829 Multicast (SSM) flows 2001:DB8::1, FF34::2, to 2001:DB8::2, FF34::3 830 on the Target identified by the "Access Loop Circuit ID": 832 1 2 3 833 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 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Type (0x880C) | Length | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | Version | MsgType=144 | Res=2 | Result Code = 0 | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Partition ID | Transaction Identifier = 18 | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 |I| SubMessage Number | Length | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | TLV Type = Target 0x1000 | Target TLV Length | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | | 848 ~ Access Loop Circuit ID ~ 849 | | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | TLV Type = Command 0x0011 | Command TLV Length = 44 | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Cmd Code = 2 | Acctg = 0 | Reserved = 0x0000 | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | Type = Multicast-Flow 0x0019 | TLV Length = 36 | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | Flow Type = 2 | AddrFam = 2 | Reserved = 0x0000 | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | | 860 ~ Multicast Group Address ~ 861 | = FF34::2 | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | | 864 ~ Source Address ~ 865 | = 2001:DB8::1 | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | TLV Type = Command 0x0011 | Command-TLV Length = 44 | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | Cmd Code = 1 | Acctg = 1 | Reserved = 0x0000 | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | Type = Multicast-Flow 0x0019 | TLV Length = 36 | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | Flow Type = 2 | AddrFam = 2 | Reserved = 0x0000 | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | | 876 ~ Multicast Group Address ~ 877 | = FF34::3 | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | | 880 ~ Source Address ~ 881 | = 2001:DB8::2 | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 4.3.1. Sender Behaviour 886 The NAS MAY issue a Multicast Replication Control message to the AN 887 to convey one or more directives to add (join) or delete (leave) one 888 or more multicast flows. 890 The NAS MAY send this message on its own initiative to support the 891 NAS initiated Multicast Control use case presented in [RFC5851] and 892 summarized in Section 3.1. In that case, the NAS MUST set the Result 893 field to AckAll (0x2) or Nack (0x1) according to its requirements. 895 The NAS MAY also send this message in response to a Multicast 896 Admission Control message (defined in Section 4.4) received from the 897 AN to support the conditional access and admission control use case 898 presented in [RFC5851] and summarized in Section 3.2. In that case, 899 the NAS MUST set the Result field to NAck (0x1). 901 In either case, the sender MUST populate the Result Code field with 902 the value 0 and the ANCP Transaction Identifier field with a unique 903 value, as described in Section 3.6.1.6 of [RFC6320]. 905 Each Multicast Replication Control Message MUST contain one or more 906 commands, each encapsulated in its own Command TLV. The sender MUST 907 use a separate Command TLV for each distinct multicast flow. 909 When the order of processing of two commands does not matter, the 910 commands MUST be transmitted in separate Multicast Replication 911 Control messages. 913 4.3.2. Receiver Behaviour 915 When successive commands (in the same or different messages) relate 916 to the same Target and multicast flow, the state of each feature 917 controlled or affected by attributes received in the Multicast 918 Replication Control message, SHALL be as set by the last command or 919 message referring to that target and flow and containing the 920 controlling attribute. As an example, successive Multicast 921 Replication Control messages containing add commands for a given port 922 and flow but differing only in the Accounting field, update the state 923 of the accounting feature to what is set in the final command 924 received, but all other features are unaffected by the second 925 message. 927 If more than one Command TLV is present in a Multicast Replication 928 Control message, the AN MUST act on the commands in the order in 929 which they are presented in the message. The AN SHALL assign a 930 sequence number to each command in a given Multicast Replication 931 Control message, starting from 1 for the first command. 933 If a Command TLV adds a flow and the AN is performing resource-based 934 admission control for Multicast Replication Control messages, then 935 the AN MUST perform admission control before replicating the flow. 936 If the admission control check fails, the AN MUST treat the failure 937 as an error as described below. The appropriate Result Code value 938 for the response is 0x13 "Out of resources". 940 If the AN processes the complete Multicast Replication Control 941 message successfully and the Result field of the Multicast 942 Replication Control message was set to AckAll (0x2), the AN MUST 943 respond with a Generic Response message where the Result field is set 944 to Success (0x3), the Result Code field is set to 0, and the 945 Transaction Identifier field is copied from the Multicast Replication 946 Control message. The body of the response MAY be empty or MAY be 947 copied from the Multicast Replication Control message. 949 If the AN processes the complete Multicast Replication Control 950 message successfully and the Result field of the Multicast 951 Replication Control message was set to Nack (0x1), the AN MUST NOT 952 respond to the message. 954 The processing/execution of multiple commands contained in a single 955 Multicast Control message MUST be interrupted at the first error 956 encountered, and the remaining commands in the Multicast Replication 957 Control message discarded. 959 If the AN detects an error in a received Multicast Replication 960 Control message and the Result field in that message was set to Nack 961 (0x1) or AckAll(0x2), the AN MUST generate a Generic Response message 962 providing error information to the NAS. This specification 963 identifies the following new Result Code values beyond those 964 specified in [RFC6320], which MAY be used in a Generic Response sent 965 in reply to a Multicast Replication Control message: 967 0x64 Command error. 969 Where detected: ANCP agent at the AN. 971 Further description: an invalid command code has been received. 973 Required additional information in the message: see below. 975 Target: ANCP agent at the NAS. 977 Action RECOMMENDED for the receiving ANCP agent: Report the 978 error to the control application with an indication of the 979 erroneous information associated with the invalid TLV(s). 981 0x65 Invalid flow address. 983 Where detected: ANCP agent at the AN. 985 Further description: either inconsistent flow address 986 information has been provided or the address family is 987 unsupported. 989 Required additional information in the message: see below. 991 Target: ANCP agent at the NAS. 993 Action RECOMMENDED for the receiving ANCP agent: Report the 994 error to the control application with an indication of the 995 erroneous information associated with the invalid TLV(s). 997 0x66 Multicast flow does not exist. 999 Where detected: control application at the AN. 1001 Further description: the NAS has attempted to delete a flow 1002 that is not active on the given access line. 1004 Required additional information in the message: see below. 1006 Target: control application at the NAS. 1008 Action RECOMMENDED for the receiving ANCP agent: report the 1009 error to the control application with an indication of the 1010 erroneous information associated with the invalid TLV(s). 1012 A Generic Response message responding to the Multicast Replication 1013 Control message and containing one of the above Result Code values 1014 MUST include a Status-Info TLV which includes one or two embedded 1015 TLVs as follows: 1017 o a Sequence-Number TLV as described in Section 5.4, giving the 1018 sequence number of the failed command, MUST be included; 1020 o the failed Command TLV itself SHOULD be included. 1022 Note that the Error Message field of the Status-Info TLV MAY be 1023 used to report more details than implied by the Result Code value 1024 in the message header. For example, the Result Code value could 1025 be 0x65 and the Error Message field could contain the text: 1026 "Source address present for ASM flow". 1028 4.4. Multicast Admission Control Message 1030 This section defines a new message called the Multicast Admission 1031 Control message. The Multicast Admission Control message is sent by 1032 the AN to the NAS to request admission of a multicast flow, or to 1033 notify of the removal of a multicast flow, for a given target. 1035 The Message Type for the Multicast Admission Control message is 145. 1037 The ANCP Multicast Admission Control message payload contains two 1038 TLVs: 1040 o Target TLV: The Target TLV is defined in [RFC6320]. It MUST 1041 appear once and only once in the Multicast Admission Control 1042 message. It is encoded as specified in [RFC6320] or extensions 1043 and identifies the AN port subject to the request for admission or 1044 release. 1046 o Command TLV: The Command TLV is defined in [RFC6320]. It MUST be 1047 present. If it appears more than once, only the first instance is 1048 considered meaningful in the present version of this specification 1049 and the other instances are ignored. 1051 Note: 1053 In the future, the specification of the Admission Control message 1054 may be extended to allow transport of more than a single directive 1055 (e.g., to carry both a leave from one group and a join to another 1056 group for the same Target). It is expected that this would 1057 support a similar notion of strict sequenced processing as 1058 currently defined for handling multiple directives in the 1059 Multicast Replication Control message whereby all directives 1060 following the first directive that can not be executed are not 1061 executed either. When the strict sequenced processing of the 1062 directives is not required the directives are distributed across 1063 separate messages. 1065 The Command TLV has the same contents as were described above for the 1066 Multicast Replication Control message, with the following addition: 1068 o a Subs-Session-ID TLV as defined in Section 5.9 MAY be appended to 1069 the Command TLV as an additional embedded TLV. The need for this 1070 TLV depends on what type of subscriber session identifier the 1071 operator is using to retrieve the subscriber profile information 1072 from AAA. Some of the types identified by [TR-146] requirement 1073 R43 are covered by the contents of the Target TLV. 1075 Note that the Command TLV length includes the length of any embedded 1076 TLVs, including the embedded TLV headers. 1078 4.4.1. Sender Behaviour 1080 The AN sending the Multicast Admission Control message MUST set the 1081 Result field to Ignore (0x0). 1083 The AN MUST populate the ANCP Transaction Identifier field with a 1084 unique value, as described in Section 3.6.1.6 of [RFC6320]. 1086 The AN MUST encode the Command TLV as specified in Section 4.3 with 1087 the following additional rules: 1089 o the Accounting field MUST be set to 0; 1091 o the Command Code field MUST be set to "Add" (1) when the message 1092 conveys a Join , to "Delete" (2) when the message conveys a Leave 1093 and to "Delete All" (3) when the message conveys a Leave of all 1094 channels (on the target); 1096 o The Multicast-Flow TLV within the Command TLV identifies the 1097 multicast flow subject to the request for admission or release. 1098 When the Command Code is 3, the Multicast-Flow TLV is omitted. 1100 o Depending on local configuration, the Subs-Session-Identifier 1101 embedded TLV MAY be included by the AN. The content of this TLV 1102 depends on local practice. 1104 4.4.2. Receiver Behaviour 1106 On receipt of an Multicast Admission Control message, the NAS: 1108 o MUST ignore the Result field; 1110 o if the directive in the Multicast Admission Control message is 1111 "Delete" (2) or "Delete All" (3) and is processed correctly by the 1112 NAS, the NAS MUST NOT generate any ANCP message in response to the 1113 Multicast Admission Control message; 1115 o if the directive in the Multicast Admission Control message is 1116 "Add" (1) and is accepted by the NAS, the NAS MUST generate a 1117 Multicast Replication Control in response to the Multicast 1118 Admission Control message. The Multicast Replication Control 1119 message: 1121 * MUST contain a Result set to Nack (0x1); 1123 * MUST contain a Transaction ID with a unique value, as described 1124 in Section 3.6.1.6 of [RFC6320]; 1126 * MUST contain the directive as accepted by the NAS. The NAS MAY 1127 modify the Accounting field if flow accounting is required. 1129 o if the directive in the Multicast Admission Control message is 1130 "Add" (1), is processed correctly but not accepted by the NAS 1131 (i.e., it does not pass the conditional access and admission 1132 control check), the NAS MAY generate a Multicast Replication 1133 Control message in response to the Multicast Admission Control 1134 message. This optional message can be used by the AN to maintain 1135 statistics about admission control rejections. When used in this 1136 situation, the Multicast Replication Control message: 1138 * MUST contain a Result set to 0x0; 1140 * MUST contain a Transaction ID with a unique value, as described 1141 in Section 3.6.1.6 of [RFC6320]; 1143 * MUST contain the directive rejected by the NAS (i.e., Target 1144 TLV and Command TLV) but with a Command Code set to "Admission 1145 Control Reject" (4), "Conditional Access Reject" (5), or 1146 "Admission Control and Conditional Access Reject" (6) as 1147 applicable. 1149 o if the Multicast Admission Control message cannot be processed 1150 correctly by the NAS (e.g. the message is malformed, the multicast 1151 flow does not exist etc.), the NAS MUST generate a Generic 1152 Response message (defined in Section 4.2 of [RFC6320]) with 1153 appropriate content indicating the reason for the failure. 1155 4.5. Bandwidth Reallocation Request Message 1157 The Bandwidth Reallocation Request message is used when the bandwidth 1158 delegation capability is included in the negotiated set. It MAY be 1159 sent either by the NAS or by the AN to request an adjustment in the 1160 amount of delegated bandwidth. It will be sent by the NAS typically 1161 to reduce the multicast bandwidth allocated to the AN in order for 1162 the NAS to satisfy a request to add one or more flows. Conversely, 1163 the AN will send a Bandwidth Reallocation Request to obtain 1164 additional bandwidth to satisfy a request to add a multicast channel. 1165 In each case, the requestor has a minimum requirement for additional 1166 bandwidth, and MAY ask for additional bandwidth beyond this amount 1167 (e.g., to handle anticipated future requests). 1169 The Bandwidth Reallocation Request message contains two TLVs: 1171 o the Target TLV (Section 4.3 of [RFC6320] or an extension), 1172 specifying a single access line; 1174 o the Bandwidth-Request TLV (Section 5.8), specifying the required 1175 and preferred amounts of delegated bandwidth. 1177 The Message Type for the Bandwidth Reallocation Request message is 1178 146. 1180 4.5.1. Sender Behaviour 1182 The Result field in the header of the Bandwidth Reallocation Request 1183 message is not used and the sender MUST set it to Ignore (0x0). 1185 The bandwidth values in the Bandwidth-Request TLV are expressed in 1186 terms of total multicast bandwidth allocated to the AN. 1188 The choice of "total bandwidth" rather than "incremental 1189 bandwidth" was made so that it would be easier for the AN and NAS 1190 to keep their respective views of the current amount of delegated 1191 bandwidth synchronized. 1193 Because the values are totals rather than desired increments/ 1194 decrements, the relationship between the required amount and the 1195 preferred amount will differ depending on whether the Bandwidth 1196 Reallocation Request message is issued by the NAS or the AN. 1198 o If the NAS is making the request, the preferred amount MUST be 1199 less than or equal to the required amount. The required amount 1200 MUST be less than the current amount of delegated bandwidth. 1202 o If the AN is making the request, the preferred amount MUST be 1203 greater than or equal to the required amount. The required amount 1204 MUST be greater than the current amount of delegated bandwidth. 1206 4.5.2. Receiver Behaviour 1208 When the peer receives a valid Bandwidth Reallocation Request 1209 message, it SHOULD determine whether it can satisfy the request from 1210 its existing allocation of unused video bandwidth. If it decides 1211 that it can reallocate bandwidth to the peer, it MAY choose to return 1212 any amount between the required and the preferred amounts indicated 1213 in the Bandwidth Reallocation Request message. 1215 The peer MUST return a Bandwidth Transfer message (Section 4.6) 1216 indicating its decision. If the request is met, the Result field of 1217 the Bandwidth Transfer message MUST be set to Success (0x3), the 1218 Result Code field MUST be set to 0x000, and the Bandwidth-Allocation 1219 TLV (Section 5.5) MUST contain the new value of total multicast 1220 bandwidth. This new value MUST lie between the required and 1221 preferred values, inclusive, from the request message. If the 1222 request is not met, the Result field of the Bandwidth Transfer 1223 message MUST be set to Failure (0x4), the Result Code field MUST be 1224 set to 0, and the Bandwidth Allocation TLV MUST contain the value of 1225 the currently allocated amount of delegated bandwidth as the 1226 responder views it. 1228 The following cases indicate that the sender holds a different view 1229 of the amount of delegated bandwidth from the receiver: 1231 o the NAS receives a request where the required amount is less than 1232 its view of the current amount of delegated bandwidth; 1234 o the AN receives a request where the required amount is greater 1235 than its view of the current amount of delegated bandwidth. 1237 If one of these cases occurs, the receiver with one exception MUST 1238 send a Bandwidth Transfer message indicating Success. 1240 o If the NAS received the request, the allocated amount in the NAS's 1241 response MUST be at least equal to NAS's view of the current 1242 amount of delegated bandwidth. 1244 o If the AN received the request, the allocated amount in the AN's 1245 response MUST be no greater than the AN's view of the current 1246 amount of delegated bandwidth. 1248 The exception is when the NAS receives a request while it has a 1249 request of its own outstanding. Handling of that case is described 1250 below. 1252 While the cases just described are an error condition, the success 1253 response achieves a graceful recovery. 1255 To avoid deadlock due to race conditions, the following rules MUST be 1256 applied: 1258 a. If the NAS receives a Bandwidth Reallocation Request message 1259 while it has a Bandwidth Reallocation Request message of its own 1260 outstanding for the same access line, the NAS MUST provide an 1261 immediate failure response to the request from the AN, with a 1262 Result Code value set to 0x68 "Inconsistent views of delegated 1263 bandwidth amount" or 0x69 "Bandwidth request conflict" as 1264 applicable. (See below for more information). 1266 b. If the AN receives a Bandwidth Reallocation Request message while 1267 it has a Bandwidth Reallocation Request message of its own 1268 outstanding for the same access line, the AN MUST release any 1269 bandwidth it has already committed to an outstanding Join request 1270 while it is awaiting a response from the NAS. It MUST decide 1271 upon and send its response to the NAS taking the released 1272 bandwidth into account. 1274 If the receiver is unable to process the Bandwidth Reallocation 1275 Request message due to an error, then the receiver MUST return a 1276 Bandwidth Transfer message where: 1278 o the Result field is set to Failure (0x4), 1280 o the Result Code field is set appropriately to indicate the type of 1281 error that was detected, 1283 o the Bandwidth Allocation TLV contains the value of the current 1284 amount of delegated bandwidth as the responder views it, and 1286 o a Status-Info TLV MAY follow the Bandwidth Allocation TLV giving 1287 further information about the error. 1289 This specification provides three new Result Code values applicable 1290 specifically to the contents of the Bandwidth-Request TLV. These 1291 Result Code values by their nature MUST only be used when the error 1292 is being reported in a Bandwidth Transfer message rather than a 1293 Generic Response message. 1295 0x67 Invalid preferred bandwidth amount. 1297 Where detected: control application at the receiver of the 1298 Bandwidth Reallocation Request message. 1300 Further description: the preferred and required amounts of 1301 bandwidth in the TLV do not have the numerical relationship 1302 described above. 1304 Required additional information in the message: as described 1305 above. 1307 Target: control application at the sender of the Bandwidth 1308 Reallocation Request message. 1310 Action RECOMMENDED for the receiving ANCP agent: report the 1311 error to the control application with the returned value of the 1312 Bandwidth-Allocation TLV. See also Section 4.6.2.2. 1314 0x68 Inconsistent views of delegated bandwidth amount. 1316 Where detected: control application at the NAS. 1318 Further description: the NAS has an outstanding Bandwidth 1319 Reallocation Request, so it is rejecting a similar request from 1320 the AN. In the AN request, the required amount was less than 1321 the NAS's view of the current amount of delegated bandwidth. 1323 Required additional information in the message: as described 1324 above. 1326 Target: control application at the AN. 1328 Action RECOMMENDED for the receiving ANCP agent: report the 1329 error to the AN control application with the returned value of 1330 the Bandwidth-Allocation TLV. See also Section 4.6.2.2. 1332 0x69 Bandwidth request conflict. 1334 Where detected: control application at the NAS. 1336 Further description: the NAS has an outstanding Bandwidth 1337 Reallocation Request, so it is rejecting a similar, valid 1338 request from the AN. 1340 Required additional information in the message: as described 1341 above. 1343 Target: control application at the AN. 1345 Action RECOMMENDED for the receiving ANCP agent: report the 1346 error to the AN control application with the returned value of 1347 the Bandwidth-Allocation TLV. See also Section 4.6.2.2. 1349 4.6. Bandwidth Transfer Message 1351 The Bandwidth Transfer message is used to transfer video bandwidth 1352 from the sender to the peer for a specific access line. This message 1353 MAY be sent either from the AN or from the NAS. As described in the 1354 previous section, it is the required response to a valid Bandwidth 1355 Reallocation Request message. 1357 The Bandwidth Transfer message MAY also be used to transfer bandwidth 1358 autonomously from one peer to another. One example of this usage is 1359 to release bandwidth borrowed earlier by means of the Bandwidth 1360 Reallocation Request message. When the message is used in this way, 1361 the Result field in the Bandwidth Transfer message MUST be set to 1362 Ignore (0x0). 1364 This allows the receiver to distinguish between an autonomous 1365 transfer and a response to a previous Bandwidth Reallocation 1366 Request, for purposes of validation. 1368 The Message Type for the Bandwidth Transfer message is 147. The 1369 Bandwidth Transfer message contains the following TLVs: 1371 o the Target TLV, designating the access line concerned; 1373 o an instance of the Bandwidth-Allocation TLV (Section 5.5). The 1374 bandwidth value in the Bandwidth-Allocation TLV is the new amount 1375 of delegated bandwidth allocated to the target. 1377 4.6.1. Sender Behaviour 1378 When sending a Bandwidth Transfer message where the Result value is 1379 Ignore (0x0) or Success (0x3), the following relationships MUST hold: 1381 o if the message is sent by the NAS, the bandwidth value in the 1382 Bandwidth-Allocation TLV MUST be greater than or equal to the 1383 sender's view of the current amount of delegated bandwidth for the 1384 access line concerned; 1386 o if the message is sent by the AN, the bandwidth value in the 1387 Bandwidth-Allocation TLV MUST be less than or equal to the 1388 sender's view of the current amount of delegated bandwidth for the 1389 access line concerned. 1391 Further sender behaviour is specified above, in Section 4.5.2. 1393 4.6.2. Receiver Behaviour 1395 4.6.2.1. Behaviour of the NAS 1397 If the amount of delegated bandwidth provided in the Bandwidth- 1398 Allocation TLV is not greater than the NAS's view of the current 1399 amount of delegated bandwidth, the NAS MUST update its view of the 1400 current amount of delegated bandwidth to the amount indicated in the 1401 Bandwidth Transfer message. This is required regardless of whether 1402 the Result field of that message indicates Success or Failure. 1404 If the amount of delegated bandwidth provided in the Bandwidth- 1405 Allocation TLV is greater than the NAS's view of the current amount 1406 of delegated bandwidth, the NAS MAY accept the given value as its new 1407 value of delegated bandwidth. Alternatively, the NAS MAY force the 1408 AN to modify its view of the amount of delegated bandwidth to that 1409 held by the NAS, by sending a Port Management message for the target 1410 access line concerned, containing a Bandwidth-Allocation TLV with a 1411 value equal to the amount of delegated bandwidth the NAS wishes to 1412 enforce. 1414 4.6.2.2. Behaviour of the AN 1416 If the amount of delegated bandwidth provided in the Bandwidth- 1417 Allocation TLV of the Bandwidth Transfer message differs from the 1418 AN's view of the current amount of delegated bandwidth, the AN MUST 1419 update its view of the current amount of delegated bandwidth to the 1420 amount indicated in the Bandwidth Transfer message. This is required 1421 with the exception of a Bandwidth Transfer message with a Result 1422 field equal to Failure (0x4) and a Result Code field equal to 0x68 1423 "Inconsistent views of delegated bandwidth amount" or 0x69 "Bandwidth 1424 request conflict". If Result Code value 0x68 is received, the AN 1425 MUST issue a Delegated Bandwidth Query Request message to determine 1426 the NAS's current view of the amount of delegated bandwidth. The AN 1427 MUST update its own view based on the value returned in the Delegated 1428 Bandwidth Query Response. If Result Code value 0x69 is received, the 1429 AN SHOULD carry out this procedure unless it can account for the 1430 discrepancy as a result of a transfer of bandwidth to the NAS that 1431 was carried out just before the incoming Bandwidth Transfer message 1432 was processed. 1434 The two Result Code values indicate a race condition where the AN 1435 may have just completed a transfer of bandwidth to the NAS. As a 1436 result, the value given in the Bandwidth Transfer message may be 1437 outdated, and the AN needs to query the NAS to find its latest 1438 view. The procedure assumes that ordering is preserved between 1439 the Bandwidth Transfer message sent by the AN in response to the 1440 NAS's request and the subsequent Delegated Bandwidth Query Request 1441 message. 1443 If as the result of the procedures just described the AN determines 1444 that it has over-committed multicast bandwidth, it MUST NOT terminate 1445 any currently-active programs, but MUST NOT honour any more "join" 1446 requests until it is possible to do so within the limit set by its 1447 current value of delegated bandwidth. 1449 4.7. Delegated Bandwidth Query Request Message 1451 The Message Type for the Delegated Bandwidth Query Request (and 1452 Response) messages is 148. 1454 The Delegated Bandwidth Query Request message MAY be sent either by 1455 the NAS or by the AN to retrieve the peer's view of the amount of 1456 delegated bandwidth. The request contains one TLV: 1458 o a Target TLV designating the access line for which the information 1459 is requested. 1461 4.7.1. Sender Behaviour 1463 The sender MUST set the Result field in the header of the Delegated 1464 Bandwidth Query Request message to AckAll (0x2). The Result Code 1465 value MUST be set to 0. The sender MUST populate the ANCP 1466 Transaction Identifier field with a unique value, as described in 1467 Section 3.6.1.6 of [RFC6320]. 1469 4.7.2. Receiver Behaviour 1471 If the AN or NAS receives a valid Delegated Bandwidth Query Request 1472 message, it MUST respond with a Delegated Bandwidth Query Response 1473 message. The Result field in the header of the response MUST be set 1474 to Success (0x3). The Result Code field MUST be set to 0. The 1475 Transaction-Id field MUST be copied from the request message. The 1476 body of the response MUST contain the Target TLV, copied from the 1477 request message. Finally, the body of the response MUST contain a 1478 Bandwidth-Allocation TLV, containing the current amount of delegated 1479 bandwidth from the point of view of the receiver of the request. 1481 If the contents of the Delegated Bandwidth Query Request message are 1482 in error, the receiver MUST return a Delegated Bandwidth Query 1483 Response message with the Result field in the header set to Failure 1484 (0x3). The Result Code field MUST be set to the value that indicates 1485 the nature of the error (e.g., 0x500 "One or more of the specified 1486 ports do not exist"). The Transaction-Id field MUST be copied from 1487 the request. The body of the response MUST contain the Target TLV 1488 copied from the request. This MAY be followed by a Status-Info TLV 1489 giving further information about the error. 1491 4.8. Delegated Bandwidth Query Response Message 1493 The Delegated Bandwidth Query Response message is sent in reply to a 1494 Delegated Bandwidth Query Request. The response to a valid request 1495 contains two TLVs: 1497 o the Target TLV, copied from the request; 1499 o a Bandwidth-Allocation TLV, giving the responder's view of the 1500 current amount of multicast bandwidth delegated to the AN. 1502 The Message Type for the Delegated Bandwidth Query Response message 1503 is 148. 1505 4.8.1. Sender Behaviour 1507 Sender behaviour for the Delegated Bandwidth Query Response message 1508 is specified in Section 4.7.2. 1510 4.8.2. Receiver Behaviour 1512 If the Delegated Bandwidth Query Response message indicates Success 1513 (0x3), the following actions apply. 1515 4.8.2.1. Behaviour at the NAS 1516 If the amount of delegated bandwidth provided in the Bandwidth- 1517 Allocation TLV is less than the NAS's view of the current amount of 1518 delegated bandwidth, the NAS MUST update its view of the current 1519 amount of delegated bandwidth to the amount indicated in the 1520 Delegated Bandwidth Query Response message. 1522 If the amount of delegated bandwidth provided in the Bandwidth- 1523 Allocation TLV is greater than the NAS's view of the current amount 1524 of delegated bandwidth, the NAS MAY accept the given value as its new 1525 value of delegated bandwidth. Alternatively, the NAS MAY force the 1526 AN to modify its view of the amount of delegated bandwidth to that 1527 held by the NAS, by sending a Port Management message for the target 1528 access line concerned, containing a Bandwidth-Allocation TLV with a 1529 value equal to the amount of delegated bandwidth the NAS wishes to 1530 enforce. 1532 4.8.2.2. Behaviour at the AN 1534 The AN SHOULD accept the value returned in the Bandwidth-Allocation 1535 TLV of the Delegated Bandwidth Query Response message as the correct 1536 value of the current amount of delegated bandwidth. If the AN has 1537 currently committed more than this amount to active programs, it MUST 1538 NOT cease replicating the flows concerned, but MUST NOT honour any 1539 more Join requests until possible to do so within the new limit. 1541 A race condition is possible, where the AN sends a query, the NAS 1542 requests more bandwidth, then receives and responds to the query, 1543 then receives the Bandwidth Transfer message responding to its 1544 request. It is up to the AN to take appropriate action in this 1545 case. The best action appears to be not to act on the result of 1546 the first query, but to repeat the query after sending the 1547 Bandwidth Transfer message. Similar considerations apply to a 1548 race between queries from both sides. 1550 4.9. Multicast Flow Query Request and Response Messages 1552 This section defines two new messages called the Multicast Flow Query 1553 Request and Multicast Flow Query Response. The Multicast Flow Query 1554 Request is sent by the NAS to request information about the multicast 1555 flows that are active on the AN. The Multicast Flow Query Response 1556 is sent in response by the AN to provide the requested information to 1557 the NAS. 1559 The Message Type for the Multicast Flow Query Request and Multicast 1560 Flow Query Response messages is 149. 1562 The contents of the Multicast Flow Query Request and Response depend 1563 on the nature of the query, as described below. 1565 4.9.1. Sender Behaviour 1567 The sender of a Multicast Flow Query Request message MUST set the 1568 Result field to AckAll (0x2). The Result Code field MUST be set to 1569 0x000. The sender MUST populate the ANCP Transaction Identifier 1570 field with a unique value, as described in section 3.6.1.6 of 1571 [RFC6320]. 1573 The Multicast Flow Query Request MAY be used by the NAS to retrieve: 1575 o the AN's view of which multicast flows are currently active on a 1576 specified set of access ports; or 1578 o the AN's view of the access ports on which a specified set of 1579 multicast flows are currently active; or 1581 o the AN's view of all the multicast flows currently active on each 1582 access port of the AN. 1584 To retrieve the AN's view of which multicast flows are currently 1585 active on a given port of the AN, the NAS MUST include a Target TLV 1586 in the Multicast Flow Query Request payload identifying that port. 1587 The Target TLV is encoded as specified in [RFC6320]. 1589 To retrieve the AN's view of the ports currently receiving a given 1590 multicast flow, the NAS MUST include a Multicast-Flow TLV in the 1591 Multicast Flow Query Request payload identifying that flow. The 1592 Multicast-Flow TLV is encoded as specified in Section 5.10. 1594 The NAS MAY include multiple Target TLVs or multiple Multicast-Flow 1595 TLVs in the Multicast Flow Query Request, but MUST NOT include both 1596 Target and Multicast-Flow TLVs in the same message. 1598 To retrieve the AN's view of all of the multicast flows currently 1599 active on each port of the AN, the NAS MUST send a Multicast Flow 1600 Query Request which does not contain any instance of the Target TLV 1601 or the Multicast-Flow TLV. 1603 4.9.2. Receiver Behaviour 1605 The AN MUST respond to a Multicast Flow Query Request message that 1606 has a valid format and a valid content with a Multicast Flow Query 1607 Response message. The Result field in the response MUST be set to 1608 Success (0x3). The Result Code field MUST be set to 0. The 1609 Transaction-Id field MUST be copied from the request. 1611 If the Multicast Flow Query Request contained one (or more) Target 1612 TLVs, the AN MUST include, for each of these Target TLVs, the 1613 following set of TLVs: 1615 o Target TLV. This MUST be identical to the Target TLV in the 1616 received Multicast Flow Query Request message. 1618 o Multicast-Flow TLV(s). The Multicast-Flow TLV MUST appear once 1619 per multicast flow that is currently active on the AN port 1620 identified in the preceding Target TLV. 1622 The Target TLVs MUST appear in the response from the AN in the same 1623 order as in the query from the NAS. 1625 If the Multicast Flow Query Request contained one (or more) 1626 Multicast-Flow TLVs, the AN MUST include, for each of these 1627 Multicast-Flow TLVs, the following set of TLVs: 1629 o Multicast-Flow TLV. This MUST be identical to the Multicast-Flow 1630 TLV in the received Multicast Flow Query Request message. 1632 o Target TLV(s). The Target TLV MUST appear once per AN port on 1633 which the multicast flow identified in the preceding Multicast- 1634 Flow TLV is active. 1636 The Multicast-Flow TLVs MUST appear in the response from the AN in 1637 the same order as in the query from the NAS. 1639 If the Multicast Flow Query Request contained no Target TLV and no 1640 Multicast Flow TLV, the AN MUST include, for each AN port currently 1641 receiving multicast flow(s), the following set of TLVs: 1643 o Target TLV. This MUST identify one AN port. 1645 o Multicast-Flow TLV(s). The Multicast-Flow TLV MUST appear once 1646 per Multicast Flow that is currently active on the AN port 1647 identified in the preceding Target TLV. 1649 If the contents of the Multicast Flow Query Request are in error, the 1650 AN MUST reply with a Multicast Flow Query Response message with the 1651 Result field set to Failure (0x4) and the Result Code field set to 1652 indicate the nature of the error. If the request contained multiple 1653 instances of the Target TLV or the Multicast-Flow TLV and one of 1654 these is in error, the response message MUST contain the results for 1655 the preceding instances of the TLV as if there had been no error. 1656 These successful results MUST be followed by the TLV in error, copied 1657 from the request. The AN MUST NOT do further processing of the 1658 request. The AN MAY add a Status-Info TLV to provide further 1659 information on the nature of the error. 1661 4.10. Committed Bandwidth Report Message 1663 This section describes the Committed Bandwidth Report message, which 1664 is sent from the AN to the NAS to report the most recent amount of 1665 multicast bandwidth usage committed to one or more access lines. 1667 The Message Type for the Committed Bandwidth Report message is 150. 1669 The Committed Bandwidth Report message contains one or more instances 1670 of the Committed-Bandwidth TLV, as described in Section 5.12. 1672 4.10.1. Sender Behaviour 1674 The sender of a Committed Bandwidth Report message MUST set the 1675 Result field to Ignore (0x0). The Result Code field MUST be set to 1676 0x000. The sender MUST populate the ANCP Transaction Identifier 1677 field with a unique value, as described in section 3.6.1.6 of 1678 [RFC6320]. 1680 Each instance of the Committed-Bandwidth TLV included in the message 1681 MUST identify an access line for which the amount of committed 1682 multicast bandwidth has changed since the previous Committed 1683 Bandwidth Report message was sent and MUST report the latest amount 1684 of multicast bandwidth committed to that line. There MUST be only 1685 one instance of the Committed-Bandwidth TLV present in the message 1686 for any given access line. The message MUST include an instance of 1687 the Committed-Bandwidth TLV for every access line for which committed 1688 multicast bandwidth has changed since the previous Committed 1689 Bandwidth Report message was sent. 1691 Further behaviour at the AN is specified in Section 6.2.2. 1693 4.10.2. Receiver Behaviour 1695 The usage of the contents of a Committed Bandwidth Report message 1696 received by the NAS is implementation-dependent. One example is that 1697 the NAS uses the reports of multicast bandwidth commitments to adjust 1698 its forwarding scheduler operation to provide the intended level of 1699 QoS. 1701 The NAS MUST NOT reply to a valid Committed Bandwidth Report message. 1702 The NAS MAY send a Generic Response message indicating the nature of 1703 any errors detected in a Committed Bandwidth Report message that it 1704 has received. 1706 5. ANCP TLVs For Multicast 1708 This section defines new ANCP TLVs for the control of multicast 1709 flows. 1711 5.1. Multicast-Service-Profile TLV 1713 This document defines the new Multicast-Service-Profile TLV. 1715 The Multicast-Service-Profile TLV MAY be included in a Provisioning 1716 message as specified in Section 4.1. 1718 The Multicast-Service-Profile TLV is illustrated in Figure 6. It 1719 consists of a TLV header encapsulating a single instance of the 1720 Multicast-Service-Profile-Name TLV and one or more instances of the 1721 List-Action TLV. 1723 1 2 3 1724 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 1725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1726 | Mcast-Service-Profile 0x0013 | TLV Length | 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1728 | Multicast-Service-Profile-Name TLV | 1729 | | 1730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1731 | List-Action TLV | 1732 | | 1733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1734 | ... | 1735 | | 1736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1737 | List-Action TLV | 1738 | | 1739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1741 Figure 6: Multicast-Service-Profile TLV 1743 The Multicast-Service-Profile TLV has the following fields: 1745 o The Multicast-Service-Profile TLV Type is 0x0013. 1747 o The TLV length is determined by the contents following the TLV 1748 header. 1750 o The Multicast-Service-Profile-Name TLV is described in 1751 Section 5.2. The Multicast-Service-Profile-Name TLV MUST contain 1752 an identifier which is unique over all profiles provisioned to the 1753 same AN partition. This identifier will be used to refer to the 1754 profile when activating it for a given target within a Port 1755 Management message (see Section 4.2). 1757 o The List-Action TLV is described in Section 5.3. The List-Action 1758 TLV(s) provide the content of a newly defined multicast service 1759 profile or modify the existing content. If more than one List- 1760 Action TLV is present, the order of the TLVs may be significant, 1761 since List-Action TLVs are processed in the order in which they 1762 appear. 1764 5.2. Multicast-Service-Profile-Name TLV 1766 The Multicast-Service-Profile-Name TLV carries the identifier of a 1767 multicast service profile provisioned on the AN. It is illustrated 1768 in Figure 7. 1770 1 2 3 1771 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 1772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1773 | Mcast-Svc-Profile-Name 0x0018 | TLV Length | 1774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1775 | Multicast service profile identifier | 1776 | | 1777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1779 Figure 7: Multicast-Service-Profile-Name TLV 1781 The Multicast-Service-Profile-Name TLV has the following fields: 1783 o The Multicast-Service-Profile-Name TLV Type is 0x0018. 1785 o TLV Length: up to 255 octets. 1787 o Multicast service profile identifier: an opaque sequence of octets 1788 identifying a specific multicast service profile. 1790 The identifier could have the form of human-readable text or an 1791 arbitrary binary value, depending on the operator's practices. 1793 5.3. List-Action TLV 1795 The List-Action TLV identifies multicast flows to be added to or 1796 removed from a list of white-, black-, or grey-listed flows. It is 1797 meaningful only in association with a Multicast-Service-Profile-Name 1798 TLV identifying the profile to which the List-Action TLV applies. 1799 Such an association can be achieved by placing both TLVs in the same 1800 base message payload or as embedded TLVs of another TLV such as the 1801 Multicast-Service-Profile. The List-Action TLV is shown in Figure 8. 1803 1 2 3 1804 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 1805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 | TLV Type = List-Action 0x0021 | TLV Length | 1807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1808 | Operation | List Type | Reserved | 1809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1810 | Address Family | Number of flow fields | 1811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1812 | Multicast flow fields | 1813 ...... 1814 | | 1815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1816 | Address Family | Number of flow fields | 1817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1818 | Multicast flow fields | 1819 ...... 1820 | | 1821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1823 Figure 8: List-Action TLV 1825 The List-Action TLV contains the following fields: 1827 o The List-Action TLV Type is 0x0021. 1829 o TLV Length: length of the subsequent contents. 1831 o Operation: operation to be performed upon the white, black, or 1832 grey list identified by the List Type field within the profile 1833 identified by the associated Multicast-Service-Profile-Name 1834 embedded TLV. The possible values are: 1836 * 1 "Add": the multicast flow fields are to be added to the list. 1838 * 2 "Delete": the multicast flow fields are to be removed from 1839 the list. Each multicast flow field in the List-Action MUST 1840 match exactly an existing entry in the list concerned. Thus to 1841 remove part of the range provided by a wildcarded list entry, 1842 it is necessary to remove the entire entry and add back the 1843 remaining partial range(s). 1845 * 3 "Replace": the multicast flow fields replace the existing 1846 contents of the list. 1848 o List Type: the list type being modified by this List-Action. The 1849 possible values are 1 "White", 2 "Black", or 3 "Grey". 1851 o Reserved: a sender MUST set this field to zeroes. A receiver MUST 1852 ignore the contents of this field. 1854 o Address Family: the IP version of the set of multicast flow fields 1855 that follow, encoded according to [PIMreg]. Possible values are 1 1856 "IPv4" or 2 "IPv6". Either an IPv4 list or an IPv6 list or both 1857 MAY be present in the List-Action TLV. 1859 o Number of flow fields: the number of multicast flow fields of the 1860 given address family which follow. 1862 o Multicast flow field: a field identifying one or more multicast 1863 flows. It consists of an 8-bit group address prefix length, an 1864 8-bit source address prefix length, a 0-16 octet group prefix, and 1865 a 0-16 octet source prefix, as shown in Figure 9. 1867 Each multicast flow field refers either to a Source-Specific 1868 Multicast (SSM) channel or to an Any Source Multicast (ASM) group. 1869 The scope of the designation may be broadened to multiple channels or 1870 groups through use of prefix length values smaller than the total 1871 address length for the given address family. Multicast flow fields 1872 MUST be placed consecutively within the embedded TLV without 1873 intervening padding except to round out individual addresses to the 1874 nearest octet boundary. 1876 A multicast flow field consists of two single-octet prefix lengths 1877 followed by zero to two prefix values as shown in Figure 9: 1879 +-+-+-+-+-+-+-+-+ 1880 | Group PrefLen | 1881 +-+-+-+-+-+-+-+-+ 1882 | Source PrefLen| 1883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1884 | Group Prefix (multicast) (0 to 16 octets) | 1885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1886 | Source Prefix (unicast, SSM only) (0 to 16 octets) | 1887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1889 Figure 9: Organization of a Single Multicast Flow Field 1891 The prefix length has its usual meaning. It is the number of most- 1892 significant bits specified within the corresponding prefix. The 1893 prefix length MAY vary from 0 to 32 in the IPv4 sub-list, and from 0 1894 to 128 in the IPv6 sub-list. 1896 A value of 0 for either the Group PrefLen (prefix length) or the 1897 Source PrefLen indicates that any value of the corresponding address 1898 will match (wild card). If the value 0 is provided for a particular 1899 prefix length, the corresponding prefix MUST be omitted from the 1900 field contents. 1902 The length of a Source or Group Prefix field is equal to (PrefLen + 1903 7)/8 octets, truncated to the nearest integer. Unused bits at the 1904 end of the prefix MUST be set to zeroes. 1906 5.4. Sequence-Number TLV 1908 The Sequence-Number TLV conveys a sequence number of some sort. The 1909 specific meaning of the sequence number is message-specific. Within 1910 this specification, the Sequence-Number TLV is used as a embedded TLV 1911 in a Status-Info TLV, in a Generic Response reporting a failed 1912 command in a Multicast Replication Control or Multicast Admission 1913 Request message. It identifies the sequence number within the 1914 message of the command that failed. 1916 The Sequence-Number TLV has the format shown in Figure 10. 1918 1 2 3 1919 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 1920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1921 | Type = Sequence-Number 0x0022 | TLV Length = 4 | 1922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1923 | Sequence number | 1924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1926 Figure 10: Sequence-Number TLV 1928 The Sequence-Number TLV has the following fields: 1930 o The Sequence-Number TLV Type is 0x0022. 1932 o TLV length is 4. 1934 o Sequence number: the sequence number of a specific entity within a 1935 series, where numbering starts from 1 for the first entity in the 1936 series. Represented as a 32-bit binary number, most significant 1937 bit first. 1939 5.5. Bandwidth-Allocation TLV 1941 The Bandwidth-Allocation TLV is used to indicate the total amount of 1942 video bandwidth delegated to the AN for multicast admission control 1943 for a given access line, in kilobits per second. The TLV has the 1944 format shown in Figure 11. 1946 1 2 3 1947 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 1948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1949 | Bandwidth-Allocation 0x0015 | TLV Length = 4 | 1950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1951 | Delegated amount (kbits/s) | 1952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1954 Figure 11: The Bandwidth-Allocation TLV 1956 The Bandwidth-Allocation TLV has the following fields: 1958 o The Bandwidth-Allocation TLV Type is 0x0015. 1960 o TLV length is 4. 1962 o Delegated amount: the bandwidth amount delegated to the AN for 1963 admission of multicast video on a given port, kilobits per second. 1964 Presented as a 32-bit binary value, most significant bit first. 1966 5.6. White-List-CAC TLV 1968 The White-List-CAC TLV is used to indicate that the NAS wishes the AN 1969 to do admission control for white-listed flows. Details on when the 1970 White-List-CAC TLV may be provisioned are specified in Section 6. 1971 The White-List-CAC TLV is illustrated in Figure 12. 1973 1 2 3 1974 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 1975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1976 | Type = White-List-CAC 0x0024 | TLV Length = 0 | 1977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1979 Figure 12: White-List-CAC TLV 1981 The White-List-CAC TLV contains the following fields: 1983 o The White-List-CAC TLV Type is 0x0024. 1985 o TLV length is 0, since the TLV contains no data other than the TLV 1986 header. 1988 5.7. MRepCtl-CAC TLV 1990 The MRepCtl-CAC TLV is used to indicate that the NAS wishes the AN to 1991 do admission control for flows added by the Multicast Replication 1992 Control message. Details on when the MRepCtl-CAC TLV may be 1993 provisioned are specified in Section 6. The MRepCtl-CAC TLV is 1994 illustrated in Figure 13. 1996 1 2 3 1997 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 1998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1999 |TLV Type = MRepCtl-CAC 0x0025 | TLV Length = 0 | 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2002 Figure 13: MRepCtl-CAC TLV 2004 The MRepCtl-CAC TLV contains the following fields: 2006 o The MRepCtl-CAC TLV Type is 0x0025. 2008 o TLV length is 0, since the TLV contains no data other than the TLV 2009 header. 2011 5.8. Bandwidth-Request TLV 2013 The Bandwidth-Request TLV is used to request an adjustment of the 2014 total amount of video bandwidth allocated to the AN for multicast 2015 admission control for a given line. The "Required amount" field 2016 indicates the minimum adjustment required to meet the request. The 2017 "Preferred amount" field indicates the adjustment the requestor would 2018 prefer to have, if possible. Section 4.5 discusses the required 2019 relationships between the "Required amount", "Preferred amount", and 2020 current values of total bandwidth allocated to the AN. 2022 The Bandwidth-Request TLV has the format shown in Figure 14. 2024 1 2 3 2025 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 2026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2027 | Type=Bandwidth-Request 0x0016 | TLV Length = 8 | 2028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2029 | Required amount (kbits/s) | 2030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2031 | Preferred amount (kbits/s) | 2032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2034 Figure 14: The Bandwidth-Request TLV 2036 The Bandwidth-Request TLV has the following fields: 2038 o The Bandwidth-Request TLV Type is 0x0016. 2040 o The TLV length is 8 octets. 2042 o Required amount: the minimum or maximum amount, depending on 2043 whether the sender is the AN or the NAS respectively, of delegated 2044 video bandwidth that is being requested, in kilobits per second. 2045 Presented as a 32-bit binary value, most significant bit first. 2047 o Preferred amount: the preferred amount of delegated video 2048 bandwidth that is being requested, in kilobits per second. 2049 Presented as a 32-bit binary value, most significant bit first. 2051 5.9. Subs-Session-Id TLV 2053 The Subs-Session-Id TLV provides a subscriber session identifier for 2054 the entity that originated a specific request to join or leave a 2055 multicast channel. The subscriber session identifier is a value 2056 derived according to local policy from one of the types specified in 2057 [TR-146] requirement R43. The TLV is illustrated in Figure 15. 2059 1 2 3 2060 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 2061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2062 | Type = Subs-Session-Id 0x0092 | TLV length | 2063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2064 | Value | 2065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2067 Figure 15: Subs-Session-Id TLV 2069 The Subs-Session-Id TLV contains the following fields: 2071 o The Subs-Session-Id TLV Type is 0x0092. 2073 o TLV length depends on the type of identifier used. 2075 o Value is the configured value of the identifier. 2077 5.10. Multicast-Flow TLV 2079 The Multicast-Flow TLV specifies a multicast flow in terms of its 2080 multicast group address and, if applicable, its unicast source 2081 address. It is illustrated in Figure 16. 2083 1 2 3 2084 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 2085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2086 | Type = Multicast-Flow 0x0019 | TLV Length | 2087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2088 | Flow Type | Addr Family | Reserved | 2089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2090 | Multicast Group Address | 2091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 2092 | Unicast Source Address (for SSM flows only) | 2093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2095 Figure 16: Multicast-Flow TLV 2097 The Multicast-Flow TLV has the following fields: 2099 o The Multicast-Flow TLV Type is 0x0019. 2101 o TLV Length: ranges from a minimum of 8 (for an ASM IPv4 flow) to 2102 36 (for an IPv6 SSM flow). 2104 o Flow Type: 1 "Any Source Multicast (ASM)", 2 "Source-Specific 2105 Multicast (SSM)". 2107 o Addr Family: address family of the multicast source and group 2108 addresses, encoded in accordance with the IANA PIM Address Family 2109 registry ([PIMreg]). 1 indicates IPv4, 2 indicates IPv6. 2111 o Reserved: MUST be set to zeroes by the sender and MUST be ignored 2112 by the receiver. 2114 One possible use for this field in the future is to indicate 2115 the presence of PIM Join attributes attached to the source 2116 address (see [RFC5384]). The applicability of PIM attributes 2117 in the context of ANCP is for further study. 2119 o Multicast Group Address: a multicast group address within the 2120 given address family. The group address MUST always be present. 2122 o Unicast Source Address: unicast address within the given address 2123 family. If the Flow Type is "ASM" (1), a source address MUST NOT 2124 be present. If the Flow Type is "SSM" (2), a source address MUST 2125 be present. 2127 5.11. Report-Buffering-Time TLV 2129 The Report-Buffering-Time TLV provides the time for which a Committed 2130 Bandwidth Report message must be held with the intention of 2131 accumulating multiple reports of changed committed multicast 2132 bandwidth in one report, to reduce the volume of messages sent to the 2133 NAS. For further information see Section 6.2.2. The TLV is 2134 illustrated in Figure 17. 2136 1 2 3 2137 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 2138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2139 | Report-Buffering-Time 0x0094 | TLV Length = 4 | 2140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2141 | Buffering Time (ms) | 2142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2144 Figure 17: Report-Buffering-Time TLV 2146 The Report-Buffering-Time TLV contains the following fields: 2148 o The Report-Buffering-Time TLV Type is 0x0094. 2150 o TLV length is 4 octets. 2152 o Buffering Time is a 32-bit unsigned integer containing a time 2153 value in ms. 2155 5.12. Committed-Bandwidth TLV 2157 The Committed-Bandwidth TLV identifies an access line and provides 2158 the current amount of multicast bandwidth that the AN has committed 2159 to it. The TLV is illustrated in Figure 18. 2161 1 2 3 2162 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 2163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2164 | Committed-Bandwidth 0x0095 | TLV Length (variable) | 2165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2166 | Committed Multicast Bandwidth (kbits/s) | 2167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2168 | | 2169 ~ Target TLV ~ 2170 | | 2171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2173 Figure 18: Committed-Bandwidth TLV 2175 The Committed-Bandwidth TLV contains the following fields: 2177 o The Committed-Bandwidth TLV Type is 0x0095. 2179 o TLV length is 4 octets plus the length of the Target TLV including 2180 its header and any padding. 2182 o Committed Multicast Bandwidth is a 32-bit unsigned integer 2183 providing a bandwidth amount in kbits/s. 2185 o The Target TLV identifies the access line to which this amount of 2186 multicast bandwidth is currently committed. 2188 6. Multicast Capabilities 2190 Section 3.5 of [RFC6320] defines a capability negotiation mechanism 2191 as well as a number of capabilities. This section defines five new 2192 capabilities in support of different modes of multicast operation: 2194 o NAS-initiated replication (capability type 3); 2196 o committed multicast bandwidth reporting (capability type 5); 2198 o conditional access with white and black lists (capability type 6); 2200 o conditional access with grey lists (capability type 7); 2202 o bandwidth delegation (capability type 8). 2204 The "Capability Data" field within the Capability TLV for all of 2205 these capabilities is empty. All of these capabilities are 2206 independent of the access technology. 2208 The remainder of this section consists of three sub-sections. 2209 Section 6.1 specifies the protocol elements that must be implemented 2210 in order to support each capability. Section 6.2 specifies the 2211 procedures that apply to each capability on its own. Section 6.3 2212 specifies how the capabilities interact if more than one multicast 2213 capability is included in the set of capabilities negotiated between 2214 the AN and the NAS. 2216 6.1. Required Protocol Support 2218 This section specifies the protocol elements that MUST be implemented 2219 to support each of the four multicast capabilities. Support of 2220 multiple multicast capabilities requires implementation of the union 2221 of the sets of protocol elements applying to each of the individual 2222 capabilities in the supported set. 2224 In addition to the elements listed below, implementation of the 2225 Target TLV (Section 4.3 of [RFC6320]) is REQUIRED for all of the 2226 capabilities specified in this document. 2228 6.1.1. Protocol Requirements For NAS-Initiated Replication 2230 Table 1 specifies the protocol elements within Section 4 and 2231 Section 5 that MUST be implemented to support the NAS-initiated 2232 replication multicast capability. Additionally, implementation of 2233 the Multicast Replication Control message requires implementation of 2234 the Command TLV (Section 4.4 of [RFC6320] with additional details in 2235 Section 4.3 of this document). 2237 +--------------+----------------------------------------------------+ 2238 | Reference | Protocol Element | 2239 +--------------+----------------------------------------------------+ 2240 | Section 4.1 | Provisioning message with MRepCtl-CAC TLV | 2241 | | | 2242 | Section 4.2 | Port Management message with Bandwidth-Allocation | 2243 | | TLV. | 2244 | | | 2245 | Section 4.3 | Multicast Replication Control message | 2246 | | | 2247 | Section 4.9 | Multicast Flow Query Request and Response messages | 2248 | | | 2249 | Section 5.4 | Sequence Number TLV | 2250 | | | 2251 | Section 5.5 | Bandwidth-Allocation TLV | 2252 | | | 2253 | Section 5.7 | MRepCtl-CAC TLV | 2254 | | | 2255 | Section 5.10 | Multicast-Flow TLV | 2256 +--------------+----------------------------------------------------+ 2258 Table 1: Protocol Requirements For NAS-Initiated Replication 2260 6.1.2. Protocol Requirements For Committed Multicast Bandwidth 2261 Reporting 2263 Table 2 specifies the protocol elements within Section 4 and 2264 Section 5 that MUST be implemented to support the committed multicast 2265 bandwidth reporting capability. 2267 +--------------+----------------------------------------------------+ 2268 | Reference | Protocol Element | 2269 +--------------+----------------------------------------------------+ 2270 | Section 4.1 | Provisioning message with Report-Buffering-Time | 2271 | | TLV | 2272 | | | 2273 | Section 4.10 | Committed Bandwidth Report message | 2274 | | | 2275 | Section 4.9 | Multicast Flow Query Request and Response messages | 2276 | | | 2277 | Section 5.11 | Report-Buffering-Timer TLV | 2278 | | | 2279 | Section 5.12 | Committed-Bandwidth TLV | 2280 | | | 2281 | Section 5.10 | Multicast-Flow TLV | 2282 +--------------+----------------------------------------------------+ 2284 Table 2: Protocol Requirements For Committed Multicast Bandwidth 2285 Reporting 2287 6.1.3. Protocol Requirements For Conditional Access With White and 2288 Black Lists 2290 Table 3 specifies the protocol elements within Section 4 and 2291 Section 5 that MUST be implemented to support the conditional access 2292 with white and black lists multicast capability. 2294 +-----------+-------------------------------------------------------+ 2295 | Reference | Protocol Element | 2296 +-----------+-------------------------------------------------------+ 2297 | Section | Provisioning message with Multicast-Service-Profile | 2298 | 4.1 | TLV, white and black lists only, and White-List-CAC | 2299 | | TLV | 2300 | | | 2301 | Section | Port Management message with Multicast-Service- | 2302 | 4.2 | Profile-Name and Bandwidth-Allocation TLVs. | 2303 | | | 2304 | Section | Multicast Flow Query Request and Response messages | 2305 | 4.9 | | 2306 | | | 2307 | Section | Multicast-Service-Profile TLV | 2308 | 5.1 | | 2309 | | | 2310 | Section | Multicast-Service-Profile-Name TLV | 2311 | 5.2 | | 2312 | | | 2313 | Section | List-Action TLV, white and black lists only | 2314 | 5.3 | | 2315 | | | 2316 | Section | Bandwidth-Allocation TLV | 2317 | 5.5 | | 2318 | | | 2319 | Section | White-List-CAC TLV | 2320 | 5.6 | | 2321 | | | 2322 | Section | Multicast-Flow TLV | 2323 | 5.10 | | 2324 +-----------+-------------------------------------------------------+ 2326 Table 3: Protocol Requirements For Conditional Access with White and 2327 Black Lists 2329 6.1.4. Protocol Requirements For Conditional Access With Grey Lists 2331 Table 4 specifies the protocol elements within Section 4 and 2332 Section 5 that MUST be implemented to support the conditional access 2333 with grey lists multicast capability. Additionally, implementation 2334 of the Multicast Replication Control message requires implementation 2335 of the Command TLV (Section 4.4 of [RFC6320] with additional details 2336 in Section 4.3 of this document). 2338 +-----------+-------------------------------------------------------+ 2339 | Reference | Protocol Element | 2340 +-----------+-------------------------------------------------------+ 2341 | Section | Provisioning message with Multicast-Service-Profile | 2342 | 4.1 | TLV, grey lists only, and MRepCtl-CAC TLV | 2343 | | | 2344 | Section | Port Management message with Multicast-Service- | 2345 | 4.2 | Profile-Name and Bandwidth-Allocation TLVs. | 2346 | | | 2347 | Section | Multicast Replication Control message | 2348 | 4.3 | | 2349 | | | 2350 | Section | Multicast Admission Control Message | 2351 | 4.4 | | 2352 | | | 2353 | Section | Multicast Flow Query Request and Response messages | 2354 | 4.9 | | 2355 | | | 2356 | Section | Multicast-Service-Profile TLV, grey lists only | 2357 | 5.1 | | 2358 | | | 2359 | Section | Multicast-Service-Profile-Name TLV | 2360 | 5.2 | | 2361 | | | 2362 | Section | List-Action TLV, grey lists only | 2363 | 5.3 | | 2364 | | | 2365 | Section | Sequence Number TLV | 2366 | 5.4 | | 2367 | | | 2368 | Section | Bandwidth-Allocation TLV | 2369 | 5.5 | | 2370 | | | 2371 | Section | MRepCtl-CAC TLV | 2372 | 5.7 | | 2373 | | | 2374 | Section | Subs-Session-Id TLV | 2375 | 5.9 | | 2376 | | | 2377 | Section | Multicast-Flow TLV | 2378 | 5.10 | | 2379 +-----------+-------------------------------------------------------+ 2381 Table 4: Protocol Requirements For Conditional Access with Grey Lists 2383 6.1.5. Protocol Requirements For Delegated Bandwidth 2384 Table 5 specifies the protocol elements within Section 4 and 2385 Section 5 that MUST be implemented to support the delegated bandwidth 2386 multicast capability. 2388 +--------------+----------------------------------------------------+ 2389 | Reference | Protocol Element | 2390 +--------------+----------------------------------------------------+ 2391 | Section 4.2 | Port Management message with Bandwidth-Allocation | 2392 | | TLV. | 2393 | | | 2394 | Section 4.5 | Bandwidth Reallocation Request Message | 2395 | | | 2396 | Section 4.6 | Bandwidth Transfer Message | 2397 | | | 2398 | Section 4.7 | Delegated Bandwidth Query Request Message | 2399 | | | 2400 | Section 4.8 | Delegated Bandwidth Query Response Message | 2401 | | | 2402 | Section 4.9 | Multicast Flow Query Request and Response messages | 2403 | | | 2404 | Section 5.5 | Bandwidth-Allocation TLV | 2405 | | | 2406 | Section 5.8 | Bandwidth-Request TLV | 2407 | | | 2408 | Section 5.10 | Multicast-Flow TLV | 2409 +--------------+----------------------------------------------------+ 2411 Table 5: Protocol Requirements For Delegated Bandwidth 2413 6.2. Capability-Specific Procedures for Providing Multicast Service 2415 This section describes multicast service procedures for each 2416 capability as if it were the only multicast capability within the 2417 negotiated set. Procedures involving combinations of multicast 2418 capabilities are described in Section 6.3. 2420 The use of the Multicast Flow Query Request and Response messages to 2421 determine the association between multicast flows and ports is common 2422 to all multicast capabilities. No additional text is required here, 2423 beyond that already given in Section 4.9 to describe the use of those 2424 messages. 2426 6.2.1. Procedures For NAS-Initiated Replication 2428 NAS-initiated replication may be negotiated to support a mode of 2429 operation where IGMP/MLD requests are terminated on the NAS. 2430 Alternatively, it may be negotiated to allow the NAS to respond to 2431 requests sent by other means (e.g., through application signalling) 2432 that require the replication of multicast channels to a given access 2433 line. 2435 6.2.1.1. Provisioning 2437 The NAS MAY perform resource-based admission control for NAS- 2438 initiated replication. In this case, it MUST NOT include the 2439 MRepCtl-CAC TLV in a Provisioning message sent to the AN. 2440 Alternatively, the NAS MAY enable resource-based admission control at 2441 the AN for NAS-initiated replication. To do this, it MUST include 2442 the MRepCtl-CAC TLV in a Provisioning message sent to the AN and it 2443 MUST also include a Bandwidth-Allocation TLV in a Port Management 2444 message for each access line. 2446 6.2.1.2. Multicast Service Procedures 2448 The procedures associated with NAS-initiated replication are 2449 straightforward. To initiate replication, the NAS MUST send a 2450 Multicast Replication Control message to the AN, containing one or 2451 more commands adding flows, as described in Section 4.3.1. To 2452 terminate replication the NAS MUST send a Multicast Replication 2453 Control message where the commands delete instead of adding the 2454 flows. The AN acts upon these messages as specified in 2455 Section 4.3.2. 2457 6.2.2. Procedures For Committed Bandwidth Reporting 2459 Committed bandwidth reporting may be negotiated if the NAS requires 2460 current knowledge of the amount of multicast bandwidth committed to 2461 each access line and cannot obtain this information by other means. 2463 6.2.2.1. Provisioning 2465 The default buffering time when committed bandwidth reporting is 2466 enabled is zero (immediate reporting). To change this, the NAS MAY 2467 send an instance of the Report-Buffering-Time TLV containing a non- 2468 zero time value to the AN in a Provisioning message. If the NAS 2469 subsequently wishes to change the buffering time again, it MAY do so 2470 in another Provisioning message. 2472 6.2.2.2. Multicast Service Procedures 2474 If the buffering time for committed bandwidth reporting is zero, the 2475 AN MUST send a Committed Bandwidth Report message to the NAS each 2476 time the amount of multicast bandwidth committed to any access line 2477 under its control changes. 2479 If a non-zero value is provided in the Report-Buffering-Time TLV, the 2480 AN at any given moment is in one of two states: not-buffering, or 2481 buffering. The AN enters buffering state if it is in not-buffering 2482 state and the multicast bandwidth amount committed to some access 2483 line changes. It leaves buffering state when the AN sends a 2484 Committed Bandwidth Report. 2486 Upon entry to the buffering state, the AN MUST start a buffering 2487 timer and create a Committed Bandwidth Report message containing a 2488 Committed-Bandwidth TLV for the triggering access line, but MUST NOT 2489 send it. If a multicast bandwidth change occurs for another access 2490 line, the AN MUST add a new Committed-Bandwidth TLV to the message 2491 for that additional line. If a multicast bandwidth change occurs for 2492 a line for which a Committed-Bandwidth TLV is already present in the 2493 buffered report, the AN MUST update the corresponding Committed- 2494 Bandwidth TLV to contain the new bandwidth value, rather than adding 2495 another Committed-Bandwidth TLV for the same access line. 2497 The buffering timer expires after the period provided by the Report- 2498 Buffering-Time TLV. When it expires, the AN MUST send the Committed 2499 Bandwidth Report message that it has been accumulating to the NAS. 2500 Exceptionally, the AN MAY choose to send the message before the timer 2501 expires, in which case it MUST clear the buffering timer when the 2502 message is sent. In either case, the AN enters the not-buffering 2503 state as a result. 2505 Report buffering implies that NAS reaction to changes in multicast 2506 bandwidth usage is delayed by the amount of the buffering period. 2507 The choice of buffering period must take this into consideration. 2509 6.2.3. Procedures For Conditional Access With Black and White Lists 2511 6.2.3.1. Provisioning 2513 The NAS provisions named multicast service profiles containing white 2514 and black lists on the AN using the Provisioning message containing 2515 one or more Multicast-Service-Profile TLVs. The NAS MAY update the 2516 contents of these profiles from time to time as required, by sending 2517 additional Provisioning messages with Multicast-Service-Profile TLVs 2518 containing incremental modifications to the existing white and black 2519 lists or replacements for them. 2521 The NAS assigns a specific multicast service profile to an individual 2522 access line using the Port Management message containing a Multicast- 2523 Service-Profile-Name TLV. The NAS MAY change the multicast service 2524 profile for a given access line at any time by sending a Port 2525 Management message identifying a new multicast service profile. 2527 The NAS MAY choose to enable resource-based admission control at the 2528 AN for white-listed flows. To do this, it MUST send a Provisioning 2529 message as described in Section 4.1, which includes the White-List- 2530 CAC TLV and it MUST provide a multicast bandwidth allocation for each 2531 access line by including a Bandwidth-Allocation TLV in a Port 2532 Management message. 2534 6.2.3.2. Multicast Service Procedures 2536 The conditional access with white and black lists capability assumes 2537 that IGMP/MLD requests are terminated on the AN. When the AN 2538 receives a "join" request, it MUST check to see whether the requested 2539 flow is white-listed or black-listed as described below. Requests 2540 for black-listed flows MUST be discarded. If the NAS has enabled 2541 resource-based admission control on the AN as described in the 2542 previous section, but a white-listed flow would cause the amount of 2543 committed multicast bandwidth to exceed the provisioned limit, the 2544 request MUST be discarded. The AN replicates flows passing these 2545 checks to the access line. 2547 To determine if a requested flow is white-listed, the AN searches for 2548 a best match to the flow in the applicable multicast service profile. 2549 Matching is done on the prefixes specified in the profile, ignoring 2550 the address bits of lower order than those in the prefix. 2552 If the requested multicast flow matches multiple lists associated 2553 with the access line, then the most specific match will be considered 2554 by the AN. If the most specific match occurs in multiple lists, the 2555 black list entry takes precedence over the white list. In this 2556 context, the most specific match is defined as: 2558 o first, most specific match (longest prefix length) on the 2559 multicast group address (i.e., on G of ) 2561 o then, most specific match (longest prefix length) on the unicast 2562 source address (i.e. on S of ) 2564 If the requested multicast flow is not part of any list, the join 2565 message SHOULD be discarded by the AN. This default behavior can 2566 easily be changed by means of a "catch-all" statement in the white 2567 list. For instance, adding () in the white List would make 2568 the default behavior to accept join messages for a multicast flow 2569 that has no other match on any list. 2571 When the AN receives a "leave" request, it terminates replication of 2572 the multicast flow. 2574 If the AN receives a Provisioning message which updates an existing 2575 multicast service profile, the AN MUST review the status of active 2576 flows on all ports to which the updated profile is currently 2577 assigned. Similarly, if a Port Management message assigns a new 2578 multicast service profile to a given port, the AN MUST review all 2579 active flows on that port. If the most specific match for any flow 2580 is a black list entry, the flow MUST be terminated immediately. If 2581 any of the remaining flows do not match an entry in the white list, 2582 they also MUST be terminated immediately. White listed flows MUST be 2583 allowed to continue. 2585 6.2.4. Procedures For Conditional Access With Grey Lists 2587 6.2.4.1. Provisioning 2589 The NAS provisions named multicast service profiles containing grey 2590 lists on the AN using the Provisioning message containing one or more 2591 Multicast-Service-Profile TLVs. The NAS MAY update the contents of 2592 these profiles from time to time as required, by sending additional 2593 Provisioning messages with Multicast-Service-Profile TLVs containing 2594 incremental modifications to the existing grey lists or replacements 2595 for them. 2597 The NAS assigns a specific multicast service profile to an individual 2598 access line using the Port Management message containing a Multicast- 2599 Service-Profile-Name TLV. The NAS MAY change profiles on the line by 2600 sending a subsequent Port Management message identifying a new 2601 profile. 2603 The NAS MAY perform resource-based admission control for grey-listed 2604 flows. In that case, the NAS MUST NOT include the MRepCtl-CAC TLV in 2605 a Provisioning message sent to the AN. Alternatively, the NAS MAY 2606 enable resource-based admission control at the AN for grey-listed 2607 flows. To do this, it MUST include the MRepCtl-CAC TLV in a 2608 Provisioning message sent to the AN and MUST also provide a 2609 Bandwidth-Allocation TLV in a Port Management message for each access 2610 line. 2612 6.2.4.2. Multicast Service Procedures 2614 The conditional access with grey lists capability assumes that IGMP/ 2615 MLD requests are terminated on the AN. When the AN receives a "join" 2616 request, it MUST determine whether there is a match to the requested 2617 flow in the grey list of the multicast service profile provisioned 2618 against the given access line. If there is no match, the request is 2619 discarded. Otherwise, the AN MUST send a Multicast Admission Control 2620 message to the NAS with content identifying the access line and the 2621 multicast flow to be added. As indicated in Section 4.4, the AN MAY 2622 be configured to add a subscriber session identifier as described in 2623 [TR-146] requirement R43. 2625 If the NAS decides to enable the flow, it MUST send a Multicast 2626 Replication Control request to the AN to replicate the flow to the 2627 access line with the Result field set to Nack (0x1), as described in 2628 Section 4.3.1. 2630 When the AN receives the Multicast Replication Control request, it 2631 performs resource-based admission control if that has been enabled as 2632 described in the previous section. If admitting the flow would cause 2633 the committed multicast bandwidth at the access line to exceed the 2634 provisioned limit, the AN reports an error to the NAS as described in 2635 Section 4.3.2. Otherwise it replicates the multicast flow as 2636 requested. 2638 If the NAS decides not to permit the flow, it MAY send a Multicast 2639 Replication Control message in response to the Multicast Admission 2640 Control message to allow the AN to update its internal records. The 2641 content of this message is described in Section 4.4.2. 2643 When the AN receives a "leave" request, it MUST terminate replication 2644 of the flow to the access line. It MUST then send a Multicast 2645 Admission Control message to the NAS indicating the deletion. The 2646 NAS updates its internal records but MUST NOT respond to the message. 2648 If the AN receives a Provisioning message which updates an existing 2649 multicast service profile, the AN MUST review the status of active 2650 flows on all ports to which the updated profile has been assigned. 2651 Similarly, if a Port Management message that assigns a new profile to 2652 a given port, the AN MUST review all active flows on that port. In 2653 either case, if any flow does not match an entry in the grey list, it 2654 MUST be terminated immediately. 2656 6.2.5. Procedures For Delegated Bandwidth 2658 6.2.5.1. Provisioning 2660 The NAS SHOULD provision an initial amount of delegated multicast 2661 bandwidth for each access line using the Port Management message 2662 containing the Bandwidth-Allocation TLV. 2664 If it fails to do so and a value has not been provisioned on the 2665 AN by other means, the AN will be forced to request a bandwidth 2666 allocation as soon as it receives a "join" request. 2668 The NAS MAY at any time force an update of the amount of delegated 2669 bandwidth by the same means. 2671 6.2.5.2. Multicast Service Procedures 2673 The delegated bandwidth capability assumes that IGMP/MLD requests are 2674 terminated on the AN. When the AN receives a "join" request, it 2675 checks whether it has sufficient remaining uncommitted multicast 2676 bandwidth on the access line to accommodate the new multicast flow. 2677 If not, it MAY send a request to the NAS for an increased allocation 2678 of delegated bandwidth, using the Bandwidth Reallocation Request 2679 message. The NAS MUST return a Bandwidth Transfer message indicating 2680 whether it has granted the request, and if so, what is the new amount 2681 of delegated bandwidth. 2683 If the AN has sufficient uncommitted multicast capacity to admit the 2684 request, either originally or as the result of a successful request 2685 to the NAS, it replicates the requested flow to the access line. 2686 Otherwise it discards the request. 2688 When the AN receives a "leave" request for an active flow, it ceases 2689 replication. 2691 The NAS or AN MAY at some point detect that their respective views of 2692 the amount of delegated bandwidth are inconsistent. If so, they can 2693 recover using procedures described in Section 4.5 and Section 4.6. 2694 As a further aid to synchronization, either the NAS or the AN MAY 2695 from time to time check the peer's view of the amount of delegated 2696 bandwidth using the Delegated Bandwidth Query message. 2698 The NAS or AN MAY at any time release bandwidth to the peer using an 2699 autonomous Bandwidth Transfer message. The contents of this message 2700 are described in Section 4.6. 2702 6.3. Combinations of Multicast Capabilities 2704 6.3.1. Combination of Conditional Access With White and Black Lists and 2705 Conditional Access With Grey Lists 2707 If conditional access with white and black lists is combined with 2708 conditional access with grey lists, provisioning of the multicast 2709 service profiles is as described in Section 6.2.3.1 except that 2710 multicast service profiles will also include grey lists. Resource- 2711 based admission control is enabled independently on the AN for white 2712 lists by including the White-List-CAC TLV in the Provisioning message 2713 and for grey lists by including the MRepCtl-CAC TLV in the 2714 Provisioning message. The Bandwidth-Allocation TLV provisions an 2715 amount that applies to both white- and grey- listed flows if 2716 resource-based admission control is enabled for both. 2718 With regard to multicast service procedures, one point of difference 2719 from the individual capabilities must be noted. This is an 2720 interaction during the profile matching procedure. The AN MUST seek 2721 the best match amongst multiple lists as described in 2722 Section 6.2.3.2. However, if there are multiple matches of equal 2723 precision, the order of priority is black list first, grey list 2724 second, and white list last. 2726 Once profile matching has been completed, processing of a "join" 2727 request is as described in Section 6.2.3.2 for white or black listed 2728 flows or Section 6.2.4.2 for grey listed flows. Requests that do not 2729 match any list SHOULD be discarded. 2731 When the AN receives a "leave" request, it MUST terminate replication 2732 of the flow to the access line. If the flow was grey-listed, the AN 2733 MUST then send a Multicast Admission Control message to the NAS 2734 indicating the deletion. 2736 If the AN receives a Provisioning message which updates an existing 2737 multicast service profile, the AN MUST review the status of active 2738 flows on all ports to which the updated profile is currently 2739 assigned. Similarly, if a Port Management message assigns a new 2740 multicast service profile to a given port, the AN MUST review all 2741 active flows on that port. If any flow has its most specific match 2742 in a black list entry, it MUST be terminated immediately. If any of 2743 the remaining flows do not match an entry in the white or grey list, 2744 they MUST also be terminated immediately. Finally, if any remaining 2745 flows were originally admitted because they were white-listed, but 2746 after the change they are grey-listed, the AN MUST generate a 2747 Multicast Flow Query response message autonomously as if it were 2748 responding to a Multicast Flow Query request, listing all such flows. 2749 These flows MUST be allowed to continue until the NAS or the 2750 subscriber terminates them. Flows with their most specific match in 2751 the white list MUST be allowed to continue. 2753 The autonomously-generated Multicast Flow Query response message MUST 2754 be formatted as if it were a successful response to a request 2755 containing no Target and no Multicast-Flow TLV, as described in 2756 Section 4.9.2, with the exception that the Transaction-Id MUST be set 2757 to all zeroes. 2759 The procedures in the previous paragraphs imply that the AN has to 2760 retain a memory of whether an admitted flow was white-listed or 2761 grey-listed at the time of its admission/readmission. 2763 6.3.2. Combination of Conditional Access With Delegated Bandwidth 2764 The provisioning and bandwidth management procedures of Section 6.2.5 2765 apply in addition to the procedures in Section 6.2.3, Section 6.2.4, 2766 or Section 6.3.1 as applicable. Admission control follows the rules 2767 for conditional access in terms of matching flows against white and 2768 black and/or grey lists and performing or not performing bandwidth 2769 checks at the AN, but the amount of bandwidth used by the AN to 2770 perform resource-based admission control is negotiable as described 2771 in Section 6.2.5.2. 2773 6.3.3. Combination of NAS-Initiated Replication with Other Capabilities 2775 NAS-initiated replication can coexist with the other capabilities, 2776 but some means must exist to prevent double replication of flows. 2777 The simplest way to do this is to terminate all IGMP/MLD requests on 2778 the AN, so that NAS-initiated replication is stimulated only by 2779 signalling through other channels. Other arrangements are possible, 2780 but need not be discussed here. 2782 Assuming the necessary separation of responsibilities, the only point 2783 of interaction between NAS-initiated replication and the other 2784 multicast capabilities is in the area of resource-based admission 2785 control. Specifically, if the AN is to do resource-based admission 2786 control for flows added by Multicast Replication Control messages, 2787 regardless of whether they are part of NAS-initiated replication or 2788 grey list multicast service processing, the NAS includes the MRepCtl- 2789 CAC TLV in a Provisioning message and the Bandwidth-Allocation TLV in 2790 a Port Management message. If instead the NAS will do resource-based 2791 admission control for flows added by Multicast Replication Control 2792 messages, regardless of whether they are part of NAS-initiated 2793 replication or grey list multicast service processing, it does not 2794 send the MRepCtl-CAC TLV in a Provisioning messages to the AN. The 2795 NAS can independently enable resource-based admission control for 2796 white flows on the AN by including the White-List-CAC TLV in the 2797 Provisioning message. 2799 6.3.4. Combinations of Committed Bandwidth Reporting with Other 2800 Multicast Capabilities 2802 Committed bandwidth reporting can take place independently of which 2803 other multicast capabilities have been negotiated. However, some 2804 combinations do not make sense because of redundancy. In particular, 2805 the NAS obtains the same information that committed bandwidth 2806 reporting gives if the only other capabilities operating are NAS- 2807 initiated replication and/or conditional access with grey lists. 2809 7. Security Considerations 2810 The security considerations of ANCP are discussed in [RFC6320] and in 2811 [RFC5713]. Multicast does not in principle introduce any new 2812 security considerations, although it does increase the attractiveness 2813 of the ANCP protocol as a means of denial of service (e.g., through 2814 direction of multicast streams onto the target) or theft of service. 2816 8. IANA Considerations 2818 IANA NOTE: Please replace XXXX with the RFC number of this document. 2820 This document defines the following additional values within the ANCP 2821 Message Type Name Space registry: 2823 +--------------+--------------------------------+-----------+ 2824 | Message Type | Message Name | Reference | 2825 +--------------+--------------------------------+-----------+ 2826 | 144 | Multicast Replication Control | RFC XXXX | 2827 | | | | 2828 | 145 | Multicast Admission Control | RFC XXXX | 2829 | | | | 2830 | 146 | Bandwidth Reallocation Request | RFC XXXX | 2831 | | | | 2832 | 147 | Bandwidth Transfer | RFC XXXX | 2833 | | | | 2834 | 148 | Delegated Bandwidth Query | RFC XXXX | 2835 | | | | 2836 | 149 | Multicast Flow Query | RFC XXXX | 2837 | | | | 2838 | 150 | Committed Bandwidth Report | RFC XXXX | 2839 +--------------+--------------------------------+-----------+ 2841 This document defines the following additional values for the ANCP 2842 Result Code registry. In support of these assignments, IANA is 2843 requested to change the lower limit of 0x100 specified by [RFC6320] 2844 for assignments by IETF Consensus to 0x64. 2846 +------------+------------------------------------------+-----------+ 2847 | Result | One-Line Description | Reference | 2848 | Code | | | 2849 +------------+------------------------------------------+-----------+ 2850 | 0x64 | Command error. | RFC XXXX | 2851 | | | | 2852 | 0x65 | Invalid flow address. | RFC XXXX | 2853 | | | | 2854 | 0x66 | Multicast flow does not exist. | RFC XXXX | 2855 | | | | 2856 | 0x67 | Invalid preferred bandwidth amount. | RFC XXXX | 2857 | | | | 2858 | 0x68 | Inconsistent views of delegated | RFC XXXX | 2859 | | bandwidth amount. | | 2860 | | | | 2861 | 0x69 | Bandwidth request conflict. | RFC XXXX | 2862 +------------+------------------------------------------+-----------+ 2864 This document defines the following additional values for the ANCP 2865 Command Code registry: 2867 +----------------+--------------------------------------+-----------+ 2868 | Command Code | Command Code Directive Name | Reference | 2869 | Value | | | 2870 +----------------+--------------------------------------+-----------+ 2871 | 1 | Add | RFC XXXX | 2872 | | | | 2873 | 2 | Delete | RFC XXXX | 2874 | | | | 2875 | 3 | Delete All | RFC XXXX | 2876 | | | | 2877 | 4 | Admission Control Reject | RFC XXXX | 2878 | | | | 2879 | 5 | Conditional Access Reject | RFC XXXX | 2880 | | | | 2881 | 6 | Admission Control and Conditional | RFC XXXX | 2882 | | Access Reject | | 2883 +----------------+--------------------------------------+-----------+ 2885 This document defines the following additional values within the ANCP 2886 TLV Type Registry: 2888 +-----------+--------------------------------+-----------+ 2889 | Type Code | TLV Name | Reference | 2890 +-----------+--------------------------------+-----------+ 2891 | 0x0013 | Multicast-Service-Profile | RFC XXXX | 2892 | | | | 2893 | 0x0015 | Bandwidth-Allocation | RFC XXXX | 2894 | | | | 2895 | 0x0016 | Bandwidth-Request | RFC XXXX | 2896 | | | | 2897 | 0x0018 | Multicast-Service-Profile-Name | RFC XXXX | 2898 | | | | 2899 | 0x0019 | Multicast-Flow | RFC XXXX | 2900 | | | | 2901 | 0x0021 | List-Action | RFC XXXX | 2902 | | | | 2903 | 0x0022 | Sequence-Number | RFC XXXX | 2904 | | | | 2905 | 0x0024 | White-List-CAC | RFC XXXX | 2906 | | | | 2907 | 0x0025 | MRepCtl-CAC | RFC XXXX | 2908 | | | | 2909 | 0x0092 | Sub-Session-Id | RFC XXXX | 2910 | | | | 2911 | 0x0094 | Report-Buffering-Time | RFC XXXX | 2912 | | | | 2913 | 0x0095 | Committed-Bandwidth | RFC XXXX | 2914 +-----------+--------------------------------+-----------+ 2916 This document defines the following additional values for the ANCP 2917 Capability Type registry: 2919 +-------+-------------------------+--------+------------+-----------+ 2920 | Value | Capability Type Name | Tech | Capability | Reference | 2921 | | | Type | Data? | | 2922 +-------+-------------------------+--------+------------+-----------+ 2923 | 3 | NAS-Initiated | 0 | No | RFC XXXX | 2924 | | Replication | | | | 2925 | | | | | | 2926 | 5 | Committed Bandwidth | 0 | No | RFC XXXX | 2927 | | Reporting | | | | 2928 | | | | | | 2929 | 6 | Conditional Access With | 0 | No | RFC XXXX | 2930 | | White and Black Lists | | | | 2931 | | | | | | 2932 | 7 | Conditional Access With | 0 | No | RFC XXXX | 2933 | | Grey Lists | | | | 2934 | | | | | | 2935 | 8 | Bandwidth Delegation | 0 | No | RFC XXXX | 2936 +-------+-------------------------+--------+------------+-----------+ 2938 9. Acknowledgements 2940 The authors would like to acknowledge Wojciech Dec for providing 2941 useful input to this document, Robert Rennison for his help in 2942 shaping the definition of the Multicast-Service-Profile TLV, Shridhar 2943 Rao for his comments and suggestions and Aniruddha A for his proposal 2944 that formed the base of the Multicast Flow Reporting solution. 2945 Philippe Champagne, Sanjay Wadhwa and Stefaan De Cnodder provided 2946 substantial contributions on the solution for the NAS initiated 2947 multicast control use case. Kristian Poscic provided the committed 2948 bandwidth reporting use case. 2950 Thanks to the Document Shepherd, Matthew Bocci, and Area Director, 2951 Ted Lemon, for points raised by their reviews following Working Group 2952 Last Call. 2954 10. References 2956 10.1. Normative References 2958 [PIMreg] IANA, "http://www.iana.org/assignments/pim-parameters/ 2959 pim-parameters.xhtml", 2005. 2961 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2962 Requirement Levels", BCP 14, RFC 2119, March 1997. 2964 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 2965 Listener Discovery (MLD) for IPv6", RFC 2710, October 2966 1999. 2968 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 2969 Thyagarajan, "Internet Group Management Protocol, Version 2970 3", RFC 3376, October 2002. 2972 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 2973 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 2975 [RFC6320] Wadhwa, S., Moisand, J., Haag, T., Voigt, N., and T. 2976 Taylor, "Protocol for Access Node Control Mechanism in 2977 Broadband Networks", RFC 6320, October 2011. 2979 [TR-146] Broadband Forum, "TR-146, Subscriber Sessions", May 2013. 2981 10.2. Informative References 2983 [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol 2984 Independent Multicast (PIM) Join Attribute Format", RFC 2985 5384, November 2008. 2987 [RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security 2988 Threats and Security Requirements for the Access Node 2989 Control Protocol (ANCP)", RFC 5713, January 2010. 2991 [RFC5851] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. 2992 Wadhwa, "Framework and Requirements for an Access Node 2993 Control Mechanism in Broadband Multi-Service Networks", 2994 RFC 5851, May 2010. 2996 Appendix A. Example of Messages and Message Flows 2998 This appendix provides an example in which most of the possible 2999 message flows for multicast control are illustrated. This appendix 3000 is for informational purposes only. In case of discrepancy with text 3001 of the body of this document, the text in the body of the document is 3002 to be considered as the normative text. 3004 Assume the following, for a given access port: 3006 o The basic subscribed service is white-listed. The AN will be 3007 responsible for admission control for this service. 3009 o Some premium services are available, but requests for these 3010 services must be referred to the policy server for proper credit 3011 processing. For this reason they are grey-listed. The NAS will 3012 be responsible for admission control for these services. 3014 o The subscriber has asked that certain services be blocked so that 3015 his children cannot view them. These services are black-listed. 3017 o All of the above services are Source-Specific Multicast (SSM). In 3018 addition, by means which bypass the AN, the subscriber can signal 3019 intent to join an on-line game service which is Any Source 3020 Multicast (ASM). The NAS is responsible for admission control for 3021 this service. 3023 o Bandwidth delegation is in effect to share video bandwidth between 3024 the AN and the NAS. 3026 The stated conditions require the use of four of the five 3027 capabilities specified in this memo. 3029 A.1. Provisioning Phase 3031 Assume that capability negotiation has been completed between the AN 3032 and NAS and that the set of negotiated capabilities includes the 3033 following four multicast capabilities: NAS-initiated replication, 3034 conditional access with white and black list, conditional access with 3035 grey list, and bandwidth delegation. At this point, the NAS can 3036 provision the service profiles on the AN and enable admission control 3037 at the AN for white-listed flows. To do this, the NAS sends the AN a 3038 Provisioning message containing this information. An example message 3039 providing the profile for our assumed subscriber is shown in 3040 Figure 19. The message has the following contents: 3042 o Message type is 93. 3044 o The Result and Result Code fields in the header are set to zeroes, 3045 as specified [RFC6320]. 3047 o A transaction identifier is assigned by the NAS. 3049 o The Multicast-Service-Profile TLV (of which typically there would 3050 be multiple instances) contains a Multicast-Service-Profile-Name 3051 TLV (with a length of 20 octets assumed for the example) and three 3052 List-Action TLVs, one each for the white, grey, and black lists 3053 within the profile. The white list flows come in two sets of 3054 group addresses: 233.252.0.0/29, coming from a server at 3055 192.0.2.15, and 233.252.0.32/29, coming from a server at 3056 192.0.2.16. The grey-listed flows are in the band 233.252.0.64/ 3057 29, coming from a server at 192.0.2.21. Finally, the black list 3058 flows are two individual flows that happen to overlap with the 3059 grey list band: 233.252.0.65, and 233.252.0.69, also with source 3060 192.0.2.21. 3062 o The White-List-CAC TLV indicates that the AN does admission 3063 control on white-listed flows. 3065 1 2 3 3066 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 3067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3068 | Type (0x880C) | Length = 132 | 3069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3070 | Version | Msg Type = 93 | Res=0 | Result Code = 0 | 3071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3072 | Partition ID | Transaction Identifier | 3073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3074 |I| SubMessage Number | Length = 132 | 3075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3076 | Mcast-Service-Profile 0x0013 | TLV Length = 112 | 3077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3078 | Mcast-Svc-Profile-Name 0x0018 | Embedded TLV Length = 20 | 3079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3080 | Multicast service profile name | 3081 ~ = "Cust 0127-53681-0003" ~ 3082 | | 3083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3084 | TLV Type = List-Action 0x0021 | Embedded TLV Length = 28 | 3085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3086 | Operation = 1 | List Type = 1 | Reserved = 0x0000 | 3087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3088 | Address Family = 1 | List Length = 20 | 3089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3090 | G Preflen = 29| S Preflen = 32| Group prefix = | 3091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3092 | 233.252.0.0 | Source prefix = | 3093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3094 | 192.0.2.15 | G Preflen = 29| S Preflen = 32| 3095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3096 | Group prefix = 233.252.0.32 | 3097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3098 | Source prefix = 192.0.2.15 | 3099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3100 | TLV Type = List-Action 0x0021 | Embedded TLV Length = 18 | 3101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3102 | Operation = 1 | List Type = 3 | Reserved = 0x0000 | 3103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3104 | Address Family = 1 | List Length = 10 | 3105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3106 | G Preflen = 29| S Preflen = 32| Group prefix = / 3107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3108 / 233.252.0.64 | Source prefix = / 3109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3110 / 192.0.2.21 | Padding = 0x0000 | 3111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3112 | TLV Type = List-Action 0x0021 | Embedded TLV Length = 28 | 3113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3114 | Operation = 1 | List Type = 2 | Reserved = 0x0000 | 3115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3116 | Address Family = 1 | List Length = 20 | 3117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3118 | G Preflen = 32| S Preflen = 32| Group prefix = / 3119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3120 / 233.252.0.65 | Source prefix = / 3121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3122 / 192.0.2.21 | G Preflen = 32| S Preflen = 32| 3123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3124 | Group prefix = 233.252.0.69 | 3125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3126 | Source prefix = 192.0.2.21 | 3127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3128 | Type = White-List-CAC 0x0024 | TLV Length = 0 | 3129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3131 Figure 19: Example Provisioning Message 3133 Note that the padding after the middle List-Action TLV is counted as 3134 part of length of the Multicast-Service-Profile TLV, but is not 3135 included in the length of that List-Action TLV. Note also that the 3136 Length field in the message header, unlike those in the TLVs, 3137 includes the message header itself, as required by [RFC6320]. 3138 Finally, note that the Provisioning message does not include a 3139 MRepCtl-CAC TLV since in our example resource-based admission control 3140 for grey listed flows and for NAS-initiated replication is performed 3141 by the NAS. 3143 As soon as the AN port comes up, the AN sends an ANCP PORT_UP message 3144 to the NAS specifying the Access Loop Circuit ID. The NAS replies 3145 with an ANCP Port Management message that, together with the other 3146 parameters, includes the multicast service profile name to be 3147 associated to that port along with the initial amount of delegated 3148 bandwidth. The corresponding message flow is illustrated in 3149 Figure 20. 3151 +----------+ +---------+ +-----+ +-----+ 3152 |Subscriber| | Home | | AN | | NAS | 3153 +----------+ | Gateway | +-----+ +-----+ 3154 | +---------+ | | 3155 | | | | 3156 | | | | 3157 | | DSL Synch. | | 3158 | |---------------->| | 3159 | | |(M1)PORT_UP(Port ID) | 3160 | | |-------------------->| 3161 | | | (*) 3162 | | |(M2) PORT_MNGT | 3163 | | | (Port ID, | 3164 | | |Mcast S Profile Name,| 3165 | | |Bandwidth Allocation)| 3166 | | |<--------------------| 3168 (*) The NAS may optionally seek direction from an external 3169 Autorization/Policy Server 3171 Figure 20: Configuring an AN Port With Multicast Service Profile ID 3172 and Delegated Bandwidth Amount 3174 The Port Management message will typically contain other TLVs but our 3175 example (Figure 21) just shows the Target, Multicast-Service-Profile- 3176 Name, and Bandwidth-Allocation TLVs. The Target TLV identifies the 3177 subscriber line, the Multicast-Service-Profile-Name TLV is identical 3178 to the one contained in the Provisioning message, and the Bandwidth- 3179 Allocation TLV provides just enough bandwidth (2000 kbits/s) for one 3180 channel to start with. 3182 The following fields in the Port Management message header are shown 3183 with specific values either as directed by the base protocol document 3184 or for the sake of our example: 3186 o Message Type is 32. 3188 o Result is set to Nack (0x1) for this example. 3190 o Result Code is 0. 3192 o A transaction identifier is assigned by the NAS. 3194 o Port is set to 0. 3196 o Event Sequence Number, the R flag and the other bits marked x, 3197 Duration, the Event Flags, and the Flow Control Flags are all 3198 irrelevant for this function and are set to 0. 3200 o Function is set to "Configure Connection Service Data" (8). 3202 o X-Function is set to 0. 3204 o Tech Type is "DSL" (5). 3206 o Block lengths are calculated assuming a Circuit-Id length of 4 in 3207 our example. Recall that the example Multicast-Service-Profile- 3208 Name TLV length is 20. 3210 1 2 3 3211 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 3212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3213 | Type (0x880C) | Length = 84 | 3214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3215 | Version | Msg Type = 32 | Res=1 | Result Code = 0 | 3216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3217 | Partition ID | Transaction Identifier | 3218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3219 |I| SubMessage Number | Length = 84 | 3220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3221 | Port = 0 | 3222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3223 | Port Session Number | 3224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3225 | Event Sequence Number = 0 | 3226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3227 |R|x|x|x|x|x|x|x| Duration = 0 | Function = 0x8| X-Function = 0| 3228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3229 | Event Flags | Flow Control Flags | 3230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3231 |x|x|x|x|x|x|x|x| Msg Type = 32 | Tech Type=5 | Blk Len = 56 | 3232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3233 | # of TLVs = 3 | Extension Block length = 44 | 3234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3235 | TLV Type = Target 0x1000 | Target TLV Length = 8 | 3236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3237 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3239 | Access Loop Circuit ID | 3240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3241 | Mcast-Svc-Profile-Name 0x0018 | TLV Length = 20 | 3242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3243 | Multicast service profile name | 3244 ~ = "Cust 0127-53681-0003" ~ 3245 | | 3246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3247 | Bandwidth-Allocation 0x0015 | TLV Length = 4 | 3248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3249 | Bandwidth value = 2000 (kbits/s) | 3250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3252 Figure 21: Example Port Management Message 3254 A.2. Handling a Grey-Listed Flow 3256 Suppose now that the subscriber chooses to watch the premium channel 3257 characterized by source 192.0.2.21, group 233.252.0.67. Upon 3258 receiving the Join request, the AN matches it against the multicast 3259 service profile for the port and determines that it is a grey-listed 3260 flow. Figure 22 illustrates the resulting ANCP message flow for the 3261 case of a simple join and leave, when resource-based admission 3262 control for grey-listed flows is not activated on the AN. 3264 To start the flow, the AN sends a Multicast Admission Control request 3265 (M1) to the NAS. The NAS decides whether flow can be admitted, 3266 applying both policy and bandwidth criteria. It returns its decision 3267 (positive in this example) in a Multicast Replication Control message 3268 (M2). Later, when the subscriber leaves the flow, the AN informs the 3269 NAS by sending another Multicast Admission Control message. 3271 +----------+ +-------+ +-----+ ANCP +-----+ 3272 |Subscriber| | Home | | AN |<---------->| NAS | 3273 +----------+ |Gateway| +-----+ +-----+ 3274 | +-------+ | | 3275 | | | Multicast | 3276 | Join(Grey-Fl) | Admission | 3277 |-----------+---------->| Control (M1) | 3278 | | |------------------>| 3279 | | | | (NAS performs 3280 | | | Multicast | admission 3281 | | | Replication (*) control) 3282 | | | Control (M2) | 3283 | Mcast Grey Flow |<------------------| 3284 |<======================+ | 3285 | | | | 3286 ~ ~ ~ ~ 3287 | | | Multicast | 3288 | Leave(Grey-Fl) | Admission | 3289 |-----------+---------->| Control (M3) | 3290 | | |------------------>| 3291 | | | | 3293 Grey-Fl : Multicast Flow matching an entry in grey List 3295 (*) The NAS may optionally seek direction from an external 3296 Authorization/Policy Server 3298 Figure 22: Successful Join/Leave Operations, Grey-Listed Flow 3300 The Multicast Admission Control message M1 contains: 3302 o an ANCP Header with: 3304 * Message Type is 145; 3305 * Result = Ignore (0x0); 3307 * a transaction identifier assigned by the AN. 3309 o a Target TLV identifying the AN Port 3311 o a Command TLV containing: 3313 * Command Code = "Add" (1); 3315 * Accounting = "No" (0); 3317 * a Multicast-Flow embedded TLV indicating the multicast flow for 3318 which the AN received the IGMP Join: flow type "SSM" (2), 3319 address family "IPv4" (1), Group address = 233.252.0.67, Source 3320 Address = 192.0.2.21; 3322 * a Subs-Session-Identifier embedded TLV containing the value 3323 0x0C000264. 3325 The Multicast Admission Control message M1 is illustrated in 3326 Figure 23: 3328 1 2 3 3329 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 3330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3331 | Type (0x880C) | Length = 98 | 3332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3333 | Version | Msg Type=145 | Res=0 | Result Code = 0 | 3334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3335 | Partition ID | Transaction Identifier | 3336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3337 |I| SubMessage Number | Length = 98 | 3338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3339 | TLV Type = Target 0x1000 | Target TLV Length = 8 | 3340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3341 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3343 | Access Loop Circuit ID | 3344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3345 | TLV Type = Command 0x0011 | TLV Length = 28 | 3346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3347 | Cmd Code = 1 | Acctg = 0 | Reserved = 0x0000 | 3348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3349 | Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 | 3350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3351 | Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 | 3352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3353 | Multicast Group Address = 233.252.0.67 | 3354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3355 | Unicast Source Address = 192.0.2.21 | 3356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 3357 |Subs-Session-Identifier 0x0092 | Embedded TLV length = 4 | 3358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3359 | Value = 0x0C000264 | 3360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3362 Figure 23: Multicast Admission Control Message Seeking To Add A Flow 3364 The Multicast Replication Control message M2 contains: 3366 o an ANCP Header with: 3368 * Message Type = "Multicast Replication Control" (144); 3370 * Result= 0x1 (NAck); 3372 * a transaction identifier assigned by the NAS; 3374 o a Target TLV identifying the AN Port; 3375 o a Command TLV containing: 3377 * Command Code = "Add" (1); 3379 * Accounting = "Yes" (1), since in our example the operator wants 3380 accounting on this flow. 3382 * a Multicast-Flow embedded TLV indicating the multicast flow 3383 that the NAS is admitting for this access line: flow type "SSM" 3384 (2), address family "IPv4" (1), Group address = 233.252.0.67, 3385 Source Address = 192.0.2.21. 3387 The Multicast Admission Control message M2 is illustrated in 3388 Figure 24. 3390 1 2 3 3391 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 3392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3393 | Type (0x880C) | Length = 48 | 3394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3395 | Version | Msg Type=144 | Res=1 | Result Code = 0 | 3396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3397 | Partition ID | Transaction Identifier | 3398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3399 |I| SubMessage Number | Length = 48 | 3400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3401 | Target Type = 0x1000 | Target TLV Length = 8 | 3402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3403 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3405 | Access Loop Circuit ID | 3406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3407 | TLV Type = Command 0x0011 | TLV Length = 20 | 3408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3409 | Cmd Code = 1 | Acctg = 1 | Reserved = 0x0000 | 3410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3411 | Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 | 3412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3413 | Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 | 3414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3415 | Multicast Group Address = 233.252.0.67 | 3416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3417 | Unicast Source Address = 192.0.2.21 | 3418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3420 Figure 24: Multicast Replication Control Message Admitting A Flow 3422 The Multicast Admission Control message M3 advising the NAS that the 3423 flow has been terminated contains: 3425 o an ANCP Header with: 3427 * Message Type is 145; 3429 * Result = Ignore (0x0) 3431 * a transaction identifier assigned by the AN; 3433 o a Target TLV identifying the access line; 3435 o a Command TLV containing: 3437 * a Command Code = "Delete" (2); 3439 * Accounting = "No" (0); 3441 * a Multicast-Flow embedded TLV indicating the multicast flow for 3442 which the AN received the IGMP leave: flow type "SSM" (2), 3443 address family "IPv4" (1), Group address = 233.252.0.67, Source 3444 Address = 192.0.2.21. 3446 * a Subs-Session-Identifier embedded TLV containing the value 3447 0x0C000264. 3449 The Multicast Admission Control message M3 is illustrated in 3450 Figure 25. 3452 1 2 3 3453 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 3454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3455 | Type (0x880C) | Length | 3456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3457 | Version | Msg Type=145 | Res=0 | Result Code = 0 | 3458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3459 | Partition ID | Transaction Identifier | 3460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3461 |I| SubMessage Number | Length | 3462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3463 | TLV Type = Target 0x1000 | Target TLV Length = 8 | 3464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3465 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3467 | Access Loop Circuit ID | 3468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3469 | TLV Type = Command 0x0011 | TLV Length = 28 | 3470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3471 | Cmd Code = 2 | Acctg = 0 | Reserved = 0x0000 | 3472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3473 | Multicast-Flow Type = 0x0019 | Embedded TLV Length = 12 | 3474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3475 | Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 | 3476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3477 | Multicast Group Address = 233.252.0.67 | 3478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3479 | Unicast Source Address = 192.0.2.21 | 3480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3481 |Subs-Session-Identifier 0x0092 | Embedded TLV length = 4 | 3482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3483 | Value = 0x0C000264 | 3484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3486 Figure 25: Multicast Admission Control Message Signalling Flow 3487 Termination 3489 A.3. Handling White-Listed Flows 3491 The NAS has enabled white list admission control on the AN, and the 3492 bandwidth delegation capability has been negotiated. White listed 3493 flows in themselves require no messages to the NAS, either upon 3494 admission or upon termination, but the AN may request an increase in 3495 the amount of delegated bandwidth if it needs the increase to admit a 3496 flow. 3498 Consider an example where the AN has already admitted one white- 3499 listed flow, thereby using up the initially provisioned amount of 3500 delegated bandwidth (2000 kbits/s). A request is received to join a 3501 new flow in the white list range. The AN chooses to send a Bandwidth 3502 Reallocation Request message to the NAS, requesting that the 3503 delegated bandwidth allocation be increased to 4000 kbits/s at a 3504 minimum, and preferably to 6000 kbits/s. 3506 In our example, the NAS is managing bandwidth tightly, as witnessed 3507 by its minimal initial allocation of just enough for one flow. It is 3508 willing to provide the minimum additional amount only, and therefore 3509 returns a Bandwidth Transfer message where the delegated bandwidth 3510 value is given as 4000 kbits/s. With this amount, the AN is able to 3511 admit the second white-listed flow. The AN could send a similar 3512 Bandwidth Transfer message back to the NAS bringing the delegated 3513 bandwidth amount back down to 2000 kbits/s when one of the flows is 3514 terminated, but this shows nothing new and is omitted. 3516 As one more point of illustration, suppose that the NAS chooses to 3517 audit the current amount of delegated bandwidth to ensure it is 3518 synchronized with the AN. It sends a Delegated Bandwidth Query 3519 request message to the AN, and receives a Delegated Bandwidth Query 3520 response message with the current allocation as the AN sees it. 3522 The complete message flow is shown in Figure 26. 3524 +----------+ +-------+ +-----+ ANCP +-----+ 3525 |Subscriber| | Home | | AN |<---------->| NAS | 3526 +----------+ |Gateway| +-----+ +-----+ 3527 | +-------+ | | 3528 | | | | 3529 | Join(White-F1) | | 3530 |-----------+---------->| | 3531 | | |AN performs | 3532 | Mcast White Flow 1 | admission control | 3533 |<======================+ | 3534 | | | | 3535 | Join(White-F2) | | 3536 |-----------+---------->|No bandwidth left | 3537 | | | | 3538 | | |Bandwidth | 3539 | | | Reallocation Req | 3540 | | |------------------>|(M1) 3541 | | | | 3542 | | | (*) 3543 | | |Bandwidth Transfer | 3544 | AN can now |<------------------|(M2) 3545 | admit flow | | 3546 | Mcast White Flow 2 | | 3547 |<======================+ | 3548 | | | | 3549 ~ ~ ~ ~ 3550 | | |Delegated Bandwidth| 3551 | | | Query request | 3552 | | |<------------------|(M3) 3553 | | | | 3554 | | |Delegated Bandwidth| 3555 | | | Query response | 3556 | | |------------------>|(M4) 3557 | | | | 3559 (*) The NAS may optionally seek direction from an external 3560 Authorization/Policy Server 3562 Figure 26: Successful Join/Leave Operations, White-Listed Flow 3564 The Bandwidth Reallocation Request message (M1) is shown in 3565 Figure 27. The contents require little explanation. The Message 3566 Type for the Bandwidth Reallocation Request is 146. The Result field 3567 is set to Ignore (0x0). Besides the Target, the message has one 3568 other TLV, the Bandwidth-Request, with a TLV Type of 0x0016. The TLV 3569 contains Required Amount and Preferred Amount fields, set to 4000 and 3570 6000 kbits/s respectively. 3572 1 2 3 3573 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 3574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3575 | Type (0x880C) | Length = 36 | 3576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3577 | Version | Msg Type=146 | Res=0 | Result Code = 0 | 3578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3579 | Partition ID | Transaction Identifier | 3580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3581 |I| SubMessage Number | Length = 36 | 3582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3583 | TLV Type = Target 0x1000 | Target TLV Length = 8 | 3584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3585 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3587 | Access Loop Circuit ID | 3588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3589 | Bandwidth-Request 0x0016 | TLV Length = 8 | 3590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3591 | Required Amount = 4000 (kbits/s) | 3592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3593 | Preferred Amount = 6000 (kbits/s) | 3594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3596 Figure 27: Bandwidth Reallocation Request Message 3598 The Bandwidth Transfer message (M2) is shown in Figure 28. Again, 3599 the contents are easily understood. The Message Type for the 3600 Bandwidth Transfer message is 147. The Result field is set to 3601 Success (0x3). The message contains the Target TLV and the 3602 Bandwidth-Allocation TLV. The latter has a TLV Type of 0x0015 and 3603 contains a Delegated Amount field, set to 4000 kbits/s. 3605 1 2 3 3606 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 3607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3608 | Type (0x880C) | Length = 32 | 3609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3610 | Version | Msg Type=147 | Res=3 | Result Code = 0 | 3611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3612 | Partition ID | Transaction Identifier | 3613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3614 |I| SubMessage Number | Length = 32 | 3615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3616 | TLV Type = Target 0x1000 | Target TLV Length = 8 | 3617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3618 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3620 | Access Loop Circuit ID | 3621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3622 | Bandwidth-Allocation 0x0015 | TLV Length = 4 | 3623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3624 | Delegated Amount = 4000 (kbits/s) | 3625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3627 Figure 28: NAS Response, Bandwidth Transfer Message 3629 The Delegated Bandwidth Query request message (M3) is shown in 3630 Figure 29. The Message Type for the Delegated Bandwidth Query 3631 request message is 148. The Result field is set to AckAll (0x2). 3632 The message contains the Target TLV only. 3634 1 2 3 3635 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 3636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3637 | Type (0x880C) | Length = 24 | 3638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3639 | Version | Msg Type=148 | Res=2 | Result Code = 0 | 3640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3641 | Partition ID | Transaction Identifier | 3642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3643 |I| SubMessage Number | Length = 24 | 3644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3645 | TLV Type = Target 0x1000 | Target TLV Length = 8 | 3646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3647 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3649 | Access Loop Circuit ID | 3650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3652 Figure 29: Delegated Bandwidth Query Request Message 3654 Finally, the Delegated Bandwidth Query response message (M4) is shown 3655 in Figure 30. The Message Type for the Delegated Bandwidth Query 3656 response message is 148. The Result field is set to Success (0x3). 3657 The message contains the Target TLV and the Bandwidth-Allocation TLV 3658 with the Delegated Amount field set to 4000 kbits/s. 3660 1 2 3 3661 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 3662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3663 | Type (0x880C) | Length = 32 | 3664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3665 | Version | Msg Type=148 | Res=2 | Result Code = 0 | 3666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3667 | Partition ID | Transaction Identifier (copied from request) | 3668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3669 |I| SubMessage Number | Length = 32 | 3670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3671 | TLV Type = Target 0x1000 | Target TLV Length = 8 | 3672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3673 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3675 | Access Loop Circuit ID | 3676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3677 | Bandwidth-Allocation 0x0015 | TLV Length = 4 | 3678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3679 | Delegated Amount = 4000 (kbits/s) | 3680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3682 Figure 30: Delegated Bandwidth Query Response Message 3684 A.4. Handling Of Black-Listed Join Requests 3686 This section introduces no new messages, since requests for flows in 3687 the black list are simply ignored. The one thing to point out is the 3688 overlap in our example between the set of flows in the grey list and 3689 the flows in the black list. This does not create any ambiguity, 3690 since not only does the black list have priority for equally good 3691 matches, but also the black list entries are more specific (group 3692 prefix lengths of 32 versus 29 in the grey list) than the grey list 3693 flow prefixes. 3695 A.5. Handling Of Requests To Join and Leave the On-Line Game 3697 The final class of multicast control actions in our example allows 3698 the subscriber to enter and leave the on-line game. As described at 3699 the beginning of this example, the game uses Any Source Multicast 3700 (ASM). Subscriber signalling bypasses the AN, going directly to the 3701 NAS (e.g., through a web interface). 3703 When the subscriber requests to join the game, the NAS (after 3704 applying policy and bandwidth checks) sends a Multicast Replication 3705 Control message to the AN to enable the flow on the port concerned. 3706 The AN knows not to apply admission control, since it has not 3707 received an MRepCtl-CAC TLV in the Provisioning message. When the 3708 subscriber leaves, the NAS sends another Multicast Replication 3709 Control message to delete the flow. This message sequence is shown 3710 in Figure 31. 3712 It is possible that the NAS finds that there is not enough bandwidth 3713 available to accommodate the subscriber's request. In this case, the 3714 NAS could send a Bandwidth Reallocation Request message to the AN, 3715 asking it to release some of the bandwidth delegated to it. This is 3716 not shown in the present example, since the messages are the same as 3717 those already presented with the exception that the Preferred Amount 3718 in the request will be *less than* or equal to the Required amount, 3719 rather than *greater than* or equal to it. 3721 +----------+ +-------+ +-----+ ANCP +-----+ 3722 |Subscriber| | Home | | AN |<---------->| NAS | 3723 +----------+ |Gateway| +-----+ +-----+ 3724 | +-------+ | | 3725 | | | | 3726 | Join game | | 3727 |-----------+------------------------------>| 3728 | | | Multicast | NAS performs 3729 | | | Replication (*) admission 3730 | | | Control (M1) | control 3731 | Mcast Game Flow |<------------------| 3732 |<=====================>+ | 3733 | | | | 3734 ~ ~ ~ ~ 3735 | | | | 3736 | Leave game | | 3737 |-----------+------------------------------>| 3738 | | | Multicast | 3739 | | | Replication | 3740 | | | Control (M2) | 3741 | Mcast Game Flow |<------------------| 3742 | discontinued | | 3743 | | | | 3745 (*) The NAS may optionally seek direction from an external 3746 Authorization/Policy Server 3748 Figure 31: NAS-Initiated Flows For On-Line Gaming 3750 Multicast Replication Control message (M1) in Figure 32 looks like 3751 the message in Figure 24 with two exceptions. The first is that the 3752 NAS has the option to set the Result field to AckAll (0x02) if it 3753 needs positive reassurance that the flow has been enabled. This was 3754 not done here to save having to depict a response differing only in 3755 the Result field. The larger difference in this example is that the 3756 flow description in the Multicast-Flow embedded TLV is that of an ASM 3757 multicast group (Flow Type = 1) with IPv4 (1) group address 3758 233.252.0.100. 3760 1 2 3 3761 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 3762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3763 | Type (0x880C) | Length = 44 | 3764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3765 | Version | Msg Type=144 | Res=1 | Result Code = 0 | 3766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3767 | Partition ID | Transaction Identifier | 3768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3769 |I| SubMessage Number | Length = 44 | 3770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3771 | TLV Type = Target 0x1000 | Target TLV Length = 8 | 3772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3773 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3775 | Access Loop Circuit ID | 3776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3777 | TLV Type = Command 0x0011 | TLV Length = 16 | 3778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3779 | Cmd Code = 1 | Acctg = 1 | Reserved = 0x0000 | 3780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3781 | Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 | 3782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3783 | Flow Type = 1 | Addr Fam = 1 | Reserved = 0x0000 | 3784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3785 | Multicast Group Address = 233.252.0.100 | 3786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 3788 Figure 32: Enabling The Subscriber To Join An On-Line Game 3790 Message M2 terminating the flow when the subscriber leaves the game 3791 looks the same as the message in Figure 32 with two exceptions: the 3792 Command Code becomes "Delete" (2), and Accounting is set to "No" (0) 3793 to turn off flow accounting. Of course, the Transaction Identifier 3794 values will differ between the two messages. 3796 A.6. Example Flow For Multicast Flow Reporting 3797 The example in this section is independent of the example in the 3798 preceding sections. 3800 Figure 33 illustrates a message flow in a case where the NAS queries 3801 the AN about which multicast flows are active on port 10, on port 11 3802 and on port 20 of the AN. 3804 +----------+ +-------+ +-----+ ANCP +-----+ 3805 |Subscriber| | Home | | AN |<---------->| NAS | 3806 +----------+ |Gateway| +-----+ +-----+ 3807 | +-------+ | | 3808 | | | Multicast Flow | 3809 | | | Query Request | 3810 | | | (M1) | 3811 | | |<------------------| 3812 | | | | 3813 | | | Multicast Flow | 3814 | | | Query Response | 3815 | | | (M2) | 3816 | | |------------------>| 3817 | | | | 3818 | | | | 3820 Figure 33: Per-Port Multicast Flow Reporting 3822 The Multicast Flow Query Request message (M1) is illustrated in 3823 Figure 34. The Message Type is 149. The Result field is set to 3824 AckAll (0x2). Three Target TLVs are present, identifying port 10, 3825 port 20, and port 11 respectively. 3827 0 1 2 3 3828 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 3829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3830 | Type (0x880C) | Length | 3831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3832 | Version | Msg Type = 149| Res=1 | Result Code = 0 | 3833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3834 | Partition ID | Transaction Identifier | 3835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3836 |I| SubMessage Number | Length | 3837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3838 | TLV Type = Target 0x1000 | Target TLV Length | 3839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3840 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 3841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3842 | | 3843 ~ Access Loop Circuit ID (port10) ~ 3844 | | 3845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3846 | TLV Type = Target 0x1000 | Target TLV Length | 3847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3848 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 3849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3850 | | 3851 ~ Access Loop Circuit ID (port20) ~ 3852 | | 3853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3854 | TLV Type = Target 0x1000 | Target TLV Length | 3855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3856 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 3857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3858 | | 3859 ~ Access Loop Circuit ID (port11) ~ 3860 | | 3861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3863 Figure 34: Multicast Flow Query Request Message For Per-Port 3864 Multicast Flow Reporting 3866 The Multicast Flow Query Response message (M2) is illustrated in 3867 Figure 35. It indicates that there is one active multicast flow 3868 [(192.0.2.1, 233.252.0.4)] on port 10, no active multicast flow on 3869 port 20 and two active multicast flows [(192.0.2.1, 233.252.0.4) and 3870 (192.0.2.2, 233.252.0.10)] on port 11. 3872 0 1 2 3 3873 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 3874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3875 | Type (0x880C) | Length | 3876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3877 | Version | Msg Type = 149|Rslt=3 | Result Code = 0 | 3878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3879 | Partition ID | Transaction Identifier | 3880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3881 |I| SubMessage Number | Length | 3882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3883 | TLV Type = Target 0x1000 | Target TLV Length | 3884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3885 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 3886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3887 | | 3888 ~ Access Loop Circuit ID (port10) ~ 3889 | | 3890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3891 | Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 | 3892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3893 | Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 | 3894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3895 | Multicast Group Address = 233.252.0.4 | 3896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3897 | Unicast Source Address = 192.0.2.1 | 3898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 3899 | TLV Type = Target 0x1000 | Target TLV Length | 3900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3901 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 3902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3903 | | 3904 ~ Access Loop Circuit ID (port20) ~ 3905 | | 3906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3907 | TLV Type = Target 0x1000 | Target TLV Length | 3908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3909 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 3910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3911 | | 3912 ~ Access Loop Circuit ID (port11) ~ 3913 | | 3914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3915 | Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 | 3916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3917 | Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 | 3918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3919 | Multicast Group Address = 233.252.0.4 | 3920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3921 | Unicast Source Address = 192.0.2.1 | 3922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 3923 | Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 | 3924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3925 | Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 | 3926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3927 | Multicast Group Address: 233.252.0.10 | 3928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3929 | Unicast Source Address = 192.0.2.2 | 3930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 3932 Figure 35: Multicast Flow Query Response message For Per-Port 3933 Multicast Flow Reporting 3935 Authors' Addresses 3937 Francois Le Faucheur 3938 Cisco Systems 3939 Greenside, 400 Avenue de Roumanille 3940 Sophia Antipolis 06410 3941 France 3943 Phone: +33 4 97 23 26 19 3944 Email: flefauch@cisco.com 3946 Roberta Maglione 3947 Cisco Systems 3948 181 Bay Street 3949 Toronto, ON M5J 2T3 3950 Canada 3952 Email: robmgl@cisco.com 3954 Tom Taylor 3955 Huawei Technologies 3956 Ottawa 3957 Canada 3959 Email: tom.taylor.stds@gmail.com