idnits 2.17.1 draft-ietf-ancp-mc-extensions-09.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 8 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 24, 2013) is 4079 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) == Unused Reference: 'RFC4601' is defined on line 3018, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE48' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE64' -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 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 Intended status: Standards Track R. Maglione 5 Expires: August 28, 2013 Cisco Systems 6 T. Taylor 7 Huawei 8 February 24, 2013 10 Multicast Control Extensions for ANCP 11 draft-ietf-ancp-mc-extensions-09.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 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 28, 2013. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 3. Multicast Use Cases . . . . . . . . . . . . . . . . . . . . . 9 82 3.1. NAS Initiated Multicast Replication Control Use Case . . . 9 83 3.1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 9 84 3.1.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 10 85 3.2. Conditional Access and Admission Control Use Case . . . . 10 86 3.2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 10 87 3.2.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 11 88 3.3. Multicast Flow Reporting Use Case . . . . . . . . . . . . 12 89 3.3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 12 90 3.3.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 12 91 3.4. Committed Bandwidth Reporting Use Case . . . . . . . . . . 13 92 3.4.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 13 93 3.4.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 13 94 4. ANCP Messages . . . . . . . . . . . . . . . . . . . . . . . . 15 95 4.1. Provisioning Message . . . . . . . . . . . . . . . . . . . 15 96 4.1.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 15 97 4.1.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 16 98 4.2. Port Management Message . . . . . . . . . . . . . . . . . 17 99 4.2.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 18 100 4.2.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 18 101 4.3. Multicast Replication Control Message . . . . . . . . . . 19 102 4.3.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 22 103 4.3.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 23 104 4.4. Multicast Admission Control Message . . . . . . . . . . . 25 105 4.4.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 26 106 4.4.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 27 107 4.5. Bandwidth Reallocation Request Message . . . . . . . . . . 28 108 4.5.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 29 109 4.5.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 29 110 4.6. Bandwidth Transfer Message . . . . . . . . . . . . . . . . 32 111 4.6.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 33 112 4.6.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 33 113 4.7. Delegated Bandwidth Query Request Message . . . . . . . . 34 114 4.7.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 35 115 4.7.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 35 116 4.8. Delegated Bandwidth Query Response Message . . . . . . . . 35 117 4.8.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 36 118 4.8.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 36 119 4.9. Multicast Flow Query Request and Response Messages . . . . 37 120 4.9.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 37 121 4.9.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 38 122 4.10. Committed Bandwidth Report Message . . . . . . . . . . . . 39 123 4.10.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 39 124 4.10.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 40 126 5. ANCP TLVs For Multicast . . . . . . . . . . . . . . . . . . . 41 127 5.1. Multicast-Service-Profile TLV . . . . . . . . . . . . . . 41 128 5.2. Multicast-Service-Profile-Name TLV . . . . . . . . . . . . 42 129 5.3. List-Action TLV . . . . . . . . . . . . . . . . . . . . . 42 130 5.4. Sequence-Number TLV . . . . . . . . . . . . . . . . . . . 45 131 5.5. Bandwidth-Allocation TLV . . . . . . . . . . . . . . . . . 45 132 5.6. White-List-CAC TLV . . . . . . . . . . . . . . . . . . . . 46 133 5.7. MRepCtl-CAC TLV . . . . . . . . . . . . . . . . . . . . . 47 134 5.8. Bandwidth-Request TLV . . . . . . . . . . . . . . . . . . 47 135 5.9. Request-Source-IP TLV . . . . . . . . . . . . . . . . . . 48 136 5.10. Request-Source-MAC TLV . . . . . . . . . . . . . . . . . . 48 137 5.11. Multicast-Flow TLV . . . . . . . . . . . . . . . . . . . . 49 138 5.12. Report-Buffering-Time TLV . . . . . . . . . . . . . . . . 50 139 5.13. Committed-Bandwidth TLV . . . . . . . . . . . . . . . . . 51 140 6. Multicast Capabilities . . . . . . . . . . . . . . . . . . . . 52 141 6.1. Required Protocol Support . . . . . . . . . . . . . . . . 52 142 6.1.1. Protocol Requirements For NAS-Initiated Replication . 53 143 6.1.2. Protocol Requirements For Committed Multicast 144 Bandwidth Reporting . . . . . . . . . . . . . . . . . 53 145 6.1.3. Protocol Requirements For Conditional Access With 146 White and Black Lists . . . . . . . . . . . . . . . . 54 147 6.1.4. Protocol Requirements For Conditional Access With 148 Grey Lists . . . . . . . . . . . . . . . . . . . . . . 55 149 6.1.5. Protocol Requirements For Delegated Bandwidth . . . . 56 150 6.2. Capability-Specific Procedures for Providing Multicast 151 Service . . . . . . . . . . . . . . . . . . . . . . . . . 57 152 6.2.1. Procedures For NAS-Initiated Replication . . . . . . . 57 153 6.2.2. Procedures For Committed Bandwidth Reporting . . . . . 58 154 6.2.3. Procedures For Conditional Access With Black and 155 White Lists . . . . . . . . . . . . . . . . . . . . . 59 156 6.2.4. Procedures For Conditional Access With Grey Lists . . 61 157 6.2.5. Procedures For Delegated Bandwidth . . . . . . . . . . 62 158 6.3. Combinations of Multicast Capabilities . . . . . . . . . . 63 159 6.3.1. Combination of Conditional Access With White and 160 Black Lists and Conditional Access With Grey Lists . . 63 161 6.3.2. Combination of Conditional Access With Delegated 162 Bandwidth . . . . . . . . . . . . . . . . . . . . . . 64 163 6.3.3. Combination of NAS-Initiated Replication with 164 Other Capabilities . . . . . . . . . . . . . . . . . . 64 165 6.3.4. Combinations of Committed Bandwidth Reporting with 166 Other Multicast Capabilities . . . . . . . . . . . . . 65 167 7. Security Considerations . . . . . . . . . . . . . . . . . . . 66 168 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67 169 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 71 170 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72 171 10.1. Normative References . . . . . . . . . . . . . . . . . . . 72 172 10.2. Informative References . . . . . . . . . . . . . . . . . . 72 173 Appendix A. Example of Messages and Message Flows . . . . . . . . 74 174 A.1. Provisioning Phase . . . . . . . . . . . . . . . . . . . . 74 175 A.2. Handling a Grey-Listed Flow . . . . . . . . . . . . . . . 80 176 A.3. Handling White-Listed Flows . . . . . . . . . . . . . . . 85 177 A.4. Handling Of Black-Listed Join Requests . . . . . . . . . . 90 178 A.5. Handling Of Requests To Join and Leave the On-Line Game . 90 179 A.6. Example Flow For Multicast Flow Reporting . . . . . . . . 93 180 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 97 182 1. Introduction 184 [RFC5851] defines a framework and requirements for an Access Node 185 control mechanism between a Network Access Server (NAS) and an Access 186 Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)) in a 187 multi-service reference architecture in order to perform QoS-related, 188 service-related and subscriber-related operations. [RFC6320] 189 specifies a protocol for Access Node Control in broadband networks in 190 line with this framework. 192 [RFC6320] supports three use cases defined in [RFC5851], specifically 193 for DSL access: the DSL Topology Discovery use case, the DSL Line 194 Configuration use case and the DSL Remote Connectivity Test use case. 195 However, it does not support the multicast use cases defined in 196 [RFC5851]. The present document specifies the extensions to the 197 Access Node Control Protocol required for support of these multicast 198 use cases. In addition, it supports the Committed Bandwidth 199 Reporting use case, described below. In terms of the ANCP protocol, 200 these use cases are organized into five capabilities: 202 o NAS-initiated multicast replication; 204 o conditional access with white and black lists; 206 o conditional access with grey lists; 208 o bandwidth delegation; 210 o committed bandwidth reporting. 212 NAS-initiated multicast replication assumes that multicast "join" and 213 "leave" requests are terminated on the NAS, or that the NAS receives 214 requests to establish multicast sessions through other means (e.g., 215 application-level signalling). The NAS sends commands to the AN to 216 start or stop replication of specific multicast flows on specific 217 subscriber ports. This use case is described briefly in the next-to- 218 last paragraph of Section 3.4 of [RFC5851]. 220 Conditional access is described in Sections 3.4.1 and 3.4.2.3 of 221 [RFC5851], with the latter section particularly applicable to 222 operation with white and black lists only. In case of "conditional 223 access with white and black lists", multicast join and leave requests 224 are terminated at the AN and accepted or ignored in accordance with 225 the direction provided by white and black lists respectively. The 226 white and black lists are provisioned per port at startup time and 227 may be modified thereafter. The NAS may enable admission control of 228 white-listed flows by appropriate provisioning. 230 Conditional access with grey lists is similar to conditional access 231 with white lists, except that before accepting any request matching a 232 grey list entry, the AN sends a request to the NAS for permission to 233 replicate the flow. Again, the NAS can enable admission control of 234 grey-listed flows at the AN. 236 Bandwidth delegation is described in Section 3.4.2.1 of [RFC5851]. 237 It allows flexible sharing of total video bandwidth on an access line 238 between the AN and the NAS. One application of such bandwidth 239 sharing is where the AN does multicast admission control, while the 240 NAS or Policy Server does unicast admission control. In that case, 241 bandwidth delegation allows dynamic sharing of bandwidth between 242 unicast and multicast video traffic on each access line. 244 Committed bandwidth reporting is described below, in Section 3.4. 245 The AN reports the amount of multicast bandwidth it has granted to a 246 given access line each time that value changes. These reports may be 247 buffered for a NAS-provisionable interval so that reports for 248 multiple access lines can be bundled into the same message. 250 The formal specification of the behaviours associated with each of 251 these capabilities, singly and in combination, is given in Section 6. 253 In addition to the multicast service processing behaviour just 254 sketched, the definition of each capability includes support for the 255 multicast accounting and reporting services described in Section 256 3.4.3 of [RFC5851]. Because of this common content and because of 257 other protocol overlaps between the different capabilities, the 258 protocol descriptions for the multicast extensions specified in this 259 document are merged into a single non-redundant narrative. Tables in 260 Section 6 then indicate the specific sub-sections of the protocol 261 description that have to be implemented to support each capability. 263 2. Terminology 265 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 266 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 267 document are to be interpreted as described in [RFC2119]. 269 The expression "delegated bandwidth" is used as a shorter way of 270 saying: "the total amount of video bandwidth delegated to the AN for 271 multicast admission control". 273 3. Multicast Use Cases 275 Quoting from [RFC5851]: 277 "... the Access Node, aggregation node(s) and the NAS must all be 278 involved in the multicast replication process. This avoids that 279 several copies of the same stream are sent within the access/ 280 aggregation network. In case of an Ethernet-based access/aggregation 281 network, this may, for example, be achieved by means of IGMP snooping 282 or IGMP proxy in the Access Node and aggregation node(s). By 283 introducing IGMP processing in the access/aggregation nodes, the 284 multicast replication process is now divided between the NAS, the 285 aggregation node(s) and Access Nodes. In order to ensure backward 286 compatibility with the ATM-based model, the NAS, aggregation node and 287 Access Node need to behave as a single logical device. This logical 288 device must have exactly the same functionality as the NAS in the ATM 289 access/aggregation network. The Access Node Control Mechanism can be 290 used to make sure that this logical/functional equivalence is 291 achieved by exchanging the necessary information between the Access 292 Node and the NAS." 294 [RFC5851] describes the use cases for ANCP associated with such 295 multicast operations, and identifies the associated ANCP 296 requirements. The present section describes a subset of these use 297 cases as background to facilitate reading of this document, but the 298 reader is refered to [RFC5851] for a more exhaustive description of 299 the ANCP multicast use cases. Detailed example message flows can 300 also be found in Appendix A. 302 3.1. NAS Initiated Multicast Replication Control Use Case 304 3.1.1. Goals 306 One option for multicast handling is for the subscriber to 307 communicate the "join/leave" information to the NAS. This can be 308 done for instance by terminating all subscriber IGMP ([RFC3376]) or 309 MLD ([RFC2710], [RFC3810]) signaling on the NAS. Another example 310 could be a subscriber using some form of application level signaling, 311 which is redirected to the NAS. In any case, this option is 312 transparent to the access and aggregation network. In this scenario, 313 the NAS uses ANCP to create and remove replication state in the AN 314 for efficient multicast replication. Thus, the NAS only sends a 315 single copy of the multicast stream towards the AN, which in turn 316 performs replication to multiple subscribers as instructed by the NAS 317 via ANCP. The NAS first performs conditional access and multicast 318 admission control when processing multicast join requests, and only 319 creates replication state in the AN if admission succeeds. 321 3.1.2. Message Flow 323 With the NAS-initiated use case, a Multicast Replication Control 324 Message is sent by the NAS to the AN with a directive to either join 325 or leave one (or more) multicast flow(s). In the example message 326 flow, the AN uses a Generic Response message to convey the outcome of 327 the directive. Figure 1 illustrates such an ANCP message exchange as 328 well as the associated AN behavior. 330 +----------+ +-------+ +-----+ ANCP +-----+ 331 |Subscriber| | Home | | AN |<-------------------->| NAS | 332 +----------+ |Gateway| +-----+ +-----+ 333 | +-------+ | | 334 | | | (*) 335 | | | Multicast-Replication-Crl | 336 | | | (Target,add, Flow 1) | 337 | | |<--------------------------| 338 | Mcast Flow 1 | | 339 |<==========================+ | 340 | | | Generic Response | 341 | | |-------------------------->| 342 | | | | 343 | | | | 344 ~ ~ ~ ~ 345 | | | | 346 | | | Multicast-Replication-Crl | 347 | | | (Target,delete, Flow 1) | 348 | | |<--------------------------| 349 | | | | 350 | | Generic Response | 352 | | |-------------------------->| 354 (*) The NAS may optionally seek direction from an external 355 Authorization/Policy Server before admitting the flow. 357 Figure 1: NAS Initiated Multicast Replication Control 359 3.2. Conditional Access and Admission Control Use Case 361 3.2.1. Goals 363 One option for multicast handling is for the access/aggregation nodes 364 to participate in IGMP/MLD processing (e.g. via IGMP/MLD snooping). 365 In this scenario, on detecting a join/leave request from an end user 366 for a multicast flow (in the grey list), the AN uses ANCP to request 367 a conditional access and admission control decision from the NAS. In 368 turn, after conditional access and admission control checks, the NAS 369 uses ANCP to instruct the AN to change the replication states 370 accordingly. 372 3.2.2. Message Flow 374 For support of the conditional access and admission control use case, 375 on detection of an IGMP/MLD Join, the AN sends an Admission Control 376 message to the NAS to request a conditional access and admission 377 control check. In the case of a positive outcome, the NAS sends a 378 Multicast Replication Control Message to the AN with a directive to 379 replicate the multicast flow to the corresponding user. Similarly on 380 detection of an IGMP/MLD leave, an Admission Control message is sent 381 by the AN to the NAS to keep the NAS aware of user departure for the 382 flow. This message flow is illustrated in Figure 2. 384 +----------+ +-------+ +-----+ ANCP +-----+ 385 |Subscriber| | Home | | AN |<------------------->| NAS | 386 +----------+ |Gateway| +-----+ +-----+ 387 | +-------+ | | 388 | | | | 389 | Join(Gr-Flow1) | Admission-Control | 390 |------------+---------->| (Target,add,Gr-Flow1) | 391 | | |-------------------------->| 392 | | | (*) 393 | | | Multicast-Replication-Crl | 394 | | | (Target,add,Gr-Flow1) | 395 | | |<--------------------------| 396 | Mcast Gr-Flow1 | | 397 |<=======================+ | 398 | | | | 399 ~ ~ ~ ~ 400 | | | | 401 | Leave(Gr-Flow1) | Admission-Control | 402 |------------+---------->| (Target,delete,Gr-Flow1) | 403 | | |-------------------------->| 404 | | | 406 | | | | 408 Gr-Flow1: a multicast flow matching the grey list for that port 410 (*) The NAS may optionally seek direction from an external 411 Authorization/Policy Server before admitting the flow. 413 Figure 2: Multicast Conditional Access and Admission Control 415 3.3. Multicast Flow Reporting Use Case 417 3.3.1. Goals 419 The Multicast flow reporting use case allows the NAS to 420 asynchronously query the AN to obtain an instantaneous status report 421 related to multicast flows currently replicated by the AN. 423 3.3.2. Message Flow 425 The NAS sends a Multicast Flow Query Request message to the AN in 426 order to query the AN about information such as which multicast flows 427 are currently active on a given AN port or which ports are currently 428 replicating a given multicast flow. The AN conveys the requested 429 information to the NAS in a Multicast Flow Query Response message. 430 This message flow is illustrated in Figure 3. 432 +----------+ +-------+ +-----+ ANCP +-----+ 433 |Subscriber| | Home | | AN |<---------->| NAS | 434 +----------+ |Gateway| +-----+ +-----+ 435 | +-------+ | | 436 | | | Multicast Flow | 437 | | | Query Request | 438 | | |<------------------| 439 | | | | 440 | | | Multicast Flow | 441 | | | Query Response | 442 | | |------------------>| 443 | | | | 444 | | | | 446 Figure 3: Multicast Flow Reporting 448 3.4. Committed Bandwidth Reporting Use Case 450 3.4.1. Goals 452 The committed bandwidth reporting use case allows the NAS to maintain 453 current awareness of how much multicast bandwidth the AN has 454 committed to a given access line, so that the NAS can adjust its 455 forwarding scheduler to ensure the associated QoS. Note that this 456 involves a finer level of detail than provided by bandwidth 457 delegation, since the amount of delegated bandwidth is an upper limit 458 on the amount of bandwidth committed rather than an actual value. To 459 reduce the volume of messaging, reports from the AN may be buffered 460 so that one message reports on changes for multiple access lines. 462 3.4.2. Message Flow 464 The message flow associated with this use case is shown in Figure 4. 465 The figure assumes that a non-zero buffering interval was previously 466 provisioned on the AN. 468 +-----+ +-------+ +-----+ ANCP +-----+ 469 |Subs |+ | Home |+ | AN |<---------->| NAS | 470 |1,2 || |GW 1,2 || +-----+ +-----+ 471 +-----+| +-------+| | | 472 +|----+ +|------+ | | 473 | | | | | | 474 | |Join(Subs1, Ch1) | | 475 |----------+--------------->| Start buffering | 476 | | | Multicast flow | timer. Create | 477 |<==========================| message with | 478 | | | | | initial contents | 479 | | | | | reporting new | 480 | | | | | Subs1 bandwidth. | 481 | | Join(Subs2, Ch2) | | 482 | |----------+------------->| Add report for | 483 | | | Multicast flow | new Subs2 b/w. | 484 | |<========================| | 485 | | | | | | 486 | |Leave(Subs1, Ch1) | | 487 |----------+--------------->| Replace report | 488 | | | | | for Subs1 with | 489 | | Stop replication X new value (which | 490 | | | | | happens to be | 491 | | | | | the same as the | 492 | | | | | starting value. | 493 | | | | | | 494 | | | | >|< TIMER expires | 495 | | | | | | 496 | | | | |Committed | 497 | | | | | Bandwidth Report | 498 | | | | |------------------>| 499 | | | | | (for latest | 500 | | | | | Subs1 and Subs2 | 501 | | | | | bandwidth) | 502 | | | | | | 504 Figure 4: Message Flow For Committed Bandwidth Reporting 506 4. ANCP Messages 508 This section defines new ANCP messages and new usage of existing ANCP 509 messages as well as procedures associated with the use of these 510 messages. 512 4.1. Provisioning Message 514 Section 4.1 of [RFC6320] defines the Provisioning message that is 515 sent by the NAS to the AN to provision information in the AN. 517 The present document specifies that the Provisioning message MAY be 518 used by the NAS to provision multicast-related information (e.g., 519 multicast service profiles). The ANCP Provisioning message payload 520 MAY contain: 522 o one or more instances of the Multicast-Service-Profile TLV. The 523 Multicast-Service-Profile TLV is defined in the present document 524 in Section 5.1. Each instance of the Multicast-Service-Profile 525 TLV contains a multicast service profile name and one or more list 526 actions. A list action consists of an action (add, delete, 527 replace), a list type (white, black, or grey), and list content 528 (multicast source and group addresses). 530 o an instance of the White-List-CAC TLV. The White-List-CAC TLV is 531 defined in Section 5.6. If present, this TLV indicates that the 532 AN is required to do admission control before replicating white- 533 listed flows. 535 o an instance of the MRepCtl-CAC TLV. The MRepCtl-CAC TLV is 536 defined in Section 5.7. If present, this TLV indicates that the 537 AN is required to do admission control before replicating flows 538 specified in Multicast Replication Control messages. 540 o an instance of the Report-Buffering-Time TLV. The Report- 541 Buffering-Time TLV is defined in Section 5.12. If present, this 542 TLV indicates Committed Bandwidth Report messages should be 543 buffered for the amount of time given by the TLV before being 544 transmitted to the NAS. 546 See Section 6 for information on which multicast capabilities require 547 support of these TLVs in the Provisioning message. 549 4.1.1. Sender Behaviour 551 When directed by the Policy Server or by management action, the NAS 552 sends the Provisioning message to initially provision or to update 553 the white, black, and/or grey multicast channel lists associated with 554 a set of named multicast service profiles, or to enable the AN to 555 perform admission control for specific classes of flows. 557 To provision or update a multicast service profile, the NAS MUST 558 include within the message one or more instances of the Multicast- 559 Service-Profile TLV specifying the content to be provisioned or 560 updated. The NAS SHOULD NOT include any list type (white, black, or 561 grey) that is not supported by the set of multicast capabilities 562 negotiated between the NAS and the AN. The NAS MUST NOT use the 563 Provisioning message to send instances of the Multicast-Service- 564 Profile TLV to the AN unless the Multicast-Service-Profile TLV is 565 supported by the set of multicast capabilities negotiated between the 566 NAS and the AN. 568 To require admission control to be performed at the AN on white- 569 listed flows, the NAS MUST include a copy of the White-List-CAC TLV 570 in the Provisioning message. The White-List-CAC TLV MUST NOT be 571 provided unless the negotiated set of capabilities includes 572 conditional access with white and black lists. 574 To require admission control to be performed at the AN on grey-listed 575 flows or on NAS-initiated flows, the NAS MUST include a copy of the 576 MRepCtl-CAC TLV in the Provisioning message. The MRepCtl-CAC TLV 577 MUST NOT be provided unless the negotiated set of capabilities 578 includes NAS-initiated replication control or conditional access with 579 grey lists. 581 To require buffering of Committed Bandwidth Report messages so that 582 reports for multiple access lines can be included in the same 583 message, the NAS MUST include a copy of the Report-Buffering-Time TLV 584 containing a non-zero time value in a Provisioning message sent to 585 the AN. The Report-Buffering-Time TLV MUST NOT be provided unless 586 the negotiated set of capabilities includes committed bandwidth 587 reporting. 589 4.1.2. Receiver Behaviour 591 The receiving AN provisions/updates the white, black, and/or grey 592 lists associated with the multicast service profile names contained 593 in the Multicast-Service-Profile TLV instances within the message 594 according to the contents of the associated List-Action TLVs. The AN 595 MUST process List-Action TLVs in the order in which they appear 596 within the message. The AN MUST ignore instances of the List-Action 597 TLV referring to any list type (white, black, or grey) that is not 598 supported by the set of multicast capabilities negotiated between the 599 NAS and the AN. 601 When a new multicast service profile is identified by a Multicast- 602 Service-Profile TLV, the initial state of all lists associated with 603 that profile according to the negotiated set of multicast 604 capabilities is empty until changed by the contents of Multicast- 605 Service-Profile TLVs. 607 The receipt of a Provisioning message containing updates to an 608 existing multicast service profile subsequent to startup will cause 609 the AN to review the status of active flows on all ports to which 610 that profile has been assigned. For further details, see Section 6. 612 If the White-List-CAC and/or MRepCtl-CAC TLV is present in the 613 Provisioning message and the respective associated capabilities have 614 been negotiated, the AN prepares (or continues) to do connection 615 admission control on the indicated class(es) of flow. If one or both 616 of these TLVs was present in an earlier Provisioning message but is 617 absent in the latest message received, the AN ceases to do connection 618 admission control on the indicated class(es) of flow. 620 The buffering time specified in an instance of the Report-Buffering- 621 Time TLV applies to only to Committed Bandwidth Report messages 622 initiated after the new buffering time is received at the AN, not to 623 any message already in the process of accumulation. 625 As indicated in [RFC6320], the AN MUST NOT reply to the Provisioning 626 message if it processed it successfully. If an error prevents 627 successful processing of the message content, the AN MUST return a 628 Generic Response message as defined in [RFC6320], containing a 629 Status-Info TLV with the appropriate content describing the error. 630 For this purpose, the presence of a list type in a Multicast-Service- 631 Profile TLV which was ignored because it was not supported by the 632 negotiated set of capabilities is not considered to be an error. 634 4.2. Port Management Message 636 As specified in [RFC6320], the NAS may send DSL line configuration 637 information to the AN ("ANCP based DSL Line Configuration" use case) 638 using ANCP Port Management messages. See Section 7.3 of [RFC6320] 639 for the format of the Port Management message in that usage. 641 This document specifies that the Port Management message MAY be used 642 to convey either or both of the following TLVs: 644 o Multicast-Service-Profile-Name TLV (defined in Section 5.2). This 645 TLV associates a Multicast Service Profile with the Access Port 646 specified by the extension block. 648 o Bandwidth-Allocation TLV (defined in Section 5.5). This TLV 649 specifies the total multicast bandwidth available to the AN for 650 admission control at the Access Port. 652 When the Port Management message is used for this purpose: 654 o the Function field in the Port Management message MUST be set to 655 8, "Configure Connection Service Data". 657 o the message MUST include TLV(s) to identify the access line 658 concerned. If the access line is a DSL loop, the line-identifying 659 TLV(s) MUST be as specified in Section 5.1.2 of [RFC6320]. For 660 non-DSL access lines, the appropriate alternative line-identifying 661 TLV(s) MUST be present. Line configuration data other than the 662 two TLVs listed in the previous paragraph MAY be present. 664 4.2.1. Sender Behaviour 666 The NAS sends the Port Management message at startup time to 667 initialize parameters associated with the Access Port specified in 668 the message and with the multicast capabilities negotiated between 669 the NAS and the AN. The NAS MAY send additional Port Management 670 messages subsequent to startup, to update or, in the case of the 671 Bandwidth-Allocation TLV, reset these parameters. If the NAS 672 includes a Multicast-Service-Profile-Name TLV in the Port Management 673 message, the name MUST match a profile name provided in a Multicast- 674 Service-Profile TLV in a prior Provisioning message. The NAS MUST 675 NOT include a TLV unless it is supported by the set of multicast 676 capabilities negotiated between the NAS and the AN. See Section 6 677 for further information. 679 4.2.2. Receiver Behaviour 681 If the Port Management message contains a Multicast-Service-Profile- 682 Name TLV, the AN associates the named profile with the specified 683 Access Port. This association replaces any previous association. 684 That is, a given Access Port is associated with at most one multicast 685 service profile. The replacement of one multicast service profile 686 with another will cause the AN to review the status of all active 687 flows on the target port. For further details see Section 6. 689 If the Port Management message contains a Bandwidth-Allocation TLV, 690 the AN adopts this as the current value of its total multicast 691 bandwidth limit for the target port. If the AN has already committed 692 multicast bandwidth exceeding the amount given in the Bandwidth- 693 Allocation TLV, the AN SHOULD NOT discontinue any multicast streams 694 in order to bring bandwidth down to within the new limit. However, 695 the AN MUST NOT admit new multicast streams that are subject to 696 admission control until it can do so within the limit specified by 697 the Bandwidth-Allocation TLV. 699 If the Port Management request cannot be processed due to error and 700 the Result field of the request is Nack (0x1) or AckAll (0x2), the AN 701 SHOULD add a Status-Info TLV to the Extension Value field in its 702 reply if this will provide useful information beyond what is provided 703 by the Result Code value returned in the response header. In 704 particular, if the name within the Multicast-Service-Profile-Name TLV 705 does not match a profile name given in a prior Provisioning message, 706 the AN SHOULD return a reply where the Result Code field in the 707 header indicates 0x55, "Invalid TLV contents", the Error Message 708 field in the Status-Info TLV contains the text "Multicast profile 709 name not provisioned", and the Status-Info TLV contains a copy of the 710 Multicast-Service-Profile-Name TLV. 712 4.3. Multicast Replication Control Message 714 This section defines a new message called the Multicast Replication 715 Control message. The Multicast Replication Control message is sent 716 by the NAS to the AN with one or more directives to add (join) or 717 delete (leave) a multicast flow on a target object identified in the 718 content of the message. 720 The Message Type for the Multicast Replication Control message is 721 144. 723 The ANCP Multicast Replication Control message payload contains the 724 following TLVs: 726 o Target TLV: The Target TLV is defined in Section 4.3 of [RFC6320]. 727 It MUST appear once and only once. It is encoded as specified in 728 [RFC6320] or extensions and identifies the AN port subject to the 729 request for admission or release. 731 o Command TLV: The Command TLV is defined in Section 4.4 of 732 [RFC6320]. It MUST be present. It MAY appear multiple times. 734 As [RFC6320] indicates, the contents of the Command Info field within 735 the Command TLV are specific to the message in which the TLV occurs. 736 For the Multicast Replication Control Message, these contents consist 737 of: 739 o a Command Code field; 741 o an Accounting field; 743 o an instance of the Multicast-Flow TLV. 745 Figure 5 illustrates the complete Command TLV with the contents 746 specific to the Multicast Replication Control message. 748 1 2 3 749 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 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | TLV Type = Command | Command-TLV Length | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 |Command Code | Accounting | Reserved | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | Multicast-Flow TLV | 756 | ... | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | Other embedded TLV Type | Other embedded TLV Length | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | | 761 ~ Other embedded TLV data ~ 762 | | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 Figure 5: Contents of the Command TLV in the Multicast Replication 766 Control Message 768 Command Code: 769 Command directive: 771 1 - Add; 773 2 - Delete; 775 3 - Delete All; 777 4 - Admission Control Reject; 779 5 - Conditional Access Reject; 781 6 - Admission Control and Conditional Access 782 Reject. 784 Directives 4 through 6 are used as described in 785 Section 4.4.2. 787 Accounting: 788 Meaningful only when the Command Code is "Add" (1). In 789 that case, 0x00 indicates no flow accounting, 0x01 790 indicates that octet accounting for the flow is to 791 commence. The Accounting field MUST be set to 0x00 for 792 other Command Code values. 794 Reserved: 795 Reserved for future use. MUST be set to 0x0000 by the 796 sender and ignored by the receiver. 798 Multicast-Flow TLV: 799 An instance of the Multicast-Flow TLV (Section 5.11) 800 specifying the flow to be added or deleted. The Multicast- 801 Flow TLV MUST be omitted if the Command Code has value 802 "Delete All" (3). 804 Other embedded TLV: 805 No other embedded TLVs are currently specified within the 806 Multicast Replication Control message/Command TLV. 807 However, see the description of the Multicast Admission 808 Control message (Section 4.4). Unrecognized embedded TLVs 809 SHOULD be silently discarded. 811 The figure below is an example of a Multicast Replication Control 812 message that would result in a swap from multicast Source-Specific 813 Multicast (SSM) flows 2001:DB8::1, FF34::2, to 2001:DB8::2, FF34::3 814 on the Target identified by the "Access Loop Circuit ID": 816 1 2 3 817 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 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | Type (0x880C) | Length | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | Version | MsgType=144 | 0x02 | Result Code | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | Partition ID | Transaction Identifier = 0001 | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 |I| SubMessage Number | Length | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | Type = Target 0x1000 | Target TLV Length | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | | 832 ~ Access Loop Circuit ID ~ 833 | | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Type = Command TLV | Command-TLV Length = 0x0014 | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | Cmd Code=2 |Acctg = 0x00 | Reserved = 0x0000 | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 |TLV Type = Multicast-Flow | TLV Length = 0x000C | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 |Flow Type=0x02 |AddrFam = 0x02 | Reserved = 0x0000 | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | | 844 ~ Multicast Group Address ~ 845 | = FF34::2 | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | | 848 ~ Source Address ~ 849 | = 2001:DB8::1 | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | Type = Command-TLV | Command-TLV Length = 0x0014 | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Cmd Code=1 |Acctg = 0x01 | Reserved = 0x0000 | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 |TLV Type = Multicast-Flow | TLV Length = 0x000C | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 |Flow Type=0x02 |AddrFam = 0x02 | Reserved = 0x0000 | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Multicast Group Address = FF34::3 | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | Source Address = 2001:DB8::2 | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 863 | | 864 ~ Multicast Group Address ~ 865 | = FF34::3 | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | | 868 ~ Source Address ~ 869 | = 2001:DB8::2 | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 4.3.1. Sender Behaviour 874 The NAS MAY issue a Multicast Replication Control message to the AN 875 to convey one or more directives to add (join) or delete (leave) one 876 or more multicast flows. 878 The NAS MAY send this message on its own initiative to support the 879 NAS initiated Multicast Control use case presented in [RFC5851] and 880 summarized in Section 3.1. In that case, the NAS MUST set the Result 881 field to AckAll (0x2) or Nack (0x1) according to its requirements. 883 The NAS MAY also send this message in response to a Multicast 884 Admission Control message (defined in Section 4.4) received from the 885 AN to support the conditional access and admission control use case 886 presented in [RFC5851] and summarized in Section 3.2. In that case, 887 the NAS MUST set the Result field to NAck (0x1). 889 In either case, the sender MUST populate the Result Code field with 890 the value 0x000 and the ANCP Transaction Identifier field with a 891 unique value, as described in Section 3.6.1.6 of [RFC6320]. 893 Each Multicast Replication Control Message MUST contain one or more 894 commands, each encapsulated in its own Command TLV. The sender MUST 895 use a separate Command TLV for each distinct multicast flow. 897 When the order of processing of two commands does not matter, the 898 commands MUST be transmitted in separate Multicast Replication 899 Control messages. 901 4.3.2. Receiver Behaviour 903 When successive commands (in the same or different messages) relate 904 to the same Target and multicast flow, the state of each feature 905 controlled or affected by attributes received in the Multicast 906 Replication Control message, SHALL be as set by the last command or 907 message referring to that target and flow and containing the 908 controlling attribute. As an example, successive Multicast 909 Replication Control messages containing add commands for a given port 910 and flow, but differing only in the Accounting field setting SHALL be 911 interpreted to mean that the state of the accounting feature is as 912 set in the final command received, but all other features are as set 913 in the initial message. 915 If more than one Command TLV is present in a Multicast Replication 916 Control message, the AN MUST act on the commands in the order in 917 which they are presented in the message. The AN SHALL assign a 918 sequence number to each command in a given Multicast Replication 919 Control message, starting from 0x01 for the first command. 921 If a Command TLV adds a flow and the AN is performing admission 922 control for Multicast Replication Control messages, then the AN MUST 923 perform admission control before replicating the flow. If the 924 admission control check fails, the AN MUST treat the failure as an 925 error as described below. The appropriate Result Code value for the 926 response is 0x013 "Out of resources". 928 If the AN processes the complete Multicast Replication Control 929 message successfully and the Result field of the Multicast 930 Replication Control message was set to AckAll (0x2), the AN MUST 931 respond with a Generic Response message where the Result field is set 932 to Success (0x3), the Result Code field is set to 0x000, and the 933 Transaction Identifier field is copied from the Multicast Replication 934 Control message. The body of the response MAY be empty or MAY be 935 copied from the Multicast Replication Control message. 937 If the AN processes the complete Multicast Replication Control 938 message successfully and the Result field of the Multicast 939 Replication Control message was set to Nack (0x1), the AN MUST NOT 940 respond to the message. 942 The processing/execution of multiple commands contained in a single 943 Multicast Control message MUST be interrupted at the first error 944 encountered, and the remaining commands in the Multicast Replication 945 Control message discarded. 947 If the AN detects an error in a received Multicast Replication 948 Control message and the Result field in that message was set to Nack 949 (0x1) or AckAll(0x2), the AN MUST generate a Generic Response message 950 providing error information to the NAS. This specification 951 identifies the following new Result Code values beyond those 952 specified in [RFC6320], which MAY be used in a Generic Response sent 953 in reply to a Multicast Replication Control message: 955 0x64 Command error. 957 Where detected: ANCP agent at the AN. 959 Further description: an invalid command code has been received. 961 Required additional information in the message: see below. 963 Target: ANCP agent at the NAS. 965 Action RECOMMENDED for the receiving ANCP agent: Correct the 966 error and re-send the request, if possible. Otherwise, report 967 the error to the control application with an indication of the 968 erroneous information associated with the invalid TLV(s). 970 0x65 Invalid flow address. 972 Where detected: ANCP agent at the AN. 974 Further description: either inconsistent flow address 975 information has been provided or the address family is 976 unsupported. 978 Required additional information in the message: see below. 980 Target: ANCP agent at the NAS. 982 Action RECOMMENDED for the receiving ANCP agent: correct the 983 error and re-send the request, if possible. Otherwise, report 984 the error to the control application with an indication of the 985 erroneous information associated with the invalid TLV(s). 987 0x66 Multicast flow does not exist. 989 Where detected: control application at the AN. 991 Further description: the NAS has attempted to delete a flow 992 that is not active on the given access line. 994 Required additional information in the message: see below. 996 Target: control application at the NAS. 998 Action RECOMMENDED for the receiving ANCP agent: report the 999 error to the control application with an indication of the 1000 erroneous information associated with the invalid TLV(s). 1002 A Generic Response message responding to the Multicast Replication 1003 Control message and containing one of the above Result Code values 1004 MUST include a Status-Info TLV which includes one or two embedded 1005 TLVs as follows: 1007 o a Sequence-Number TLV as described in Section 5.4, giving the 1008 sequence number of the failed command, MUST be included; 1010 o the failed Command TLV itself SHOULD be included. 1012 Note that the Error Message field of the Status-Info TLV MAY be 1013 used to report more details than implied by the Result Code value 1014 in the message header. For example, the Result Code value could 1015 be 0x65 and the Error Message field could contain the text: 1016 "Source address present for ASM flow". 1018 4.4. Multicast Admission Control Message 1020 This section defines a new message called the Multicast Admission 1021 Control message. The Multicast Admission Control message is sent by 1022 the AN to the NAS to request admission of a multicast flow, or to 1023 notify of the removal of a multicast flow, for a given target. 1025 The Message Type for the Multicast Admission Control message is 145. 1027 The ANCP Multicast Admission Control message payload contains two 1028 TLVs: 1030 o Target TLV: The Target TLV is defined in [RFC6320]. It MUST 1031 appear once and only once in the Multicast Admission Control 1032 message. It is encoded as specified in [RFC6320] or extensions 1033 and identifies the AN port subject to the request for admission or 1034 release. 1036 o Command TLV: The Command TLV is defined in [RFC6320]. It MUST be 1037 present. If it appears more than once, only the first instance is 1038 considered meaningful in the present version of this specification 1039 and the other instances are ignored. 1041 Note: 1043 In the future, the specification of the Admission Control message 1044 may be extended to allow transport of more than a single directive 1045 (e.g., to carry both a leave from one group and a join to another 1046 group for the same Target). It is expected that this would 1047 support a similar notion of strict sequenced processing as 1048 currently defined for handling multiple directives in the 1049 Multicast Replication Control message whereby all directives 1050 following the first directive that can not be executed are not 1051 executed either. When the strict sequenced processing of the 1052 directives is not required the directives are distributed across 1053 separate messages. 1055 The Command TLV has the same contents as were described above for the 1056 Multicast Replication Control message, with the following additions: 1058 o a Request-Source-IP TLV MAY be appended to the Command TLV as an 1059 additional embedded TLV; 1061 o similarly, a Request-Source-MAC TLV MAY be appended to the Command 1062 TLV as an additional embedded TLV. 1064 Note that the Command TLV length includes the length of any embedded 1065 TLVs, including the embedded TLV headers. 1067 4.4.1. Sender Behaviour 1069 The AN sending the Multicast Admission Control message MUST set the 1070 Result field to Ignore (0x0). 1072 The AN MUST populate the ANCP Transaction Identifier field with a 1073 unique value, as described in Section 3.6.1.6 of [RFC6320]. 1075 The AN MUST encode the Command TLV as specified in Section 4.3 with 1076 the following additional rules: 1078 o the Accounting field MUST be set to 0; 1079 o the Command Code field MUST be set to "1 - Add" when the message 1080 conveys a Join , to "2 - Delete" when the message conveys a Leave 1081 and to "3 - Delete All" when the message conveys a Leave of all 1082 channels (on the target); 1084 o The Multicast-Flow TLV within the Command TLV identifies the 1085 multicast flow subject to the request for admission or release. 1086 When the Command Code is 3, the Multicast-Flow TLV is meaningless 1087 and MUST be omitted. 1089 o the Request-Source-IP embedded TLV MAY be included by the AN to 1090 convey the IP address of the sender of the join/leave message 1091 (e.g., IGMP/MLD Join/Leave) that triggered the AN to include the 1092 corresponding Command TLV in the Admission Control message. If it 1093 appears more than once, only the first instance is considered 1094 meaningful and the other instances are ignored. 1096 o the Request-Source-MAC embedded TLV MAY be included by the AN to 1097 convey the MAC address of the sender of the join/leave message 1098 (e.g., IGMP/MLD Join/Leave) that triggered the AN to include the 1099 corresponding Command TLV in the Admission Control message. If it 1100 appears more than once, only the first instance is considered 1101 meaningful and the other instances are ignored. 1103 4.4.2. Receiver Behaviour 1105 On receipt of an Multicast Admission Control message, the NAS: 1107 o MUST ignore the Result field; 1109 o if the directive in the Multicast Admission Control message is "2 1110 - Delete" or "3 - Delete All" and is processed correctly by the 1111 NAS, the NAS MUST NOT generate any ANCP message in response to the 1112 Multicast Admission Control message; 1114 o if the directive in the Multicast Admission Control message is "1 1115 - Add" and is accepted by the NAS, the NAS MUST generate a 1116 Multicast Replication Control in response to the Multicast 1117 Admission Control message. The Multicast Replication Control 1118 message: 1120 * MUST contain a Result set to Nack (0x1); 1122 * MUST contain a Transaction ID with a unique value, as described 1123 in Section 3.6.1.6 of [RFC6320]; 1125 * MUST contain the directive as accepted by the NAS. The NAS MAY 1126 modify the Accounting field if flow accounting is required. 1128 o if the directive in the Multicast Admission Control message is "1 1129 - Add", is processed correctly but not accepted by the NAS (i.e., 1130 it does not pass the admission control or conditional access 1131 check), the NAS MAY generate a Multicast Replication Control 1132 message in response to the Multicast Admission Control message. 1133 This optional message can be used by the AN to maintain statistics 1134 about admission control rejections. 1136 In the future, the AN may be able to notify the subscriber that 1137 the request was rejected (e.g., using 1138 [I-D.morin-mboned-igmpmld-error-feedback]). 1140 When used in this situation, the Multicast Replication Control 1141 message: 1143 * MUST contain a Result set to 0x0; 1145 * MUST contain a Transaction ID with a unique value, as described 1146 in Section 3.6.1.6 of [RFC6320]; 1148 * MUST contain the directive rejected by the NAS (i.e., Target 1149 TLV and Command TLV) but with a Command Code set to "4 - 1150 Admission Control Reject", "5 - Conditional Access Reject", or 1151 "6 - Admission Control and Conditional Access Reject" as 1152 applicable. 1154 o if the Multicast Admission Control message cannot be processed 1155 correctly by the NAS (e.g. the message is malformed, the multicast 1156 flow does not exist etc.), the NAS MUST generate a Generic 1157 Response message (defined in Section 4.2 of [RFC6320]) with 1158 appropriate content indicating the reason for the failure. 1160 4.5. Bandwidth Reallocation Request Message 1162 The Bandwidth Reallocation Request message is used when the bandwidth 1163 delegation capability is included in the negotiated set. It MAY be 1164 sent either by the NAS or by the AN to request an adjustment in the 1165 amount of delegated bandwidth. It will be sent by the NAS typically 1166 to reduce the multicast bandwidth allocated to the AN in order for 1167 the NAS to satisfy a request to add one or more flows. Conversely, 1168 the AN will send a Bandwidth Reallocation Request to obtain 1169 additional bandwidth to satisfy a request to add a multicast channel. 1170 In each case, the requestor has a minimum requirement for additional 1171 bandwidth, and MAY ask for additional bandwidth beyond this amount 1172 (e.g., to handle anticipated future requests). 1174 The Bandwidth Reallocation Request message contains two TLVs: 1176 o the Target TLV (Section 4.3 of [RFC6320] or an extension), 1177 specifying a single access line; 1179 o the Bandwidth-Request TLV (Section 5.8), specifying the required 1180 and preferred amounts of delegated bandwidth. 1182 The Message Type for the Bandwidth Reallocation Request message is 1183 146. 1185 4.5.1. Sender Behaviour 1187 The Result field in the header of the Bandwidth Reallocation Request 1188 message is not used and the sender MUST set it to Ignore (0x0). 1190 The bandwidth values in the Bandwidth-Request TLV are expressed in 1191 terms of total multicast bandwidth allocated to the AN. 1193 The choice of "total bandwidth" rather than "incremental 1194 bandwidth" was made so that it would be easier for the AN and NAS 1195 to keep their respective views of the current amount of delegated 1196 bandwidth synchronized. 1198 Because the values are totals rather than desired increments/ 1199 decrements, the relationship between the required amount and the 1200 preferred amount will differ depending on whether the Bandwidth 1201 Reallocation Request message is issued by the NAS or the AN. 1203 o If the NAS is making the request, the preferred amount MUST be 1204 less than or equal to the required amount. The required amount 1205 MUST be less than the current amount of delegated bandwidth. 1207 o If the AN is making the request, the preferred amount MUST be 1208 greater than or equal to the required amount. The required amount 1209 MUST be greater than the current amount of delegated bandwidth. 1211 4.5.2. Receiver Behaviour 1213 When the peer receives a valid Bandwidth Reallocation Request 1214 message, it SHOULD determine whether it can satisfy the request from 1215 its existing allocation of unused video bandwidth. If it decides 1216 that it can reallocate bandwidth to the peer, it MAY choose to return 1217 any amount between the required and the preferred amounts indicated 1218 in the Bandwidth Reallocation Request message. 1220 The peer MUST return a Bandwidth Transfer message (Section 4.6) 1221 indicating its decision. If the request is met, the Result field of 1222 the Bandwidth Transfer message MUST be set to Success (0x3), the 1223 Result Code field MUST be set to 0x000, and the Bandwidth-Allocation 1224 TLV (Section 5.5) MUST contain the new value of total multicast 1225 bandwidth. This new value MUST lie between the required and 1226 preferred values, inclusive, from the request message. If the 1227 request is not met, the Result field of the Bandwidth Transfer 1228 message MUST be set to Failure (0x4), the Result Code field MUST be 1229 set to 0x000, and the Bandwidth Allocation TLV MUST contain the value 1230 of the currently allocated amount of delegated bandwidth as the 1231 responder views it. 1233 The following cases indicate that the sender holds a different view 1234 of the amount of delegated bandwidth from the receiver: 1236 o the NAS receives a request where the required amount is less than 1237 its view of the current amount of delegated bandwidth; 1239 o the AN receives a request where the required amount is greater 1240 than its view of the current amount of delegated bandwidth. 1242 If one of these cases occurs, the receiver with one exception MUST 1243 send a Bandwidth Transfer message indicating Success. 1245 o If the NAS received the request, the allocated amount in the NAS's 1246 response MUST be at least equal to NAS's view of the current 1247 amount of delegated bandwidth. 1249 o If the AN received the request, the allocated amount in the AN's 1250 response MUST be no greater than the AN's view of the current 1251 amount of delegated bandwidth. 1253 The exception is when the NAS receives a request while it has a 1254 request of its own outstanding. Handling of that case is described 1255 below. 1257 While the cases just described are an error condition, the success 1258 response achieves a graceful recovery. 1260 To avoid deadlock due to race conditions, the following rules MUST be 1261 applied: 1263 a. If the NAS receives a Bandwidth Reallocation Request message 1264 while it has a Bandwidth Reallocation Request message of its own 1265 outstanding for the same access line, the NAS MUST provide an 1266 immediate failure response to the request from the AN, with a 1267 Result Code value set to 0x68 "Inconsistent views of delegated 1268 bandwidth amount" or 0x69 "Bandwidth request conflict" as 1269 applicable. (See below for more information). 1271 b. If the AN receives a Bandwidth Reallocation Request message while 1272 it has a Bandwidth Reallocation Request message of its own 1273 outstanding for the same access line, the AN MUST release any 1274 bandwidth it has already committed to an outstanding Join request 1275 while it is awaiting a response from the NAS. It MUST decide 1276 upon and send its response to the NAS taking the released 1277 bandwidth into account. 1279 If the receiver is unable to process the Bandwidth Reallocation 1280 Request message due to an error, then the receiver MUST return a 1281 Bandwidth Transfer message where: 1283 o the Result field is set to Failure (0x4), 1285 o the Result Code field is set appropriately to indicate the type of 1286 error that was detected, 1288 o the Bandwidth Allocation TLV contains the value of the current 1289 amount of delegated bandwidth as the responder views it, and 1291 o a Status-Info TLV MAY follow the Bandwidth Allocation TLV giving 1292 further information about the error. 1294 This specification provides three new Result Code values applicable 1295 specifically to the contents of the Bandwidth-Request TLV. These 1296 Result Code values by their nature MUST only be used when the error 1297 is being reported in a Bandwidth Transfer message rather than a 1298 Generic Response message. 1300 0x67 Invalid preferred bandwidth amount. 1302 Where detected: control application at the receiver of the 1303 Bandwidth Reallocation Request message. 1305 Further description: the preferred and required amounts of 1306 bandwidth in the TLV do not have the numerical relationship 1307 described above. 1309 Required additional information in the message: as described 1310 above. 1312 Target: control application at the sender of the Bandwidth 1313 Reallocation Request message. 1315 Action RECOMMENDED for the receiving ANCP agent: report the 1316 error to the control application with the returned value of the 1317 Bandwidth-Allocation TLV. See also Section 4.6.2.2. 1319 0x68 Inconsistent views of delegated bandwidth amount. 1321 Where detected: control application at the NAS. 1323 Further description: the NAS has an outstanding Bandwidth 1324 Reallocation Request, so it is rejecting a similar request from 1325 the AN. In the AN request, the required amount was less than 1326 the NAS's view of the current amount of delegated bandwidth. 1328 Required additional information in the message: as described 1329 above. 1331 Target: control application at the AN. 1333 Action RECOMMENDED for the receiving ANCP agent: report the 1334 error to the AN control application with the returned value of 1335 the Bandwidth-Allocation TLV. See also Section 4.6.2.2. 1337 0x69 Bandwidth request conflict. 1339 Where detected: control application at the NAS. 1341 Further description: the NAS has an outstanding Bandwidth 1342 Reallocation Request, so it is rejecting a similar, valid 1343 request from the AN. 1345 Required additional information in the message: as described 1346 above. 1348 Target: control application at the AN. 1350 Action RECOMMENDED for the receiving ANCP agent: report the 1351 error to the AN control application with the returned value of 1352 the Bandwidth-Allocation TLV. See also Section 4.6.2.2. 1354 4.6. Bandwidth Transfer Message 1356 The Bandwidth Transfer message is used to transfer video bandwidth 1357 from the sender to the peer for a specific access line. This message 1358 MAY be sent either from the AN or from the NAS. As described in the 1359 previous section, it is the required response to a valid Bandwidth 1360 Reallocation Request message. 1362 The Bandwidth Transfer message MAY also be used to transfer bandwidth 1363 autonomously from one peer to another. One example of this usage is 1364 to release bandwidth borrowed earlier by means of the Bandwidth 1365 Reallocation Request message. When the message is used in this way, 1366 the Result field in the Bandwidth Transfer message MUST be set to 1367 Ignore (0x0). 1369 This allows the receiver to distinguish between an autonomous 1370 transfer and a response to a previous Bandwidth Reallocation 1371 Request, for purposes of validation. 1373 The Message Type for the Bandwidth Transfer message is 147. The 1374 Bandwidth Transfer message contains the following TLVs: 1376 o the Target TLV, designating the access line concerned; 1378 o an instance of the Bandwidth-Allocation TLV (Section 5.5). The 1379 bandwidth value in the Bandwidth-Allocation TLV is the new amount 1380 of delegated bandwidth allocated to the target. 1382 4.6.1. Sender Behaviour 1384 When sending a Bandwidth Transfer message where the Result value is 1385 Ignore (0x0) or Success (0x3), the following relationships MUST hold: 1387 o if the message is sent by the NAS, the bandwidth value in the 1388 Bandwidth-Allocation TLV MUST be greater than or equal to the 1389 sender's view of the current amount of delegated bandwidth for the 1390 access line concerned; 1392 o if the message is sent by the AN, the bandwidth value in the 1393 Bandwidth-Allocation TLV MUST be less than or equal to the 1394 sender's view of the current amount of delegated bandwidth for the 1395 access line concerned. 1397 Further sender behaviour is specified above, in Section 4.5.2. 1399 4.6.2. Receiver Behaviour 1401 4.6.2.1. Behaviour of the NAS 1403 If the amount of delegated bandwidth provided in the Bandwidth- 1404 Allocation TLV is not greater than the NAS's view of the current 1405 amount of delegated bandwidth, the NAS MUST update its view of the 1406 current amount of delegated bandwidth to the amount indicated in the 1407 Bandwidth Transfer message. This is required regardless of whether 1408 the Result field of that message indicates Success or Failure. 1410 If the amount of delegated bandwidth provided in the Bandwidth- 1411 Allocation TLV is greater than the NAS's view of the current amount 1412 of delegated bandwidth, the NAS MAY accept the given value as its new 1413 value of delegated bandwidth. Alternatively, the NAS MAY force the 1414 AN to modify its view of the amount of delegated bandwidth to that 1415 held by the NAS, by sending a Port Management message for the target 1416 access line concerned, containing a Bandwidth-Allocation TLV with a 1417 value equal to the amount of delegated bandwidth the NAS wishes to 1418 enforce. 1420 4.6.2.2. Behaviour of the AN 1422 If the amount of delegated bandwidth provided in the Bandwidth- 1423 Allocation TLV of the Bandwidth Transfer message differs from the 1424 AN's view of the current amount of delegated bandwidth, the AN MUST 1425 update its view of the current amount of delegated bandwidth to the 1426 amount indicated in the Bandwidth Transfer message. This is required 1427 with the exception of a Bandwidth Transfer message with a Result 1428 field equal to Failure (0x4) and a Result Code field equal to 0x68 1429 "Inconsistent views of delegated bandwidth amount" or 0x69 "Bandwidth 1430 request conflict". If Result Code value 0x68 is received, the AN 1431 MUST issue a Delegated Bandwidth Query Request message to determine 1432 the NAS's current view of the amount of delegated bandwidth. The AN 1433 MUST update its own view based on the value returned in the Delegated 1434 Bandwidth Query Response. If Result Code value 0x69 is received, the 1435 AN SHOULD carry out this procedure unless it can account for the 1436 discrepancy as a result of a transfer of bandwidth to the NAS that 1437 was carried out just before the incoming Bandwidth Transfer message 1438 was processed. 1440 The two Result Code values indicate a race condition where the AN 1441 may have just completed a transfer of bandwidth to the NAS. As a 1442 result, the value given in the Bandwidth Transfer message may be 1443 outdated, and the AN needs to query the NAS to find its latest 1444 view. The procedure assumes that ordering is preserved between 1445 the Bandwidth Transfer message sent by the AN in response to the 1446 NAS's request and the subsequent Delegated Bandwidth Query Request 1447 message. 1449 If as the result of the procedures just described the AN determines 1450 that it has over-committed multicast bandwidth, it MUST NOT terminate 1451 any currently-active programs, but MUST NOT honour any more "join" 1452 requests until it is possible to do so within the limit set by its 1453 current value of delegated bandwidth. 1455 4.7. Delegated Bandwidth Query Request Message 1457 The Message Type for the Delegated Bandwidth Query Request (and 1458 Response) messages is 148. 1460 The Delegated Bandwidth Query Request message MAY be sent either by 1461 the NAS or by the AN to retrieve the peer's view of the amount of 1462 delegated bandwidth. The request contains one TLV: 1464 o a Target TLV designating the access line for which the information 1465 is requested. 1467 4.7.1. Sender Behaviour 1469 The sender MUST set the Result field in the header of the Delegated 1470 Bandwidth Query Request message to AckAll (0x2). The Result Code 1471 value MUST be set to 0x000. The sender MUST populate the ANCP 1472 Transaction Identifier field with a unique value, as described in 1473 Section 3.6.1.6 of [RFC6320]. 1475 4.7.2. Receiver Behaviour 1477 If the AN or NAS receives a valid Delegated Bandwidth Query Request 1478 message, it MUST respond with a Delegated Bandwidth Query Response 1479 message. The Result field in the header of the response MUST be set 1480 to Success (0x3). The Result Code field MUST be set to 0x000. The 1481 Transaction-Id field MUST be copied from the request message. The 1482 body of the response MUST contain the Target TLV, copied from the 1483 request message. Finally, the body of the response MUST contain a 1484 Bandwidth-Allocation TLV, containing the current amount of delegated 1485 bandwidth from the point of view of the receiver of the request. 1487 If the contents of the Delegated Bandwidth Query Request message are 1488 in error, the receiver MUST return a Delegated Bandwidth Query 1489 Response message with the Result field in the header set to Failure 1490 (0x3). The Result Code field MUST be set to the value that indicates 1491 the nature of the error (e.g., 0x500 "One or more of the specified 1492 ports do not exist"). The Transaction-Id field MUST be copied from 1493 the request. The body of the response MUST contain the Target TLV 1494 copied from the request. This MAY be followed by a Status-Info TLV 1495 giving further information about the error. 1497 4.8. Delegated Bandwidth Query Response Message 1499 The Delegated Bandwidth Query Response message is sent in reply to a 1500 Delegated Bandwidth Query Request. The response to a valid request 1501 contains two TLVs: 1503 o the Target TLV, copied from the request; 1505 o a Bandwidth-Allocation TLV, giving the responder's view of the 1506 current amount of multicast bandwidth delegated to the AN. 1508 The Message Type for the Delegated Bandwidth Query Response message 1509 is 148. 1511 4.8.1. Sender Behaviour 1513 Sender behaviour for the Delegated Bandwidth Query Response message 1514 is specified in Section 4.7.2. 1516 4.8.2. Receiver Behaviour 1518 If the Delegated Bandwidth Query Response message indicates Success 1519 (0x3), the following actions apply. 1521 4.8.2.1. Behaviour at the NAS 1523 If the amount of delegated bandwidth provided in the Bandwidth- 1524 Allocation TLV is less than the NAS's view of the current amount of 1525 delegated bandwidth, the NAS MUST update its view of the current 1526 amount of delegated bandwidth to the amount indicated in the 1527 Delegated Bandwidth Query Response message. 1529 If the amount of delegated bandwidth provided in the Bandwidth- 1530 Allocation TLV is greater than the NAS's view of the current amount 1531 of delegated bandwidth, the NAS MAY accept the given value as its new 1532 value of delegated bandwidth. Alternatively, the NAS MAY force the 1533 AN to modify its view of the amount of delegated bandwidth to that 1534 held by the NAS, by sending a Port Management message for the target 1535 access line concerned, containing a Bandwidth-Allocation TLV with a 1536 value equal to the amount of delegated bandwidth the NAS wishes to 1537 enforce. 1539 4.8.2.2. Behaviour at the AN 1541 The AN SHOULD accept the value returned in the Bandwidth-Allocation 1542 TLV of the Delegated Bandwidth Query Response message as the correct 1543 value of the current amount of delegated bandwidth. If the AN has 1544 currently committed more than this amount to active programs, it MUST 1545 NOT cease replicating the flows concerned, but MUST NOT honour any 1546 more Join requests until possible to do so within the new limit. 1548 A race condition is possible, where the AN sends a query, the NAS 1549 requests more bandwidth, then receives and responds to the query, 1550 then receives the Bandwidth Transfer message responding to its 1551 request. It is up to the AN to take appropriate action in this 1552 case. The best action appears to be not to act on the result of 1553 the first query, but to repeat the query after sending the 1554 Bandwidth Transfer message. Similar considerations apply to a 1555 race between queries from both sides. 1557 4.9. Multicast Flow Query Request and Response Messages 1559 This section defines two new messages called the Multicast Flow Query 1560 Request and Multicast Flow Query Response. The Multicast Flow Query 1561 Request is sent by the NAS to request information about the multicast 1562 flows that are active on the AN. The Multicast Flow Query Response 1563 is sent in response by the AN to provide the requested information to 1564 the NAS. 1566 The Message Type for the Multicast Flow Query Request and Multicast 1567 Flow Query Response messages is 149. 1569 The contents of the Multicast Flow Query Request and Response depend 1570 on the nature of the query, as described below. 1572 4.9.1. Sender Behaviour 1574 The sender of a Multicast Flow Query Request message MUST set the 1575 Result field to AckAll (0x2). The Result Code field MUST be set to 1576 0x000. The sender MUST populate the ANCP Transaction Identifier 1577 field with a unique value, as described in section 3.6.1.6 of 1578 [RFC6320]. 1580 The Multicast Flow Query Request MAY be used by the NAS to retrieve: 1582 o the AN's view of which multicast flows are currently active on a 1583 specified set of access ports; or 1585 o the AN's view of the access ports on which a specified set of 1586 multicast flows are currently active; or 1588 o the AN's view of all the multicast flows currently active on each 1589 access port of the AN. 1591 To retrieve the AN's view of which multicast flows are currently 1592 active on a given port of the AN, the NAS MUST include a Target TLV 1593 in the Multicast Flow Query Request payload identifying that port. 1594 The Target TLV is encoded as specified in [RFC6320]. 1596 To retrieve the AN's view of the ports currently receiving a given 1597 multicast flow, the NAS MUST include a Multicast-Flow TLV in the 1598 Multicast Flow Query Request payload identifying that flow. The 1599 Multicast-Flow TLV is encoded as specified in Section 5.11. 1601 The NAS MAY include multiple Target TLVs or multiple Multicast-Flow 1602 TLVs in the Multicast Flow Query Request, but MUST NOT include both 1603 Target and Multicast-Flow TLVs in the same message. 1605 To retrieve the AN's view of all of the multicast flows currently 1606 active on each port of the AN, the NAS MUST send a Multicast Flow 1607 Query Request which does not contain any instance of the Target TLV 1608 or the Multicast-Flow TLV. 1610 4.9.2. Receiver Behaviour 1612 The AN MUST respond to a Multicast Flow Query Request message that 1613 has a valid format and a valid content with a Multicast Flow Query 1614 Response message. The Result field in the response MUST be set to 1615 Success (0x3). The Result Code field MUST be set to 0x000. The 1616 Transaction-Id field MUST be copied from the request. 1618 If the Multicast Flow Query Request contained one (or more) Target 1619 TLVs, the AN MUST include, for each of these Target TLVs, the 1620 following set of TLVs: 1622 o Target TLV. This MUST be identical to the Target TLV in the 1623 received Multicast Flow Query Request message. 1625 o Multicast-Flow TLV(s). The Multicast-Flow TLV MUST appear once 1626 per multicast flow that is currently active on the AN port 1627 identified in the preceding Target TLV. 1629 The Target TLVs MUST appear in the response from the AN in the same 1630 order as in the query from the NAS. 1632 If the Multicast Flow Query Request contained one (or more) 1633 Multicast-Flow TLVs, the AN MUST include, for each of these 1634 Multicast-Flow TLVs, the following set of TLVs: 1636 o Multicast-Flow TLV. This MUST be identical to the Multicast-Flow 1637 TLV in the received Multicast Flow Query Request message. 1639 o Target TLV(s). The Target TLV MUST appear once per AN port on 1640 which the multicast flow identified in the preceding Multicast- 1641 Flow TLV is active. 1643 The Multicast-Flow TLVs MUST appear in the response from the AN in 1644 the same order as in the query from the NAS. 1646 If the Multicast Flow Query Request contained no Target TLV and no 1647 Multicast Flow TLV, the AN MUST include, for each AN port currently 1648 receiving multicast flow(s), the following set of TLVs: 1650 o Target TLV. This MUST identify one AN port. 1652 o Multicast-Flow TLV(s). The Multicast-Flow TLV MUST appear once 1653 per Multicast Flow that is currently active on the AN port 1654 identified in the preceding Target TLV. 1656 If the contents of the Multicast Flow Query Request are in error, the 1657 AN MUST reply with a Multicast Flow Query Response message with the 1658 Result field set to Failure (0x4) and the Result Code field set to 1659 indicate the nature of the error. If the request contained multiple 1660 instances of the Target TLV or the Multicast-Flow TLV and one of 1661 these is in error, the response message MUST contain the results for 1662 the preceding instances of the TLV as if there had been no error. 1663 These successful results MUST be followed by the TLV in error, copied 1664 from the request. The AN MUST NOT do further processing of the 1665 request. The AN MAY add a Status-Info TLV to provide further 1666 information on the nature of the error. 1668 4.10. Committed Bandwidth Report Message 1670 This section describes the Committed Bandwidth Report message, which 1671 is sent from the AN to the NAS to report the most recent amount of 1672 multicast bandwidth usage committed to one or more access lines. 1674 The Message Type for the Committed Bandwidth Report message is 150. 1676 The Committed Bandwidth Report message contains one or more instances 1677 of the Committed-Bandwidth TLV, as described in Section 5.13. 1679 4.10.1. Sender Behaviour 1681 The sender of a Committed Bandwidth Report message MUST set the 1682 Result field to Ignore (0x0). The Result Code field MUST be set to 1683 0x000. The sender MUST populate the ANCP Transaction Identifier 1684 field with a unique value, as described in section 3.6.1.6 of 1685 [RFC6320]. 1687 Each instance of the Committed-Bandwidth TLV included in the message 1688 MUST identify an access line for which the amount of committed 1689 multicast bandwidth has changed since the previous Committed 1690 Bandwidth Report message was sent and MUST report the latest amount 1691 of multicast bandwidth committed to that line. There MUST be only 1692 one instance of the Committed-Bandwidth TLV present in the message 1693 for any given access line. The message MUST include an instance of 1694 the Committed-Bandwidth TLV for every access line for which committed 1695 multicast bandwidth has changed since the previous Committed 1696 Bandwidth Report message was sent. 1698 Further behaviour at the AN is specified in Section 6.2.2. 1700 4.10.2. Receiver Behaviour 1702 The usage of the contents of a Committed Bandwidth Report message 1703 received by the NAS is implementation-dependent. One example is that 1704 the NAS uses the reports of multicast bandwidth commitments to adjust 1705 its forwarding scheduler operation to provide the intended level of 1706 QoS. 1708 The NAS MUST NOT reply to a valid Committed Bandwidth Report message. 1709 The NAS MAY send a Generic Response message indicating the nature of 1710 any errors detected in a Committed Bandwidth Report message that it 1711 has received. 1713 5. ANCP TLVs For Multicast 1715 This section defines new ANCP TLVs for the control of multicast 1716 flows. 1718 5.1. Multicast-Service-Profile TLV 1720 This document defines the new Multicast-Service-Profile TLV. 1722 The Multicast-Service-Profile TLV MAY be included in a Provisioning 1723 message as specified in Section 4.1. 1725 The Multicast-Service-Profile TLV is illustrated in Figure 6. It 1726 consists of a TLV header encapsulating a single instance of the 1727 Multicast-Service-Profile-Name TLV and one or more instances of the 1728 List-Action TLV. 1730 1 2 3 1731 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 1732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1733 |TLV Type = Mcast Serv Profile | TLV Length | 1734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1735 | Multicast-Service-Profile-Name TLV | 1736 | | 1737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1738 | List-Action TLV | 1739 | | 1740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1741 | ... | 1742 | | 1743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1744 | List-Action TLV | 1745 | | 1746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1748 Figure 6: Multicast-Service-Profile TLV 1750 The Multicast-Service-Profile TLV has the following fields: 1752 o The Multicast-Service-Profile TLV Type is 0x0013. 1754 o The TLV length is determined by the contents following the TLV 1755 header. 1757 o The Multicast-Service-Profile-Name TLV is described in 1758 Section 5.2. The Multicast-Service-Profile-Name TLV MUST contain 1759 an identifier which is unique over all profiles provisioned to the 1760 same AN partition. This identifier will be used to refer to the 1761 profile when activating it for a given target within a Port 1762 Management message (see Section 4.2). 1764 o The List-Action TLV is described in Section 5.3. The List-Action 1765 TLV(s) provide the content of a newly defined multicast service 1766 profile or modify the existing content. If more than one List- 1767 Action TLV is present, the order of the TLVs may be significant, 1768 since List-Action TLVs are processed in the order in whch they 1769 appear. 1771 5.2. Multicast-Service-Profile-Name TLV 1773 The Multicast-Service-Profile-Name TLV carries the identifier of a 1774 multicast service profile provisioned on the AN. It is illustrated 1775 in Figure 7. 1777 1 2 3 1778 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 1779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1780 |TLV Type = MSP Name | TLV Length | 1781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1782 | Multicast service profile identifier | 1783 | | 1784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1786 Figure 7: Multicast-Service-Profile-Name TLV 1788 The Multicast-Service-Profile-Name TLV has the following fields: 1790 o The Multicast-Service-Profile-Name TLV Type is 0x0018. 1792 o TLV Length: up to 255 octets. 1794 o Multicast service profile identifier: an opaque sequence of octets 1795 identifying a specific multicast service profile. 1797 The identifier could have the form of human-readable text or an 1798 arbitrary binary value, depending on the operator's practices. 1800 5.3. List-Action TLV 1802 The List-Action TLV identifies multicast flows to be added to or 1803 removed from a list of white-, black-, or grey-listed flows. It is 1804 meaningful only in association with a Multicast-Service-Profile-Name 1805 TLV identifying the profile to which the List-Action TLV applies. 1806 Such an association can be achieved by placing both TLVs in the same 1807 base message payload or as embedded TLVs of another TLV such as the 1808 Multicast-Service-Profile. The List-Action TLV is shown in Figure 8. 1810 1 2 3 1811 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 1812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1813 | TLV Type = List-Action TLV | TLV Length | 1814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1815 | Operation | List Type | Reserved | 1816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1817 | Address Family | Number of flow fields | 1818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1819 | Multicast flow fields | 1820 ...... 1821 | | 1822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1823 | Address Family | Number of flow fields | 1824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1825 | Multicast flow fields | 1826 ...... 1827 | | 1828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1830 Figure 8: List-Action TLV 1832 The List-Action TLV contains the following fields: 1834 o The List-Action TLV Type is 0x0021. 1836 o TLV Length: length of the subsequent contents. 1838 o Operation: operation to be performed upon the white, black, or 1839 grey list identified by the List Type field within the profile 1840 identified by the associated Multicast-Service-Profile-Name 1841 embedded TLV. The possible values are: 1843 * Add (0x01): the multicast flow fields are to be added to the 1844 list. 1846 * Delete (0x02): the multicast flow fields are to be removed from 1847 the list. Each multicast flow field in the List-Action MUST 1848 match exactly an existing entry in the list concerned. Thus to 1849 remove part of the range provided by a wildcarded list entry, 1850 it is necessary to remove the entire entry and add back the 1851 remaining partial range(s). 1853 * Replace (0x03): the multicast flow fields replace the existing 1854 contents of the list. 1856 o List Type: the list type being modified by this List-Action. The 1857 possible values are White (0x01), Black (0x02), or Grey (0x03). 1859 o Reserved: a sender MUST set this field to 0x0000. A receiver MUST 1860 ignore the contents of this field. 1862 o Address Family: the IP version of the set of multicast flow fields 1863 that follow, encoded according to [PIMreg]. Possible values are 1864 0x0001 (IPv4) or 0x0002 (IPv6). Either an IPv4 list or an IPv6 1865 list or both MAY be present in the List-Action TLV. 1867 o Number of flow fields: the number of multicast flow fields of the 1868 given address family which follow. 1870 o Multicast flow field: a field identifying one or more multicast 1871 flows. It consists of an 8-bit group address prefix length, an 1872 8-bit source address prefix length, a 0-16 octet group prefix, and 1873 a 0-16 octet source prefix, as shown in Figure 9. 1875 Each multicast flow field refers either to a Source-Specific 1876 Multicast (SSM) channel or to an Any Source Multicast (ASM) group. 1877 The scope of the designation may be broadened to multiple channels or 1878 groups through use of prefix length values smaller than the total 1879 address length for the given address family. Multicast flow fields 1880 MUST be placed consecutively within the embedded TLV without 1881 intervening padding except to round out individual addresses to the 1882 nearest octet boundary. 1884 A multicast flow field consists of two single-octet prefix lengths 1885 followed by zero to two prefix values as shown in Figure 9: 1887 +-+-+-+-+-+-+-+-+ 1888 | Group PrefLen | 1889 +-+-+-+-+-+-+-+-+ 1890 | Source PrefLen| 1891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1892 | Group Prefix (multicast) (0 to 16 octets) | 1893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1894 | Source Prefix (unicast, SSM only) (0 to 16 octets) | 1895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1897 Figure 9: Organization of a Single Multicast Flow Field 1899 The prefix length has its usual meaning. It is the number of most- 1900 significant bits specified within the corresponding prefix. The 1901 prefix length MAY vary from 0 to 32 in the IPv4 sub-list, and from 0 1902 to 128 in the IPv6 sub-list. 1904 A value of 0x00 for either the Group PrefLen (prefix length) or the 1905 Source PrefLen indicates that any value of the corresponding address 1906 will match (wild card). If the value 0x00 is provided for a 1907 particular prefix length, the corresponding prefix MUST be omitted 1908 from the field contents. 1910 The length of a Source or Group Prefix field is equal to (PrefLen + 1911 7)/8 octets, truncated to the nearest integer. Unused bits at the 1912 end of the prefix MUST be set to zeroes. 1914 5.4. Sequence-Number TLV 1916 The Sequence-Number TLV conveys a sequence number of some sort. The 1917 specific meaning of the sequence number is message-specific. Within 1918 this specification, the Sequence-Number TLV is used as a embedded TLV 1919 in a Status-Info TLV, in a Generic Response reporting a failed 1920 command in a Multicast Replication Control or Multicast Admission 1921 Request message. It identifies the sequence number within the 1922 message of the command that failed. 1924 The Sequence-Number TLV has the format shown in Figure 10. 1926 1 2 3 1927 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 1928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1929 |TLV Type = Sequence-Number | TLV Length = 4 | 1930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1931 | Sequence number | 1932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1934 Figure 10: Sequence-Number TLV 1936 The Sequence-Number TLV has the following fields: 1938 o The Sequence-Number TLV Type is 0x0022. 1940 o TLV length is 0x0004. 1942 o Sequence number: the sequence number of a specific entity within a 1943 series, where numbering starts from 1 for the first entity in the 1944 series. Represented as a 32-bit binary number, most significant 1945 bit first. 1947 5.5. Bandwidth-Allocation TLV 1949 The Bandwidth-Allocation TLV is used to indicate the total amount of 1950 video bandwidth delegated to the AN for multicast admission control 1951 for a given access line, in kilobits per second. The TLV has the 1952 format shown in Figure 11. 1954 1 2 3 1955 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 1956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1957 |TLV Type = BW-Allocation | TLV Length = 4 | 1958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1959 | Delegated amount (kbits/s) | 1960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1962 Figure 11: The Bandwidth-Allocation TLV 1964 The Bandwidth-Allocation TLV has the following fields: 1966 o The Bandwidth-Allocation TLV Type is 0x0015. 1968 o TLV length is 4. 1970 o Delegated amount: the bandwidth amount delegated to the AN for 1971 admission of multicast video on a given port, kilobits per second. 1972 Presented as a 32-bit binary value, most significant bit first. 1974 5.6. White-List-CAC TLV 1976 The White-List-CAC TLV is used to indicate that the NAS wishes the AN 1977 to do admission control for white-listed flows. Details on when the 1978 White-List-CAC TLV may be provisioned are specified in Section 6. 1979 The White-List-CAC TLV is illustrated in Figure 12. 1981 1 2 3 1982 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 1983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1984 |TLV Type = White-List-CAC | TLV Length = 0 | 1985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1987 Figure 12: White-List-CAC TLV 1989 The White-List-CAC TLV contains the following fields: 1991 o The White-List-CAC TLV Type is 0x0024. 1993 o TLV length is 0, since the TLV contains no data other than the TLV 1994 header. 1996 5.7. MRepCtl-CAC TLV 1998 The MRepCtl-CAC TLV is used to indicate that the NAS wishes the AN to 1999 do admission control for flows added by the Multicast Replication 2000 Control message. Details on when the MRepCtl-CAC TLV may be 2001 provisioned are specified in Section 6. The MRepCtl-CAC TLV is 2002 illustrated in Figure 13. 2004 1 2 3 2005 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 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2007 |TLV Type = MRepCtl-CAC | TLV Length = 0 | 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2010 Figure 13: MRepCtl-CAC TLV 2012 The MRepCtl-CAC TLV contains the following fields: 2014 o The MRepCtl-CAC TLV Type is 0x0025. 2016 o TLV length is 0, since the TLV contains no data other than the TLV 2017 header. 2019 5.8. Bandwidth-Request TLV 2021 The Bandwidth-Request TLV is used to request an adjustment of the 2022 total amount of video bandwidth allocated to the AN for multicast 2023 admission control for a given line. The "Required amount" field 2024 indicates the minimum adjustment required to meet the request. The 2025 "Preferred amount" field indicates the adjustment the requestor would 2026 prefer to have, if possible. Section 4.5 discusses the required 2027 relationships between the "Required amount", "Preferred amount", and 2028 current values of total bandwidth allocated to the AN. 2030 The Bandwidth-Request TLV has the format shown in Figure 14. 2032 1 2 3 2033 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 2034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2035 |TLV Type = Bandwidth-Request | TLV Length = 8 | 2036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2037 | Required amount (kbits/s) | 2038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2039 | Preferred amount (kbits/s) | 2040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2042 Figure 14: The Bandwidth-Request TLV 2044 The Bandwidth-Request TLV has the following fields: 2046 o The Bandwidth-Request TLV Type is 0x0016. 2048 o The TLV length is 8 octets. 2050 o Required amount: the minimum or maximum amount, depending on 2051 whether the sender is the AN or the NAS respectively, of delegated 2052 video bandwidth that is being requested, in kilobits per second. 2053 Presented as a 32-bit binary value, most significant bit first. 2055 o Preferred amount: the preferred amount of delegated video 2056 bandwidth that is being requested, in kilobits per second. 2057 Presented as a 32-bit binary value, most significant bit first. 2059 5.9. Request-Source-IP TLV 2061 The Request-Source-IP TLV provides the IP address of the entity that 2062 originated a specific request to join or leave a multicast channel. 2063 The TLV is illustrated in Figure 15. 2065 1 2 3 2066 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 2067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2068 | TLV Type = Request-Source-IP | TLV length = 4 or 16 | 2069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2070 | Unicast Address | 2071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2073 Figure 15: Request-Source-IP TLV 2075 The Request-Source-IP TLV contains the following fields: 2077 o The Request-Source-IP TLV Type is 0x0092. 2079 o TLV length is 4 for an IPv4 address or 16 for an IPv6 address. 2081 o Unicast address: IP address of the source of a multicast flow join 2082 request, in network byte order. 2084 5.10. Request-Source-MAC TLV 2086 The Request-Source-MAC TLV provides the MAC address of the entity 2087 that originated a specific request to join or leave a multicast 2088 channel. The TLV is illustrated in Figure 16. 2090 1 2 3 2091 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 2092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2093 |TLV Type=Request-Source-MAC | TLV Length = 6 or 8 | 2094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2095 | | 2096 +-+-+- IEEE MAC Address +-+-+-+ 2097 | | 2098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2100 Figure 16: Request-Source-MAC TLV 2102 The Request-Source-MAC TLV contains the following fields: 2104 o The Request-Source-MAC TLV Type is 0x0093. 2106 o TLV length is either 6 octets (MAC-48 or EUI-48) or 8 octets 2107 (EUI-64). 2109 o IEEE MAC Address: MAC address of the device originating the 2110 request to join a multicast flow. Within the address, bytes and 2111 bits respectively shall be ordered from most to least significant, 2112 consistently with [IEEE48] for MAC-48 and EUI-48, and with 2113 [IEEE64] for EUI-64. 2115 EUI-48 and EUI-64 are registered trademarks of the IEEE. 2117 5.11. Multicast-Flow TLV 2119 The Multicast-Flow TLV specifies a multicast flow in terms of its 2120 multicast group address and, if applicable, its unicast source 2121 address. It is illustrated in Figure 17. 2123 1 2 3 2124 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 2125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2126 |TLV Type = Multicast-Flow | TLV Length | 2127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2128 | Flow Type | Addr Family | Reserved | 2129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2130 | Multicast Group Address | 2131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 2132 | Unicast Source Address (for SSM flows only) | 2133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2135 Figure 17: Multicast-Flow TLV 2137 The Multicast-Flow TLV has the following fields: 2139 o The Multicast-Flow TLV Type is 0x0019. 2141 o TLV Length: ranges from a minimum of 8 (for an ASM IPv4 flow) to 2142 36 (for an IPv6 SSM flow). 2144 o Flow Type: 0x01 for Any Source Multicast (ASM), 0x02 for Source- 2145 Specific Multicast (SSM). 2147 o Addr Family: address family of the multicast source and group 2148 addresses, encoded in accordance with the IANA PIM Address Family 2149 registry ([PIMreg]). 0x01 indicates IPv4, 0x02 indicates IPv6. 2151 o Reserved: MUST be set to 0x0000 by the sender and MUST be ignored 2152 by the receiver. 2154 One possible use for this field in the future is to indicate 2155 the presence of PIM Join attributes attached to the source 2156 address (see [RFC5384]). The applicability of PIM attributes 2157 in the context of ANCP is for further study. 2159 o Multicast Group Address: a multicast group address within the 2160 given address family. The group address MUST always be present. 2162 o Unicast Source Address: unicast address within the given address 2163 family. If the Flow Type is 0x01 (ASM), a source address MUST NOT 2164 be present. If the Flow Type is 0x02 (SSM), a source address MUST 2165 be present. 2167 5.12. Report-Buffering-Time TLV 2169 The Report-Buffering-Time TLV provides the time for which a Committed 2170 Bandwidth Report message must be held with the intention of 2171 accumulating multiple reports of changed committed multicast 2172 bandwidth in one report, to reduce the volume of messages sent to the 2173 NAS. For further information see Section 6.2.2. The TLV is 2174 illustrated in Figure 18. 2176 1 2 3 2177 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 2178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2179 |TLV Type=Report-Buffering-Time | TLV Length = 4 | 2180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2181 | Buffering Time (ms) | 2182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2184 Figure 18: Report-Buffering-Time TLV 2186 The Report-Buffering-Time TLV contains the following fields: 2188 o The Report-Buffering-Time TLV Type is 0x0094. 2190 o TLV length is 4 octets. 2192 o Buffering Time is a 32-bit unsigned integer containing a time 2193 value in ms. 2195 5.13. Committed-Bandwidth TLV 2197 The Committed-Bandwidth TLV identifies an access line and provides 2198 the current amount of multicast bandwidth that the AN has committed 2199 to it. The TLV is illustrated in Figure 19. 2201 1 2 3 2202 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 2203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2204 |TLV Type=Committed-Bandwidth | TLV Length (variable) | 2205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2206 | Committed Multicast Bandwidth (kbits/s) | 2207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2208 | | 2209 +-+-+- Target TLV +-+-+-+ 2210 | | 2211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2213 Figure 19: Committed-Bandwidth TLV 2215 The Committed-Bandwidth TLV contains the following fields: 2217 o The Committed-Bandwidth TLV Type is 0x0095. 2219 o TLV length is 4 octets plus the length of the Target TLV including 2220 its header and any padding. 2222 o Committed Multicast Bandwidth is a 32-bit unsigned integer 2223 providing a bandwidth amount in kbits/s. 2225 o The Target TLV identifies the access line to which this amount of 2226 multicast bandwidth is currently committed. 2228 6. Multicast Capabilities 2230 Section 3.5 of [RFC6320] defines a capability negotiation mechanism 2231 as well as a number of capabilities. This section defines five new 2232 capabilities in support of different modes of multicast operation: 2234 o NAS-initiated replication (capability type 3); 2236 o committed multicast bandwidth reporting (capability type 5); 2238 o conditional access with white and black lists (capability type 6); 2240 o conditional access with grey lists (capability type 7); 2242 o bandwidth delegation (capability type 8). 2244 The "Capability Data" field within the Capability TLV for all of 2245 these capabilities is empty. All of these capabilities are 2246 independent of the access technology. 2248 The remainder of this section consists of three sub-sections. 2249 Section 6.1 specifies the protocol elements that must be implemented 2250 in order to support each capability. Section 6.2 specifies the 2251 procedures that apply to each capability on its own. Section 6.3 2252 specifies how the capabilities interact if more than one multicast 2253 capability is included in the set of capabilities negotiated between 2254 the AN and the NAS. 2256 Note that if a request contains content that is not supported 2257 (according to the tables in Section 6.1) by the negotiated set of 2258 multicast capabilities, the appropriate response is to return a 2259 Generic Response message indicating Failure (0x4) with an appropriate 2260 code value. The body of the message MUST contain a Status-Info TLV. 2261 See Sections 4.2 and 4.5 in [RFC6320] for more details. 2263 6.1. Required Protocol Support 2265 This section specifies the protocol elements that MUST be implemented 2266 to support each of the four multicast capabilities. Support of 2267 multiple multicast capabilities requires implementation of the union 2268 of the sets of protocol elements applying to each of the individual 2269 capabilities in the supported set. 2271 In addition to the elements listed below, implementation of the 2272 Target TLV (Section 4.3 of [RFC6320]) is REQUIRED for all of the 2273 capabilities specified in this document. 2275 6.1.1. Protocol Requirements For NAS-Initiated Replication 2277 Table 1 specifies the protocol elements within Section 4 and 2278 Section 5 that MUST be implemented to support the NAS-initiated 2279 replication multicast capability. Additionally, implementation of 2280 the Multicast Replication Control message requires implementation of 2281 the Command TLV (Section 4.4 of [RFC6320] with additional details in 2282 Section 4.3 of this document). 2284 +--------------+----------------------------------------------------+ 2285 | Reference | Protocol Element | 2286 +--------------+----------------------------------------------------+ 2287 | Section 4.1 | Provisioning message with MRepCtl-CAC TLV | 2288 | | | 2289 | Section 4.2 | Port Management message with Bandwidth-Allocation | 2290 | | TLV. | 2291 | | | 2292 | Section 4.3 | Multicast Replication Control message | 2293 | | | 2294 | Section 4.9 | Multicast Flow Query Request and Response messages | 2295 | | | 2296 | Section 5.4 | Sequence Number TLV | 2297 | | | 2298 | Section 5.5 | Bandwidth-Allocation TLV | 2299 | | | 2300 | Section 5.7 | MRepCtl-CAC TLV | 2301 | | | 2302 | Section 5.11 | Multicast-Flow TLV | 2303 +--------------+----------------------------------------------------+ 2305 Table 1: Protocol Requirements For NAS-Initiated Replication 2307 6.1.2. Protocol Requirements For Committed Multicast Bandwidth 2308 Reporting 2310 Table 2 specifies the protocol elements within Section 4 and 2311 Section 5 that MUST be implemented to support the committed multicast 2312 bandwidth reporting capability. 2314 +--------------+----------------------------------------------------+ 2315 | Reference | Protocol Element | 2316 +--------------+----------------------------------------------------+ 2317 | Section 4.1 | Provisioning message with Report-Buffering-Time | 2318 | | TLV | 2319 | | | 2320 | Section 4.10 | Committed Bandwidth Report message | 2321 | | | 2322 | Section 4.9 | Multicast Flow Query Request and Response messages | 2323 | | | 2324 | Section 5.12 | Report-Buffering-Timer TLV | 2325 | | | 2326 | Section 5.13 | Committed-Bandwidth TLV | 2327 | | | 2328 | Section 5.11 | Multicast-Flow TLV | 2329 +--------------+----------------------------------------------------+ 2331 Table 2: Protocol Requirements For Committed Multicast Bandwidth 2332 Reporting 2334 6.1.3. Protocol Requirements For Conditional Access With White and 2335 Black Lists 2337 Table 3 specifies the protocol elements within Section 4 and 2338 Section 5 that MUST be implemented to support the conditional access 2339 with white and black lists multicast capability. 2341 +--------------+----------------------------------------------------+ 2342 | Reference | Protocol Element | 2343 +--------------+----------------------------------------------------+ 2344 | Section 4.1 | Provisioning message with | 2345 | | Multicast-Service-Profile TLV, white and black | 2346 | | lists only, and White-List-CAC TLV | 2347 | | | 2348 | Section 4.2 | Port Management message with | 2349 | | Multicast-Service-Profile-Name and | 2350 | | Bandwidth-Allocation TLVs. | 2351 | | | 2352 | Section 4.9 | Multicast Flow Query Request and Response messages | 2353 | | | 2354 | Section 5.1 | Multicast-Service-Profile TLV | 2355 | | | 2356 | Section 5.2 | Multicast-Service-Profile-Name TLV | 2357 | | | 2358 | Section 5.3 | List-Action TLV, white and black lists only | 2359 | | | 2360 | Section 5.5 | Bandwidth-Allocation TLV | 2361 | | | 2362 | Section 5.6 | White-List-CAC TLV | 2363 | | | 2364 | Section 5.11 | Multicast-Flow TLV | 2365 +--------------+----------------------------------------------------+ 2367 Table 3: Protocol Requirements For Conditional Access with White and 2368 Black Lists 2370 6.1.4. Protocol Requirements For Conditional Access With Grey Lists 2372 Table 4 specifies the protocol elements within Section 4 and 2373 Section 5 that MUST be implemented to support the conditional access 2374 with grey lists multicast capability. Additionally, implementation 2375 of the Multicast Replication Control message requires implementation 2376 of the Command TLV (Section 4.4 of [RFC6320] with additional details 2377 in Section 4.3 of this document). 2379 +--------------+----------------------------------------------------+ 2380 | Reference | Protocol Element | 2381 +--------------+----------------------------------------------------+ 2382 | Section 4.1 | Provisioning message with | 2383 | | Multicast-Service-Profile TLV, grey lists only, | 2384 | | and MRepCtl-CAC TLV | 2385 | | | 2386 | Section 4.2 | Port Management message with | 2387 | | Multicast-Service-Profile-Name and | 2388 | | Bandwidth-Allocation TLVs. | 2389 | | | 2390 | Section 4.3 | Multicast Replication Control message | 2391 | | | 2392 | Section 4.4 | Multicast Admission Control Message | 2393 | | | 2394 | Section 4.9 | Multicast Flow Query Request and Response messages | 2395 | | | 2396 | Section 5.1 | Multicast-Service-Profile TLV, grey lists only | 2397 | | | 2398 | Section 5.2 | Multicast-Service-Profile-Name TLV | 2399 | | | 2400 | Section 5.3 | List-Action TLV, grey lists only | 2401 | | | 2402 | Section 5.4 | Sequence Number TLV | 2403 | | | 2404 | Section 5.5 | Bandwidth-Allocation TLV | 2405 | | | 2406 | Section 5.7 | MRepCtl-CAC TLV | 2407 | | | 2408 | Section 5.9 | Request-Source-IP TLV | 2409 | | | 2410 | Section 5.10 | Request-Source-MAC TLV | 2411 | | | 2412 | Section 5.11 | Multicast-Flow TLV | 2413 +--------------+----------------------------------------------------+ 2415 Table 4: Protocol Requirements For Conditional Access with Grey Lists 2417 6.1.5. Protocol Requirements For Delegated Bandwidth 2419 Table 5 specifies the protocol elements within Section 4 and 2420 Section 5 that MUST be implemented to support the delegated bandwidth 2421 multicast capability. 2423 +--------------+----------------------------------------------------+ 2424 | Reference | Protocol Element | 2425 +--------------+----------------------------------------------------+ 2426 | Section 4.2 | Port Management message with Bandwidth-Allocation | 2427 | | TLV. | 2428 | | | 2429 | Section 4.5 | Bandwidth Reallocation Request Message | 2430 | | | 2431 | Section 4.6 | Bandwidth Transfer Message | 2432 | | | 2433 | Section 4.7 | Delegated Bandwidth Query Request Message | 2434 | | | 2435 | Section 4.8 | Delegated Bandwidth Query Response Message | 2436 | | | 2437 | Section 4.9 | Multicast Flow Query Request and Response messages | 2438 | | | 2439 | Section 5.5 | Bandwidth-Allocation TLV | 2440 | | | 2441 | Section 5.8 | Bandwidth-Request TLV | 2442 | | | 2443 | Section 5.11 | Multicast-Flow TLV | 2444 +--------------+----------------------------------------------------+ 2446 Table 5: Protocol Requirements For Delegated Bandwidth 2448 6.2. Capability-Specific Procedures for Providing Multicast Service 2450 This section describes multicast service procedures for each 2451 capability as if it were the only multicast capability within the 2452 negotiated set. Procedures involving combinations of multicast 2453 capabilities are described in Section 6.3. 2455 The use of the Multicast Flow Query Request and Response messages to 2456 determine the association between multicast flows and ports is common 2457 to all multicast capabilities. No additional text is required here, 2458 beyond that already given in Section 4.9 to describe the use of those 2459 messages. 2461 6.2.1. Procedures For NAS-Initiated Replication 2463 NAS-initiated replication may be negotiated to support a mode of 2464 operation where IGMP/MLD requests are terminated on the NAS. 2465 Alternatively, it may be negotiated to allow the NAS to respond to 2466 requests sent by other means (e.g., through application signalling) 2467 that require the replication of multicast channels to a given access 2468 line. 2470 6.2.1.1. Provisioning 2472 The NAS MAY perform admission control for NAS-initiated replication. 2473 In this case, it MUST NOT include the MRepCtl-CAC TLV in a 2474 Provisioning message sent to the AN. Alternatively, the NAS MAY 2475 enable admission control at the AN for NAS-initiated replication. To 2476 do this, it MUST include the MRepCtl-CAC TLV in a Provisioning 2477 message sent to the AN and it MUST also include a Bandwidth- 2478 Allocation TLV in a Port Management message for each access line. 2480 6.2.1.2. Multicast Service Procedures 2482 The procedures associated with NAS-initiated replication are 2483 straightforward. To initiate replication, the NAS MUST send a 2484 Multicast Replication Control message to the AN, containing one or 2485 more commands adding flows, as described in Section 4.3.1. To 2486 terminate replication the NAS MUST send a Multicast Replication 2487 Control message where the commands delete instead of adding the 2488 flows. The AN acts upon these messages as specified in 2489 Section 4.3.2. 2491 6.2.2. Procedures For Committed Bandwidth Reporting 2493 Committed bandwidth reporting may be negotiated if the NAS requires 2494 current knowledge of the amount of multicast bandwidth committed to 2495 each access line and cannot obtain this information by other means. 2497 6.2.2.1. Provisioning 2499 The default buffering time when committed bandwidth reporting is 2500 enabled is zero (immediate reporting). To change this, the NAS MAY 2501 send an instance of the Report-Buffering-Time TLV containing a non- 2502 zero time value to the AN in a Provisioning message. If the NAS 2503 subsequently wishes to change the buffering time again, it MAY do so 2504 in another Provisioning message. 2506 6.2.2.2. Multicast Service Procedures 2508 If the buffering time for committed bandwidth reporting is zero, the 2509 AN MUST send a Committed Bandwidth Report message to the NAS each 2510 time the amount of multicast bandwidth committed to any access line 2511 under its control changes. 2513 If a non-zero value is provided in the Report-Buffering-Time TLV, the 2514 AN at any given moment is in one of two states: not-buffering, or 2515 buffering. The AN enters buffering state if it is in not-buffering 2516 state and the multicast bandwidth amount committed to some access 2517 line changes. It leaves buffering state when the AN sends a 2518 Committed Bandwidth Report. 2520 Upon entry to the buffering state, the AN MUST start a buffering 2521 timer and create a Committed Bandwidth Report message containing a 2522 Committed-Bandwidth TLV for the triggering access line, but MUST NOT 2523 send it. If a multicast bandwidth change occurs for another access 2524 line, the AN MUST add a new Committed-Bandwidth TLV to the message 2525 for that additional line. If a multicast bandwidth change occurs for 2526 a line for which a Committed-Bandwidth TLV is already present in the 2527 buffered report, the AN MUST update the corresponding Committed- 2528 Bandwidth TLV to contain the new bandwidth value, rather than adding 2529 another Committed-Bandwidth TLV for the same access line. 2531 The buffering timer expires after the period provided by the Report- 2532 Buffering-Time TLV. When it expires, the AN MUST send the Committed 2533 Bandwidth Report message that it has been accumulating to the NAS. 2534 Exceptionally, the AN MAY choose to send the message before the timer 2535 expires, in which case it MUST clear the buffering timer when the 2536 message is sent. In either case, the AN enters the not-buffering 2537 state as a result. 2539 Report buffering implies that NAS reaction to changes in multicast 2540 bandwidth usage is delayed by the amount of the buffering period. 2541 The choice of buffering period must take this into consideration. 2543 6.2.3. Procedures For Conditional Access With Black and White Lists 2545 6.2.3.1. Provisioning 2547 The NAS provisions named multicast service profiles containing white 2548 and black lists on the AN using the Provisioning message containing 2549 one or more Multicast-Service-Profile TLVs. The NAS MAY update the 2550 contents of these profiles from time to time as required, by sending 2551 additional Provisioning messages with Multicast-Service-Profile TLVs 2552 containing incremental modifications to the existing white and black 2553 lists or replacements for them. 2555 The NAS assigns a specific multicast service profile to an individual 2556 access line using the Port Management message containing a Multicast- 2557 Service-Profile-Name TLV. The NAS MAY change the multicast service 2558 profile for a given access line at any time by sending a Port 2559 Management message identifying a new multicast service profile. 2561 The NAS MAY choose to enable admission control at the AN for white- 2562 listed flows. To do this, it MUST send a Provisioning message as 2563 described in Section 4.1, which includes the White-List-CAC TLV and 2564 it MUST provide a multicast bandwidth allocation for each access line 2565 by including a Bandwidth-Allocation TLV in a Port Management message. 2567 6.2.3.2. Multicast Service Procedures 2569 The conditional access with white and black lists capability assumes 2570 that IGMP/MLD requests are terminated on the AN. When the AN 2571 receives a "join" request, it MUST check to see whether the requested 2572 flow is white-listed or black-listed as described below. Requests 2573 for black-listed flows MUST be discarded. If the NAS has enabled 2574 admission control on the AN as described in the previous section, but 2575 a white-listed flow would cause the amount of committed multicast 2576 bandwidth to exceed the provisioned limit, the request MUST be 2577 discarded. The AN replicates flows passing these checks to the 2578 access line. 2580 To determine if a requested flow is white-listed, the AN searches for 2581 a best match to the flow in the applicable multicast service profile. 2582 Matching is done on the prefixes specified in the profile, ignoring 2583 the address bits of lower order than those in the prefix. 2585 If the requested multicast flow matches multiple lists associated 2586 with the access line, then the most specific match will be considered 2587 by the AN. If the most specific match occurs in multiple lists, the 2588 black list entry takes precedence over the white list. In this 2589 context, the most specific match is defined as: 2591 o first, most specific match (longest prefix length) on the 2592 multicast group address (i.e., on G of ) 2594 o then, most specific match (longest prefix length) on the unicast 2595 source address (i.e. on S of ) 2597 If the requested multicast flow is not part of any list, the join 2598 message SHOULD be discarded by the AN. This default behavior can 2599 easily be changed by means of a "catch-all" statement in the white 2600 list. For instance, adding () in the white List would make 2601 the default behavior to accept join messages for a multicast flow 2602 that has no other match on any list. 2604 When the AN receives a "leave" request, it terminates replication of 2605 the multicast flow. 2607 If the AN receives a Provisioning message which updates an existing 2608 multicast service profile, the AN MUST review the status of active 2609 flows on all ports to which the updated profile is currently 2610 assigned. Similarly, if a Port Management message assigns a new 2611 multicast service profile to a given port, the AN MUST review all 2612 active flows on that port. If the most specific match for any flow 2613 is a black list entry, the flow MUST be terminated immediately. If 2614 any of the remaining flows do not match an entry in the white list, 2615 they also MUST be terminated immediately. White listed flows MUST be 2616 allowed to continue. 2618 6.2.4. Procedures For Conditional Access With Grey Lists 2620 6.2.4.1. Provisioning 2622 The NAS provisions named multicast service profiles containing grey 2623 lists on the AN using the Provisioning message containing one or more 2624 Multicast-Service-Profile TLVs. The NAS MAY update the contents of 2625 these profiles from time to time as required, by sending additional 2626 Provisioning messages with Multicast-Service-Profile TLVs containing 2627 incremental modifications to the existing grey lists or replacements 2628 for them. 2630 The NAS assigns a specific multicast service profile to an individual 2631 access line using the Port Management message containing a Multicast- 2632 Service-Profile-Name TLV. The NAS MAY change profiles on the line by 2633 sending a subsequent Port Management message identifying a new 2634 profile. 2636 The NAS MAY perform admission control for grey-listed flows. In that 2637 case, the NAS MUST NOT include the MRepCtl-CAC TLV in a Provisioning 2638 message sent to the AN. Alternatively, the NAS MAY enable admission 2639 control at the AN for grey-listed flows. To do this, it MUST include 2640 the MRepCtl-CAC TLV in a Provisioning message sent to the AN and MUST 2641 also provide a Bandwidth-Allocation TLV in a Port Management message 2642 for each access line. 2644 6.2.4.2. Multicast Service Procedures 2646 The conditional access with grey lists capability assumes that IGMP/ 2647 MLD requests are terminated on the AN. When the AN receives a "join" 2648 request, it MUST determine whether there is a match to the requested 2649 flow in the grey list of the multicast service profile provisioned 2650 against the given access line. If there is no match, the request is 2651 discarded. Otherwise, the AN MUST send a Multicast Admission Control 2652 message to the NAS with content identifying the access line and the 2653 multicast flow to be added. As indicated in Section 4.4, the AN MAY 2654 add information identifying the requestor by IP address and/or MAC 2655 address. 2657 If the NAS decides to enable the flow, it MUST send a Multicast 2658 Replication Control request to the AN to replicate the flow to the 2659 access line with the Result field set to Nack (0x1), as described in 2660 Section 4.3.1. 2662 When the AN receives the Multicast Replication Control request, it 2663 performs admission control if admission control has been enabled as 2664 described in the previous section. If admitting the flow would cause 2665 the committed multicast bandwidth at the access line to exceed the 2666 provisioned limit, the AN reports an error to the NAS as described in 2667 Section 4.3.2. Otherwise it replicates the multicast flow as 2668 requested. 2670 If the NAS decides not to permit the flow, it MAY send a Multicast 2671 Replication Control message in response to the Multicast Admission 2672 Control message to allow the AN to update its internal records. The 2673 content of this message is described in Section 4.4.2. 2675 When the AN receives a "leave" request, it MUST terminate replication 2676 of the flow to the access line. It MUST then send a Multicast 2677 Admission Control message to the NAS indicating the deletion. The 2678 NAS updates its internal records but MUST NOT respond to the message. 2680 If the AN receives a Provisioning message which updates an existing 2681 multicast service profile, the AN MUST review the status of active 2682 flows on all ports to which the updated profile has been assigned. 2683 Similarly, if a Port Management message that assigns a new profile to 2684 a given port, the AN MUST review all active flows on that port. In 2685 either case, if any flow does not match an entry in the grey list, it 2686 MUST be terminated immediately. 2688 6.2.5. Procedures For Delegated Bandwidth 2690 6.2.5.1. Provisioning 2692 The NAS SHOULD provision an initial amount of delegated multicast 2693 bandwidth for each access line using the Port Management message 2694 containing the Bandwidth-Allocation TLV. 2696 If it fails to do so and a value has not been provisioned on the 2697 AN by other means, the AN will be forced to request a bandwidth 2698 allocation as soon as it receives a "join" request. 2700 The NAS MAY at any time force an update of the amount of delegated 2701 bandwidth by the same means. 2703 6.2.5.2. Multicast Service Procedures 2705 The delegated bandwidth capability assumes that IGMP/MLD requests are 2706 terminated on the AN. When the AN receives a "join" request, it 2707 checks whether it has sufficient remaining uncommitted multicast 2708 bandwidth on the access line to accommodate the new multicast flow. 2709 If not, it MAY send a request to the NAS for an increased allocation 2710 of delegated bandwidth, using the Bandwidth Reallocation Request 2711 message. The NAS MUST return a Bandwidth Transfer message indicating 2712 whether it has granted the request, and if so, what is the new amount 2713 of delegated bandwidth. 2715 If the AN has sufficient uncommitted multicast capacity to admit the 2716 request, either originally or as the result of a successful request 2717 to the NAS, it replicates the requested flow to the access line. 2718 Otherwise it discards the request. 2720 When the AN receives a "leave" request for an active flow, it ceases 2721 replication. 2723 The NAS or AN MAY at some point detect that their respective views of 2724 the amount of delegated bandwidth are inconsistent. If so, they can 2725 recover using procedures described in Section 4.5 and Section 4.6. 2726 As a further aid to synchronization, either the NAS or the AN MAY 2727 from time to time check the peer's view of the amount of delegated 2728 bandwidth using the Delegated Bandwidth Query message. 2730 The NAS or AN MAY at any time release bandwidth to the peer using an 2731 autonomous Bandwidth Transfer message. The contents of this message 2732 are described in Section 4.6. 2734 6.3. Combinations of Multicast Capabilities 2736 6.3.1. Combination of Conditional Access With White and Black Lists and 2737 Conditional Access With Grey Lists 2739 If conditional access with white and black lists is combined with 2740 conditional access with grey lists, provisioning of the multicast 2741 service profiles is as described in Section 6.2.3.1 except that 2742 multicast service profiles will also include grey lists. Admission 2743 control is enabled independently on the AN for white lists by 2744 including the White-List-CAC TLV in the Provisioning message and for 2745 grey lists by including the MRepCtl-CAC TLV in the Provisioning 2746 message. The Bandwidth-Allocation TLV provisions an amount that 2747 applies to both white- and grey- listed flows if admission control is 2748 enabled for both. 2750 With regard to multicast service procedures, one point of difference 2751 from the individual capabilities must be noted. This is an 2752 interaction during the profile matching procedure. The AN MUST seek 2753 the best match amongst multiple lists as described in 2754 Section 6.2.3.2. However, if there are multiple matches of equal 2755 precision, the order of priority is black list first, grey list 2756 second, and white list last. 2758 Once profile matching has been completed, processing of a "join" 2759 request is as described in Section 6.2.3.2 for white or black listed 2760 flows or Section 6.2.4.2 for grey listed flows. Requests that do not 2761 match any list SHOULD be discarded. 2763 When the AN receives a "leave" request, it MUST terminate replication 2764 of the flow to the access line. If the flow was grey-listed, the AN 2765 MUST then send a Multicast Admission Control message to the NAS 2766 indicating the deletion. Thus the AN needs to retain the fact that 2767 the flow was grey-listed for the life of the flow. 2769 If the AN receives a Provisioning message which updates an existing 2770 multicast service profile, the AN MUST review the status of active 2771 flows on all ports to which the updated profile is currently 2772 assigned. Similarly, if a Port Management message assigns a new 2773 multicast service profile to a given port, the AN MUST review all 2774 active flows on that port. If any flow has its most specific match 2775 in a black list entry, it MUST be terminated immediately. If any of 2776 the remaining flows do not match an entry in the white or grey list, 2777 they MUST also be terminated immediately. Finally, if any remaining 2778 flows were originally admitted because they were white-listed, but 2779 after the change they are grey-listed, the AN MUST generate a 2780 Multicast Flow Query response message autonomously as if it were 2781 responding to a Multicast Flow Query request, listing all such flows. 2782 These flows MUST be allowed to continue until the NAS or the 2783 subscriber terminates them. Flows with their most specific match in 2784 the white list MUST be allowed to continue. 2786 The autonomously-generated Multicast Flow Query response message MUST 2787 be formatted as if it were a successful response to a request 2788 containing no Target and no Multicast-Flow TLV, as described in 2789 Section 4.9.2, with the exception that the Transaction-Id MUST be set 2790 to all zeroes. 2792 6.3.2. Combination of Conditional Access With Delegated Bandwidth 2794 The provisioning and bandwidth management procedures of Section 6.2.5 2795 apply in addition to the procedures in Section 6.2.3, Section 6.2.4, 2796 or Section 6.3.1 as applicable. Admission control follows the rules 2797 for conditional access in terms of matching flows against white and 2798 black and/or grey lists and performing or not performing bandwidth 2799 checks at the AN, but the amount of bandwidth used by the AN to 2800 perform admission control is negotiable as described in 2801 Section 6.2.5.2. 2803 6.3.3. Combination of NAS-Initiated Replication with Other Capabilities 2805 NAS-initiated replication can coexist with the other capabilities, 2806 but some means must exist to prevent double replication of flows. 2808 The simplest way to do this is to terminate all IGMP/MLD requests on 2809 the AN, so that NAS-initiated replication is stimulated only by 2810 signalling through other channels. Other arrangements are possible, 2811 but need not be discussed here. 2813 Assuming the necessary separation of responsibilities, the only point 2814 of interaction between NAS-initiated replication and the other 2815 multicast capabilities is in the area of admission control. 2816 Specifically, if the AN is to do admission control for flows added by 2817 Multicast Replication Control messages, regardless of whether they 2818 are part of NAS-initiated replication or grey list multicast service 2819 processing, the NAS includes the MRepCtl-CAC TLV in a Provisioning 2820 message and the Bandwidth-Allocation TLV in a Port Management 2821 message. If instead the NAS will do admission control for flows 2822 added by Multicast Replication Control messages, regardless of 2823 whether they are part of NAS-initiated replication or grey list 2824 multicast service processing, it does not send the MRepCtl-CAC TLV in 2825 a Provisioning messages to the AN. The NAS can independently enable 2826 Admission Control for white flows on the AN by including the White- 2827 List-CAC TLV in the Provisioning message. 2829 6.3.4. Combinations of Committed Bandwidth Reporting with Other 2830 Multicast Capabilities 2832 Committed bandwidth reporting can take place independently of which 2833 other multicast capabilities have been negotiated. However, some 2834 combinations do not make sense because of redundancy. In particular, 2835 the NAS obtains the same information that committed bandwidth 2836 reporting gives if the only other capabilities operating are NAS- 2837 initiated replication and/or conditional access with grey lists. 2839 7. Security Considerations 2841 The security considerations of ANCP are discussed in [RFC6320] and in 2842 [RFC5713]. Multicast does not in principle introduce any new 2843 security considerations, although it does increase the attractiveness 2844 of the ANCP protocol as a means of denial of service (e.g., through 2845 direction of multicast streams onto the target) or theft of service. 2847 8. IANA Considerations 2849 IANA NOTE: Please replace XXXX with the RFC number of this document. 2851 This document defines the following additional values within the ANCP 2852 Message Type Name Space registry: 2854 +--------------+--------------------------------+-----------+ 2855 | Message Type | Message Name | Reference | 2856 +--------------+--------------------------------+-----------+ 2857 | 144 | Multicast Replication Control | RFC XXXX | 2858 | | | | 2859 | 145 | Multicast Admission Control | RFC XXXX | 2860 | | | | 2861 | 146 | Bandwidth Reallocation Request | RFC XXXX | 2862 | | | | 2863 | 147 | Bandwidth Transfer | RFC XXXX | 2864 | | | | 2865 | 148 | Delegated Bandwidth Query | RFC XXXX | 2866 | | | | 2867 | 149 | Multicast Flow Query | RFC XXXX | 2868 | | | | 2869 | 150 | Committed Bandwidth Report | RFC XXXX | 2870 +--------------+--------------------------------+-----------+ 2872 This document defines the following additional values for the ANCP 2873 Result Code registry: 2875 +------------+------------------------------------------+-----------+ 2876 | Result | One-Line Description | Reference | 2877 | Code | | | 2878 +------------+------------------------------------------+-----------+ 2879 | 0x64 | Command error. | RFC XXXX | 2880 | | | | 2881 | 0x65 | Invalid flow address. | RFC XXXX | 2882 | | | | 2883 | 0x66 | Multicast flow does not exist. | RFC XXXX | 2884 | | | | 2885 | 0x67 | Invalid preferred bandwidth amount. | RFC XXXX | 2886 | | | | 2887 | 0x68 | Inconsistent views of delegated | RFC XXXX | 2888 | | bandwidth amount. | | 2889 | | | | 2890 | 0x69 | Bandwidth request conflict. | RFC XXXX | 2891 +------------+------------------------------------------+-----------+ 2893 This document defines the following additional values for the ANCP 2894 Command Code registry: 2896 +----------------+--------------------------------------+-----------+ 2897 | Command Code | Command Code Directive Name | Reference | 2898 | Value | | | 2899 +----------------+--------------------------------------+-----------+ 2900 | 1 | Add | RFC XXXX | 2901 | | | | 2902 | 2 | Delete | RFC XXXX | 2903 | | | | 2904 | 3 | Delete All | RFC XXXX | 2905 | | | | 2906 | 4 | Admission Control Reject | RFC XXXX | 2907 | | | | 2908 | 5 | Conditional Access Reject | RFC XXXX | 2909 | | | | 2910 | 6 | Admission Control and Conditional | RFC XXXX | 2911 | | Access Reject | | 2912 +----------------+--------------------------------------+-----------+ 2914 This document defines the following additional values within the ANCP 2915 TLV Type Registry: 2917 +-----------+--------------------------------+-----------+ 2918 | Type Code | TLV Name | Reference | 2919 +-----------+--------------------------------+-----------+ 2920 | 0x0013 | Multicast-Service-Profile | RFC XXXX | 2921 | | | | 2922 | 0x0015 | Bandwidth-Allocation | RFC XXXX | 2923 | | | | 2924 | 0x0016 | Bandwidth-Request | RFC XXXX | 2925 | | | | 2926 | 0x0018 | Multicast-Service-Profile-Name | RFC XXXX | 2927 | | | | 2928 | 0x0019 | Multicast-Flow | RFC XXXX | 2929 | | | | 2930 | 0x0021 | List-Action | RFC XXXX | 2931 | | | | 2932 | 0x0022 | Sequence-Number | RFC XXXX | 2933 | | | | 2934 | 0x0024 | White-List-CAC | RFC XXXX | 2935 | | | | 2936 | 0x0025 | MRepCtl-CAC | RFC XXXX | 2937 | | | | 2938 | 0x0092 | Request-Source-IP | RFC XXXX | 2939 | | | | 2940 | 0x0093 | Request-Source-MAC | RFC XXXX | 2941 | | | | 2942 | 0x0094 | Report-Buffering-Time | RFC XXXX | 2943 | | | | 2944 | 0x0095 | Committed-Bandwidth | RFC XXXX | 2945 +-----------+--------------------------------+-----------+ 2947 This document defines the following additional values for the ANCP 2948 Capability Type registry: 2950 +-------+-------------------------+--------+------------+-----------+ 2951 | Value | Capability Type Name | Tech | Capability | Reference | 2952 | | | Type | Data? | | 2953 +-------+-------------------------+--------+------------+-----------+ 2954 | 3 | NAS-Initiated | 0 | No | RFC XXXX | 2955 | | Replication | | | | 2956 | | | | | | 2957 | 5 | Committed Bandwidth | 0 | No | RFC XXXX | 2958 | | Reporting | | | | 2959 | | | | | | 2960 | 6 | Conditional Access With | 0 | No | RFC XXXX | 2961 | | White and Black Lists | | | | 2962 | | | | | | 2963 | 7 | Conditional Access With | 0 | No | RFC XXXX | 2964 | | Grey Lists | | | | 2965 | 8 | Bandwidth Delegation | 0 | No | RFC XXXX | 2966 +-------+-------------------------+--------+------------+-----------+ 2968 9. Acknowledgements 2970 The authors would like to acknowledge Wojciech Dec for providing 2971 useful input to this document, Robert Rennison for his help in 2972 shaping the definition of the Multicast-Service-Profile TLV, Shridhar 2973 Rao for his comments and suggestions and Aniruddha A for his proposal 2974 that formed the base of the Multicast Flow Reporting solution. 2975 Philippe Champagne, Sanjay Wadhwa and Stefaan De Cnodder provided 2976 substantial contributions on the solution for the NAS initiated 2977 multicast control use case. Kristian Poscic provided the committed 2978 bandwidth reporting use case. 2980 10. References 2982 10.1. Normative References 2984 [IEEE48] IEEE, "http://standards.ieee.org/regauth/oui/tutorials/ 2985 EUI48.html", 2010. 2987 [IEEE64] IEEE, "http://standards.ieee.org/regauth/oui/tutorials/ 2988 EUI64.html", 2010. 2990 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2991 Requirement Levels", BCP 14, RFC 2119, March 1997. 2993 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 2994 Listener Discovery (MLD) for IPv6", RFC 2710, 2995 October 1999. 2997 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 2998 Thyagarajan, "Internet Group Management Protocol, Version 2999 3", RFC 3376, October 2002. 3001 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 3002 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 3004 [RFC6320] Wadhwa, S., Moisand, J., Haag, T., Voigt, N., and T. 3005 Taylor, "Protocol for Access Node Control Mechanism in 3006 Broadband Networks", RFC 6320, October 2011. 3008 10.2. Informative References 3010 [I-D.morin-mboned-igmpmld-error-feedback] 3011 Morin, T. and B. Haberman, "IGMP/MLD Error Feedback", 3012 draft-morin-mboned-igmpmld-error-feedback-02 (work in 3013 progress), November 2008. 3015 [PIMreg] IANA, "http://www.iana.org/assignments/pim-parameters/pim- 3016 parameters.xhtml", 2005. 3018 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 3019 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 3020 Protocol Specification (Revised)", RFC 4601, August 2006. 3022 [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol 3023 Independent Multicast (PIM) Join Attribute Format", 3024 RFC 5384, November 2008. 3026 [RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security 3027 Threats and Security Requirements for the Access Node 3028 Control Protocol (ANCP)", RFC 5713, January 2010. 3030 [RFC5851] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. 3031 Wadhwa, "Framework and Requirements for an Access Node 3032 Control Mechanism in Broadband Multi-Service Networks", 3033 RFC 5851, May 2010. 3035 Appendix A. Example of Messages and Message Flows 3037 This appendix provides an example in which most of the possible 3038 message flows for multicast control are illustrated. This appendix 3039 is for informational purposes only. In case of discrepancy with text 3040 of the body of this document, the text in the body of the document is 3041 to be considered as the normative text. 3043 Assume the following, for a given access port: 3045 o The basic subscribed service is white-listed. The AN will be 3046 responsible for admission control for this service. 3048 o Some premium services are available, but requests for these 3049 services must be referred to the policy server for proper credit 3050 processing. For this reason they are grey-listed. The NAS will 3051 be responsible for admission control for these services. 3053 o The subscriber has asked that certain services be blocked so that 3054 his children cannot view them. These services are black-listed. 3056 o All of the above services are Source-Specific Multicast (SSM). In 3057 addition, by means which bypass the AN, the subscriber can signal 3058 intent to join an on-line game service which is Any Source 3059 Multicast (ASM). The NAS is responsible for admission control for 3060 this service. 3062 o Bandwidth delegation is in effect to share video bandwidth between 3063 the AN and the NAS. 3065 The stated conditions require the use of four of the five 3066 capabilities specified in this memo. 3068 A.1. Provisioning Phase 3070 Assume that capability negotiation has been completed between the AN 3071 and NAS and that the set of negotiated capabilities includes the 3072 following four multicast capabilities: NAS-initiated replication, 3073 conditional access with white and black list, conditional access with 3074 grey list, and bandwidth delegation. At this point, the NAS can 3075 provision the service profiles on the AN and enable admission control 3076 at the AN for white-listed flows. To do this, the NAS sends the AN a 3077 Provisioning message containing this information. An example message 3078 providing the profile for our assumed subscriber is shown in 3079 Figure 20. The message has the following contents: 3081 o Message type is 93. 3083 o The Result and Result Code fields in the header are set to zeroes, 3084 as specified [RFC6320]. 3086 o A Transaction identifier is assigned by the NAS. 3088 o The Multicast-Service-Profile TLV (of which typically there would 3089 be multiple instances) contains a Multicast-Service-Profile-Name 3090 TLV (with a length of 20 octets assumed for the example) and three 3091 List-Action TLVs, one each for the white, grey, and black lists 3092 within the profile. The white list flows come in two sets of 3093 group addresses: 233.252.0.0/29, coming from a server at 3094 192.0.2.15, and 233.252.0.32/29, coming from a server at 3095 192.0.2.16. The grey-listed flows are in the band 3096 233.252.0.64/29, coming from a server at 192.0.2.21. Finally, the 3097 black list flows are two individual flows that happen to overlap 3098 with the grey list band: 233.252.0.65, and 233.252.0.69, also with 3099 source 192.0.2.21. 3101 o The White-List-CAC TLV indicates that the AN does admission 3102 control on white-listed flows. 3104 1 2 3 3105 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 3106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3107 | Type (0x880C) | Length = 132 | 3108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3109 | Version | Msg Type = 93 | 0x00 | Result Code = 0x000 | 3110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3111 | Partition ID | Transaction Identifier | 3112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3113 |I| SubMessage Number | Length = 132 | 3114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3115 | M-Serv-Prof TLV Type = 0x13 | TLV Length = 112 | 3116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3117 | M-S-Prof-Name TLV Type = 0x18 | Embedded TLV Length = 20 | 3118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3119 | Multicast service profile name | 3120 ~ = "Cust 0127-53681-0003" ~ 3121 | | 3122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3123 | List-Action TLV Type = 0x21 | Embedded TLV Length = 28 | 3124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3125 | Oper = 0x01 |Lst Typ = 0x01 | Reserved = 0x0000 | 3126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3127 | Address Family = 0x01 | List Length = 20 | 3128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3129 | G Preflen = 29| S Preflen = 32| Group prefix = | 3130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3131 | 233.252.0.0 | Source prefix = | 3132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3133 | 192.0.2.15 | G Preflen = 29| S Preflen = 32| 3134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3135 | Group prefix = 233.252.0.32 | 3136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3137 | Source prefix = 192.0.2.15 | 3138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3139 | List-Action TLV Type = 0x21 | Embedded TLV Length = 18 | 3140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3141 | Oper = 0x01 |Lst Typ = 0x03 | Reserved = 0x0000 | 3142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3143 | Address Family = 0x01 | List Length = 10 | 3144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3145 | G Preflen = 29| S Preflen = 32| Group prefix = / 3146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3147 / 233.252.0.64 | Source prefix = / 3148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3149 / 192.0.2.21 | Padding = 0x0000 | 3150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3151 | List-Action TLV Type = 0x21 | Embedded TLV Length = 28 | 3152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3153 | Oper = 0x01 |Lst Typ = 0x02 | Reserved = 0x0000 | 3154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3155 | Address Family = 0x01 | List Length = 20 | 3156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3157 | G Preflen = 32| S Preflen = 32| Group prefix = / 3158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3159 / 233.252.0.65 | Source prefix = / 3160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3161 / 192.0.2.21 | G Preflen = 32| S Preflen = 32| 3162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3163 | Group prefix = 233.252.0.69 | 3164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3165 | Source prefix = 192.0.2.21 | 3166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3167 |White-List-CAC TLV Type = 0x24 | TLV Length = 0 | 3168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3170 Figure 20: Example Provisioning Message 3172 TLV lengths in the figure are given in decimal for easier 3173 understanding. Note that the padding after the middle List-Action 3174 TLV is counted as part of length of the Multicast-Service-Profile 3175 TLV, but is not included in the length of that List-Action TLV. Note 3176 also that the Length field in the message header, unlike those in the 3177 TLVs, includes the message header itself, as required by [RFC6320]. 3179 Finally, note that the Provisioning message does not include a 3180 MRepCtl-CAC TLV since in our example admission control for grey 3181 listed flows and for NAS-initiated replication is performed by the 3182 NAS. 3184 As soon as the AN port comes up, the AN sends an ANCP PORT_UP message 3185 to the NAS specifying the Access Loop Circuit ID. The NAS replies 3186 with an ANCP Port Management message that, together with the other 3187 parameters, includes the multicast service profile name to be 3188 associated to that port along with the initial amount of delegated 3189 bandwidth. The corresponding message flow is illustrated in 3190 Figure 21. 3192 +----------+ +---------+ +-----+ +-----+ 3193 |Subscriber| | Home | | AN | | NAS | 3194 +----------+ | Gateway | +-----+ +-----+ 3195 | +---------+ | | 3196 | | | | 3197 | | | | 3198 | | DSL Synch. | | 3199 | |--------------------->| | 3200 | | |(M1)PORT_UP(Port ID) | 3201 | | |-------------------->| 3202 | | | (*) 3203 | | |(M2) PORT_MNGT | 3204 | | | (Port ID, | 3205 | | |Mcast S Profile Name,| 3206 | | |Bandwidth Allocation)| 3207 | | |<--------------------| 3209 (*) The NAS may optionally seek direction from an external 3210 Autorization/Policy Server 3212 Figure 21: Configuring an AN Port With Multicast Service Profile ID 3213 and Delegated Bandwidth Amount 3215 The Port Management message will typically contain other TLVs but our 3216 example (Figure 22) just shows the Target, Multicast-Service-Profile- 3217 Name, and Bandwidth-Allocation TLVs. The Target TLV identifies the 3218 subscriber line, the Multicast-Service-Profile-Name TLV is identical 3219 to the one contained in the Provisioning message, and the Bandwidth- 3220 Allocation TLV provides just enough bandwidth (2000 kbits/s) for one 3221 channel to start with. 3223 The following fields in the Port Management message header are shown 3224 with specific values either as directed by the base protocol document 3225 or for the sake of our example: 3227 o Message Type is 32. 3229 o Result is set to Nack (0x01) for this example. 3231 o Result Code is 0x000. 3233 o Port is set to 0. 3235 o Event Sequence Number, the R flag and the other bits marked x, 3236 Duration, the Event Flags, and the Flow Control Flags are all 3237 irrelevant for this function and are set to 0. 3239 o Function is set to 0x8, "Configure Connection Service Data". 3241 o X-Function is set to 0. 3243 o Tech Type is 0x05 (DSL). 3245 o Block lengths are calculated assuming a Circuit-Id length of 4 in 3246 our example. Recall that the example Multicast-Service-Profile- 3247 Name TLV length is 20. 3249 1 2 3 3250 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 3251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3252 | Type (0x880C) | Length = 84 | 3253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3254 | Version | Msg Type = 32 | 0x01 | Result Code = 0x000 | 3255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3256 | Partition ID | Transaction Identifier | 3257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3258 |I| SubMessage Number | Length = 84 | 3259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3260 | Port = 0 | 3261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3262 | Port Session Number | 3263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3264 | Event Sequence Number = 0 | 3265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3266 |R|x|x|x|x|x|x|x| Duration = 0 | Function = 0x8| X-Function = 0| 3267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3268 | Event Flags | Flow Control Flags | 3269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3270 |x|x|x|x|x|x|x|x| Msg Type = 32 |Tech Type=0x05 | Blk Len = 56 | 3271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3272 | # of TLVs = 3 | Extension Block length = 44 | 3273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3274 | Target TLV Type = 0x1000 | Target TLV Length = 8 | 3275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3276 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3278 | Access Loop Circuit ID | 3279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3280 | M-S-Prof-Name TLV Type = 0x18 | TLV Length = 20 | 3281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3282 | Multicast service profile name | 3283 ~ = "Cust 0127-53681-0003" ~ 3284 | | 3285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3286 | BW Alloc TLV Type = 0x15 | TLV Length = 4 | 3287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3288 | Bandwidth value = 0x000007D0 (2000 kbits/s) | 3289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3291 Figure 22: Example Port Management Message 3293 A.2. Handling a Grey-Listed Flow 3295 Suppose now that the subscriber chooses to watch the premium channel 3296 characterized by source 192.0.2.21, group 233.252.0.67. Upon 3297 receiving the Join request, the AN matches it against the multicast 3298 service profile for the port and determines that it is a grey-listed 3299 flow. Figure 23 illustrates the resulting ANCP message flow for the 3300 case of a simple join and leave, when admission control for grey- 3301 listed flows is not activated on the AN. 3303 To start the flow, the AN sends a Multicast Admission Control request 3304 (M1) to the NAS. The NAS decides whether flow can be admitted, 3305 applying both policy and bandwidth criteria. It returns its decision 3306 (positive in this example) in a Multicast Replication Control message 3307 (M2). Later, when the subscriber leaves the flow, the AN informs the 3308 NAS by sending another Multicast Admission Control message. 3310 +----------+ +-------+ +-----+ ANCP +-----+ 3311 |Subscriber| | Home | | AN |<---------->| NAS | 3312 +----------+ |Gateway| +-----+ +-----+ 3313 | +-------+ | | 3314 | | | Multicast | 3315 | Join(Grey-Fl) | Admission | 3316 |-----------+---------->| Control (M1) | 3317 | | |------------------>| 3318 | | | | (NAS performs 3319 | | | Multicast | admission 3320 | | | Replication (*) control) 3321 | | | Control (M2) | 3322 | Mcast Grey Flow |<------------------| 3323 |<======================+ | 3324 | | | | 3325 ~ ~ ~ ~ 3326 | | | Multicast | 3327 | Leave(Grey-Fl) | Admission | 3328 |-----------+---------->| Control (M3) | 3329 | | |------------------>| 3330 | | | | 3332 Grey-Fl : Multicast Flow matching an entry in grey List 3334 (*) The NAS may optionally seek direction from an external 3335 Authorization/Policy Server 3337 Figure 23: Successful Join/Leave Operations, Grey-Listed Flow 3339 The Multicast Admission Control message M1 contains: 3341 o an ANCP Header with: 3343 * Message-Type = 145 - Multicast Admission Control; 3345 * Result= 0x0 (Ignore); 3347 * Transaction-ID = Transaction-ID maintained by AN; 3349 o a Target TLV identifying the AN Port 3351 o a Command TLV containing: 3353 * Command Code = Add (1); 3355 * Accounting = 0; 3357 * a Multicast-Flow embedded TLV indicating the SSM multicast flow 3358 (Flow Type = 0x02) for which the AN received the IGMP Join: 3359 IPv4 (0x01) Group address= 233.252.0.67, IPv4 (0x01) Source 3360 Address = 192.0.2.21; 3362 * a Request-Source-IP embedded TLV containing the IGMP join 3363 source IP (192.0.2.100). 3365 The Multicast Admission Control message M1 is illustrated in 3366 Figure 24: 3368 1 2 3 3369 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 3370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3371 | Type (0x880C) | Length = 98 | 3372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3373 | Version | Msg Type=145 | 0x0 | Result Code = 0x000 | 3374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3375 | Partition ID | Transaction Identifier | 3376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3377 |I| SubMessage Number | Length = 98 | 3378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3379 | Type = 0x1000 (Target) | Target TLV Length = 8 | 3380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3381 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3383 | Access Loop Circuit ID | 3384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3385 | Command TLV Type = 0x11 | TLV Length = 28 | 3386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3387 | Cmd Code=0x01 |Acctg = 0x00 | Reserved = 0x0000 | 3388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3389 |Multicast-Flow TLV Type = 0x19 | Embedded TLV Length = 12 | 3390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3391 |Flow Type=0x02 |Addr Fam =0x01 | Reserved = 0x0000 | 3392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3393 | Multicast Group Address = 233.252.0.67 | 3394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3395 | Unicast Source Address = 192.0.2.21 | 3396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 3397 | Req-Src-IP TLV Type = 0x92 | Embedded TLV length = 4 | 3398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3399 | Unicast Address = 192.0.2.100 | 3400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3402 Figure 24: Multicast Admission Control Message Seeking To Add A Flow 3404 The Multicast Replication Control message M2 contains: 3406 o an ANCP Header with: 3408 * Message Type = 144 - Multicast Replication Control; 3410 * Result= 0x1 (NAck); 3412 * Transaction-ID = Transaction-ID maintained by NAS; 3414 o a Target TLV identifying the AN Port; 3416 o a Command TLV containing: 3418 * Command Code = Add (1); 3420 * Accounting = 1 (begin flow accounting), since in our example 3421 the operator wants accounting on this flow. 3423 * a Multicast-Flow embedded TLV indicating the SSM multicast flow 3424 (Flow Type = 0x02) that the NAS is admitting for this access 3425 port: IPv4 (0x01) Group address= 233.252.0.67, IPv4 (0x01) 3426 Source Address = 192.0.2.21. 3428 The Multicast Admission Control message M2 is illustrated in 3429 Figure 25. 3431 1 2 3 3432 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 3433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3434 | Type (0x880C) | Length = 48 | 3435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3436 | Version | Msg Type=144 | 0x1 | Result Code = 0x000 | 3437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3438 | Partition ID | Transaction Identifier | 3439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3440 |I| SubMessage Number | Length = 48 | 3441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3442 | Type = 0x1000 (Target) | Target TLV Length = 8 | 3443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3444 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3446 | Access Loop Circuit ID | 3447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3448 | Command TLV Type = 0x11 | TLV Length = 20 | 3449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3450 | Cmd Code=0x01 | Acctg = 0x01 | Reserved = 0x0000 | 3451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3452 |Multicast-Flow TLV Type = 0x19 | Embedded TLV Length = 12 | 3453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3454 |Flow Type=0x02 |Addr Fam =0x01 | Reserved = 0x0000 | 3455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3456 | Multicast Group Address = 233.252.0.67 | 3457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3458 | Unicast Source Address = 192.0.2.21 | 3459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3461 Figure 25: Multicast Replication Control Message Admitting A Flow 3463 The Multicast Admission Control message M3 advising the NAS that the 3464 flow has been terminated contains: 3466 o an ANCP Header with: 3468 * Message-Type = 145 - Multicast Admission Control 3470 * Result= 0x0 (Ignore) 3472 * Transaction-ID = Transaction-ID maintained by AN 3474 o a Target TLV identifying the AN Port 3476 o a Command TLV containing: 3478 * a Command Code = Delete (2); 3480 * Accounting = 0; 3482 * a Multicast-Flow embedded TLV indicating the SSM multicast flow 3483 (Flow Type = 0x02) for which the AN received the IGMP leave: 3484 IPv4 (0x01) Group address= 233.252.0.67, IPv4 (0x01) Source 3485 Address = 192.0.2.21. 3487 * a Request-Source-IP embedded TLV containing the IGMP leave 3488 request source, IPv4 (0x01) address 192.0.2.100. 3490 The Multicast Admission Control message M3 is illustrated in 3491 Figure 26. 3493 1 2 3 3494 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 3495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3496 | Type (0x880C) | Length | 3497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3498 | Version | Msg Type=145 | 0x0 | Result Code = 0x000 | 3499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3500 | Partition ID | Transaction Identifier | 3501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3502 |I| SubMessage Number | Length | 3503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3504 | Type = 0x1000 (Target) | Target TLV Length = 8 | 3505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3506 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3508 | Access Loop Circuit ID | 3509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3510 | Command TLV Type = 0x11 | TLV Length = 28 | 3511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3512 | Cmd Code=0x02 |Acctg = 0x00 | Reserved = 0x0000 | 3513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3514 |Multicast-Flow TLV Type = 0x19 | Embedded TLV Length = 12 | 3515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3516 |Flow Type=0x02 |Addr Fam =0x01 | Reserved = 0x0000 | 3517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3518 | Multicast Group Address = 233.252.0.67 | 3519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3520 | Unicast Source Address = 192.0.2.21 | 3521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3522 | Req-Src-IP TLV Type = 0x92 | Embedded TLV length = 4 | 3523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3524 | Unicast Address = 192.0.2.100 | 3525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3527 Figure 26: Multicast Admission Control Message Signalling Flow 3528 Termination 3530 A.3. Handling White-Listed Flows 3532 The NAS has enabled white list admission control on the AN, and the 3533 bandwidth delegation capability has been negotiated. White listed 3534 flows in themselves require no messages to the NAS, either upon 3535 admission or upon termination, but the AN may request an increase in 3536 the amount of delegated bandwidth if it needs the increase to admit a 3537 flow. 3539 Consider an example where the AN has already admitted one white- 3540 listed flow, thereby using up the initially provisioned amount of 3541 delegated bandwidth (2000 kbits/s). A request is received to join a 3542 new flow in the white list range. The AN chooses to send a Bandwidth 3543 Reallocation Request message to the NAS, requesting that the 3544 delegated bandwidth allocation be increased to 4000 kbits/s at a 3545 minimum, and preferably to 6000 kbits/s. 3547 In our example, the NAS is managing bandwidth tightly, as witnessed 3548 by its minimal initial allocation of just enough for one flow. It is 3549 willing to provide the minimum additional amount only, and therefore 3550 returns a Bandwidth Transfer message where the delegated bandwidth 3551 value is given as 4000 kbits/s. With this amount, the AN is able to 3552 admit the second white-listed flow. The AN could send a similar 3553 Bandwidth Transfer message back to the NAS bringing the delegated 3554 bandwidth amount back down to 2000 kbits/s when one of the flows is 3555 terminated, but this shows nothing new and is omitted. 3557 As one more point of illustration, suppose that the NAS chooses to 3558 audit the current amount of delegated bandwidth to ensure it is 3559 synchronized with the AN. It sends a Delegated Bandwidth Query 3560 request message to the AN, and receives a Delegated Bandwidth Query 3561 response message with the current allocation as the AN sees it. 3563 The complete message flow is shown in Figure 27. 3565 +----------+ +-------+ +-----+ ANCP +-----+ 3566 |Subscriber| | Home | | AN |<---------->| NAS | 3567 +----------+ |Gateway| +-----+ +-----+ 3568 | +-------+ | | 3569 | | | | 3570 | Join(White-F1) | | 3571 |-----------+---------->| | 3572 | | |AN performs | 3573 | Mcast White Flow 1 | admission control | 3574 |<======================+ | 3575 | | | | 3576 | Join(White-F2) | | 3577 |-----------+---------->|No bandwidth left | 3578 | | | | 3579 | | |Bandwidth | 3580 | | | Reallocation Req | 3581 | | |------------------>|(M1) 3582 | | | | 3583 | | | (*) 3584 | | |Bandwidth Transfer | 3585 | AN can now |<------------------|(M2) 3586 | admit flow | | 3587 | Mcast White Flow 2 | | 3588 |<======================+ | 3589 | | | | 3590 ~ ~ ~ ~ 3591 | | |Delegated Bandwidth| 3592 | | | Query request | 3593 | | |<------------------|(M3) 3594 | | | | 3595 | | |Delegated Bandwidth| 3596 | | | Query response | 3597 | | |------------------>|(M4) 3598 | | | | 3600 (*) The NAS may optionally seek direction from an external 3601 Authorization/Policy Server 3603 Figure 27: Successful Join/Leave Operations, White-Listed Flow 3605 The Bandwidth Reallocation Request message (M1) is shown in 3606 Figure 28. The contents require little explanation. The Message 3607 Type for the Bandwidth Reallocation Request is 146. The Result field 3608 is set to 0x0 (Ignore). Besides the Target, the message has one 3609 other TLV, the Bandwidth-Request, with a TLV Type of 0x16. The TLV 3610 contains Required Amount and Preferred Amount fields, set to 4000 and 3611 6000 kbits/s respectively. 3613 1 2 3 3614 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 3615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3616 | Type (0x880C) | Length = 36 | 3617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3618 | Version | Msg Type=146 | 0x0 | Result Code = 0x000 | 3619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3620 | Partition ID | Transaction Identifier | 3621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3622 |I| SubMessage Number | Length = 36 | 3623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3624 | Type = 0x1000 (Target) | Target TLV Length = 8 | 3625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3626 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3628 | Access Loop Circuit ID | 3629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3630 |Bandwidth-Req TLV Type = 0x16 | TLV Length = 8 | 3631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3632 | Required Amount = 0x00000FA0 (4000 kbits/s) | 3633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3634 | Preferred Amount = 0x00001770 (6000 kbits/s) | 3635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3637 Figure 28: Bandwidth Reallocation Request Message 3639 The Bandwidth Transfer message (M2) is shown in Figure 29. Again, 3640 the contents are easily understood. The Message Type for the 3641 Bandwidth Transfer message is 147. The Result field is set to 3642 Success (0x3). The message contains the Target TLV and the 3643 Bandwidth-Allocation TLV. The latter has a TLV Type of 0x15 and 3644 contains a Delegated Amount field, set to 4000 kbits/s. 3646 1 2 3 3647 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 3648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3649 | Type (0x880C) | Length = 32 | 3650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3651 | Version | Msg Type=147 | 0x3 | Result Code = 0x000 | 3652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3653 | Partition ID | Transaction Identifier | 3654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3655 |I| SubMessage Number | Length = 32 | 3656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3657 | Type = 0x1000 (Target) | Target TLV Length = 8 | 3658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3659 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3661 | Access Loop Circuit ID | 3662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3663 |BW-Allocation TLV Type = 0x15 | TLV Length = 4 | 3664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3665 | Delegated Amount = 0x00000FA0 (4000 kbits/s) | 3666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3668 Figure 29: NAS Response, Bandwidth Transfer Message 3670 The Delegated Bandwidth Query request message (M3) is shown in 3671 Figure 30. The Message Type for the Delegated Bandwidth Query 3672 request message is 148. The Result field is set to AckAll (0x2). 3673 The message contains the Target TLV only. 3675 1 2 3 3676 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 3677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3678 | Type (0x880C) | Length = 24 | 3679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3680 | Version | Msg Type=148 | 0x2 | Result Code = 0x000 | 3681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3682 | Partition ID | Transaction Identifier | 3683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3684 |I| SubMessage Number | Length = 24 | 3685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3686 | Type = 0x1000 (Target) | Target TLV Length = 8 | 3687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3688 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3690 | Access Loop Circuit ID | 3691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3693 Figure 30: Delegated Bandwidth Query Request Message 3695 Finally, the Delegated Bandwidth Query response message (M4) is shown 3696 in Figure 31. The Message Type for the Delegated Bandwidth Query 3697 response message is 148. The Result field is set to Success (0x3). 3698 The message contains the Target TLV and the Bandwidth-Allocation TLV 3699 with the Delegated Amount field set to 4000 kbits/s. 3701 1 2 3 3702 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 3703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3704 | Type (0x880C) | Length = 32 | 3705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3706 | Version | Msg Type=148 | 0x3 | Result Code = 0x000 | 3707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3708 | Partition ID | Transaction Identifier (copied from request) | 3709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3710 |I| SubMessage Number | Length = 32 | 3711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3712 | Type = 0x1000 (Target) | Target TLV Length = 8 | 3713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3714 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3716 | Access Loop Circuit ID | 3717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3718 |BW-Allocation TLV Type = 0x15 | TLV Length = 4 | 3719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3720 | Delegated Amount = 0x00000FA0 (4000 kbits/s) | 3721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3723 Figure 31: Delegated Bandwidth Query Response Message 3725 A.4. Handling Of Black-Listed Join Requests 3727 This section introduces no new messages, since requests for flows in 3728 the black list are simply ignored. The one thing to point out is the 3729 overlap in our example between the set of flows in the grey list and 3730 the flows in the black list. This does not create any ambiguity, 3731 since not only does the black list have priority for equally good 3732 matches, but also the black list entries are more specific (group 3733 prefix lengths of 32 versus 29 in the grey list) than the grey list 3734 flow prefixes. 3736 A.5. Handling Of Requests To Join and Leave the On-Line Game 3738 The final class of multicast control actions in our example allows 3739 the subscriber to enter and leave the on-line game. As described at 3740 the beginning of this example, the game uses Any Source Multicast 3741 (ASM). Subscriber signalling bypasses the AN, going directly to the 3742 NAS (e.g., through a web interface). 3744 When the subscriber requests to join the game, the NAS (after 3745 applying policy and bandwidth checks) sends a Multicast Replication 3746 Control message to the AN to enable the flow on the port concerned. 3747 The AN knows not to apply admission control, since it has not 3748 received an MRepCtl-CAC TLV in the Provisioning message. When the 3749 subscriber leaves, the NAS sends another Multicast Replication 3750 Control message to delete the flow. This message sequence is shown 3751 in Figure 32. 3753 It is possible that the NAS finds that there is not enough bandwidth 3754 available to accommodate the subscriber's request. In this case, the 3755 NAS could send a Bandwidth Reallocation Request message to the AN, 3756 asking it to release some of the bandwidth delegated to it. This is 3757 not shown in the present example, since the messages are the same as 3758 those already presented with the exception that the Preferred Amount 3759 in the request will be *less than* or equal to the Required amount, 3760 rather than *greater than* or equal to it. 3762 +----------+ +-------+ +-----+ ANCP +-----+ 3763 |Subscriber| | Home | | AN |<---------->| NAS | 3764 +----------+ |Gateway| +-----+ +-----+ 3765 | +-------+ | | 3766 | | | | 3767 | Join game | | 3768 |-----------+------------------------------>| 3769 | | | Multicast | NAS performs 3770 | | | Replication (*) admission 3771 | | | Control (M1) | control 3772 | Mcast Game Flow |<------------------| 3773 |<=====================>+ | 3774 | | | | 3775 ~ ~ ~ ~ 3776 | | | | 3777 | Leave game | | 3778 |-----------+------------------------------>| 3779 | | | Multicast | 3780 | | | Replication | 3781 | | | Control (M2) | 3782 | Mcast Game Flow |<------------------| 3783 | discontinued | | 3784 | | | | 3786 (*) The NAS may optionally seek direction from an external 3787 Authorization/Policy Server 3789 Figure 32: NAS-Initiated Flows For On-Line Gaming 3791 Multicast Replication Control message (M1) in Figure 33 looks like 3792 the message in Figure 25 with two exceptions. The first is that the 3793 NAS has the option to set the Result field to AckAll (0x02) if it 3794 needs positive reassurance that the flow has been enabled. This was 3795 not done here to save having to depict a response differing only in 3796 the Result field. The larger difference in this example is that the 3797 flow description in the Multicast-Flow embedded TLV is that of an ASM 3798 multicast group (Flow Type = 0x01) with IPv4 (0x01) group address 3799 233.252.1.100. 3801 1 2 3 3802 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 3803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3804 | Type (0x880C) | Length = 44 | 3805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3806 | Version | Msg Type=144 | 0x1 | Result Code = 0x000 | 3807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3808 | Partition ID | Transaction Identifier | 3809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3810 |I| SubMessage Number | Length = 44 | 3811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3812 | Type = 0x1000 (Target) | Target TLV Length = 8 | 3813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3814 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3816 | Access Loop Circuit ID | 3817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3818 | Command TLV Type = 0x11 | TLV Length = 16 | 3819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3820 | Cmd Code=0x01 | Acctg = 0x01 | Reserved = 0x0000 | 3821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3822 |Multicast-Flow TLV Type = 0x19 | Embedded TLV Length = 8 | 3823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3824 |Flow Type=0x01 |Addr Fam =0x01 | Reserved = 0x0000 | 3825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3826 | Multicast Group Address = 233.252.1.100 | 3827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 3829 Figure 33: Enabling The Subscriber To Join An On-Line Game 3831 Message M2 terminating the flow when the subscriber leaves the game 3832 looks the same as the message in Figure 33 with two exceptions: the 3833 Command Code becomes Delete (2), and Accounting is set to 0 to turn 3834 off flow accounting. Of course, the Transaction Identifier values 3835 will differ between the two messages. 3837 A.6. Example Flow For Multicast Flow Reporting 3839 The example in this section is independent of the example in the 3840 preceding sections. 3842 Figure 34 illustrates a message flow in a case where the NAS queries 3843 the AN about which multicast flows are active on port 10, on port 11 3844 and on port 20 of the AN. 3846 +----------+ +-------+ +-----+ ANCP +-----+ 3847 |Subscriber| | Home | | AN |<---------->| NAS | 3848 +----------+ |Gateway| +-----+ +-----+ 3849 | +-------+ | | 3850 | | | Multicast Flow | 3851 | | | Query Request | 3852 | | | (M1) | 3853 | | |<------------------| 3854 | | | | 3855 | | | Multicast Flow | 3856 | | | Query Response | 3857 | | | (M2) | 3858 | | |------------------>| 3859 | | | | 3860 | | | | 3862 Figure 34: Per-Port Multicast Flow Reporting 3864 The Multicast Flow Query Request message (M1) is illustrated in 3865 Figure 35. The Message Type is 149. The Result field is set to 3866 AckAll (0x2). Three Target TLVs are present, identifying port 10, 3867 port 20, and port 11 respectively. 3869 0 1 2 3 3870 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 3871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3872 | Type (0x880C) | Length | 3873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3874 | Version | Msg Type = 149|Rslt=2 | Result Code = 0 | 3875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3876 | Partition ID | Transaction Identifier | 3877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3878 |I| SubMessage Number | Length | 3879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3880 | Type = 0x1000 (Target) | Target TLV Length | 3881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3882 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 3883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3884 | | 3885 ~ Access Loop Circuit ID (port10) ~ 3886 | | 3887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3888 | Type = 0x1000 (Target) | Target TLV Length | 3889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3890 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 3891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3892 | | 3893 ~ Access Loop Circuit ID (port20) ~ 3894 | | 3895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3896 | Type = 0x1000 (Target) | Target TLV Length | 3897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3898 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 3899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3900 | | 3901 ~ Access Loop Circuit ID (port11) ~ 3902 | | 3903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3905 Figure 35: Multicast Flow Query Request Message For Per-Port 3906 Multicast Flow Reporting 3908 The Multicast Flow Query Response message (M2) is illustrated in 3909 Figure 36. It indicates that there is one active multicast flow 3910 [(192.0.2.1, 233.252.2.4)] on port 10, no active multicast flow on 3911 port 20 and two active multicast flows [(192.0.2.1, 233.252.2.4) and 3912 (192.0.2.2, 233.252.2.10)] on port 11. 3914 0 1 2 3 3915 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 3916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3917 | Type (0x880C) | Length | 3918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3919 | Version | Msg Type = 149|Rslt=3 | Result Code = 0 | 3920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3921 | Partition ID | Transaction Identifier | 3922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3923 |I| SubMessage Number | Length | 3924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3925 | Type = 0x1000 (Target) | Target TLV Length | 3926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3927 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 3928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3929 | | 3930 ~ Access Loop Circuit ID (port10) ~ 3931 | | 3932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3933 |Multicast-Flow TLV Type = 0x19 | Embedded TLV Length = 12 | 3934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3935 |Flow Type=0x02 |Addr Fam =0x01 | Reserved = 0x0000 | 3936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3937 | Multicast Group Address = 233.252.2.4 | 3938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3939 | Unicast Source Address = 192.0.2.1 | 3940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 3941 | Type = 0x1000 (Target) | Target TLV Length | 3942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3943 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 3944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3945 | | 3946 ~ Access Loop Circuit ID (port20) ~ 3947 | | 3948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3949 | Type = 0x1000 (Target) | Target TLV Length | 3950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3951 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 3952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3953 | | 3954 ~ Access Loop Circuit ID (port11) ~ 3955 | | 3956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3957 |Multicast-Flow TLV Type = 0x19 | Embedded TLV Length = 12 | 3958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3959 |Flow Type=0x02 |Addr Fam =0x01 | Reserved = 0x0000 | 3960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3961 | Multicast Group Address = 233.252.2.4 | 3962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3963 | Unicast Source Address = 192.0.2.1 | 3964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 3965 |Multicast-Flow TLV Type = 0x19 | Embedded TLV Length = 12 | 3966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3967 |Flow Type=0x02 |Addr Fam =0x01 | Reserved = 0x0000 | 3968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3969 | Multicast Group Address: 233.252.2.10 | 3970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3971 | Unicast Source Address = 192.0.2.2 | 3972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 3974 Figure 36: Multicast Flow Query Response message For Per-Port 3975 Multicast Flow Reporting 3977 Authors' Addresses 3979 Francois Le Faucheur 3980 Cisco Systems 3981 Greenside, 400 Avenue de Roumanille 3982 Sophia Antipolis 06410 3983 France 3985 Phone: +33 4 97 23 26 19 3986 Email: flefauch@cisco.com 3988 Roberta Maglione 3989 Cisco Systems 3990 Via Reiss Romoli 274 3991 Torino 10148 3992 Italy 3994 Phone: 3995 Email: robmgl@cisco.com 3997 Tom Taylor 3998 Huawei Technologies 3999 Ottawa 4000 Canada 4002 Email: tom.taylor.stds@gmail.com