idnits 2.17.1 draft-ietf-ancp-mc-extensions-04.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 -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? 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 9, 2011) is 4826 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 2932, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-ancp-protocol-15 -- 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 (~~), 6 warnings (==), 5 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 13, 2011 Telecom Italia 6 T. Taylor 7 Huawei 8 February 9, 2011 10 Multicast Control Extensions for ANCP 11 draft-ietf-ancp-mc-extensions-04.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 13, 2011. 50 Copyright Notice 52 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . 23 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 . . . . . . . . . . . . . . . . 31 111 4.6.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 32 112 4.6.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 32 113 4.7. Delegated Bandwidth Query Request Message . . . . . . . . 33 114 4.7.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 34 115 4.7.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 34 116 4.8. Delegated Bandwidth Query Response Message . . . . . . . . 34 117 4.8.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 34 118 4.8.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 35 119 4.9. Multicast Flow Query Request and Response Messages . . . . 35 120 4.9.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 36 121 4.9.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 37 122 4.10. Committed Bandwidth Report Message . . . . . . . . . . . . 38 123 4.10.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 38 124 4.10.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 38 126 5. ANCP TLVs For Multicast . . . . . . . . . . . . . . . . . . . 40 127 5.1. Multicast-Service-Profile TLV . . . . . . . . . . . . . . 40 128 5.2. Multicast-Service-Profile-Name TLV . . . . . . . . . . . . 41 129 5.3. List-Action TLV . . . . . . . . . . . . . . . . . . . . . 41 130 5.4. Sequence-Number TLV . . . . . . . . . . . . . . . . . . . 44 131 5.5. Bandwidth-Allocation TLV . . . . . . . . . . . . . . . . . 45 132 5.6. White-List-CAC TLV . . . . . . . . . . . . . . . . . . . . 45 133 5.7. MRepCtl-CAC TLV . . . . . . . . . . . . . . . . . . . . . 46 134 5.8. Bandwidth-Request TLV . . . . . . . . . . . . . . . . . . 46 135 5.9. Request-Source-IP TLV . . . . . . . . . . . . . . . . . . 47 136 5.10. Request-Source-MAC TLV . . . . . . . . . . . . . . . . . . 47 137 5.11. Multicast-Flow TLV . . . . . . . . . . . . . . . . . . . . 48 138 5.12. Report-Buffering-Time TLV . . . . . . . . . . . . . . . . 49 139 5.13. Committed-Bandwidth TLV . . . . . . . . . . . . . . . . . 50 140 6. Multicast Capabilities . . . . . . . . . . . . . . . . . . . . 51 141 6.1. Required Protocol Support . . . . . . . . . . . . . . . . 51 142 6.1.1. Protocol Requirements For NAS-initiated Replication . 52 143 6.1.2. Protocol Requirements For Committed Multicast 144 Bandwidth Reporting . . . . . . . . . . . . . . . . . 52 145 6.1.3. Protocol Requirements For Conditional Access With 146 White and Black Lists . . . . . . . . . . . . . . . . 53 147 6.1.4. Protocol Requirements For Conditional Access With 148 Grey Lists . . . . . . . . . . . . . . . . . . . . . . 54 149 6.1.5. Protocol Requirements For Delegated Bandwidth . . . . 55 150 6.2. Capability-Specific Procedures for Providing Multicast 151 Service . . . . . . . . . . . . . . . . . . . . . . . . . 56 152 6.2.1. Procedures For NAS-Initiated Replication . . . . . . . 56 153 6.2.2. Procedures For Committed Bandwidth Reporting . . . . 57 154 6.2.3. Procedures For Conditional Access With Black and 155 White Lists . . . . . . . . . . . . . . . . . . . . . 58 156 6.2.4. Procedures For Conditional Access With Grey Lists . . 60 157 6.2.5. Procedures For Delegated Bandwidth . . . . . . . . . . 61 158 6.3. Combinations of Multicast Capabilities . . . . . . . . . . 62 159 6.3.1. Combination of Conditional Access With White and 160 Black Lists and Conditional Access With Grey Lists . . 62 161 6.3.2. Combination of Conditional Access With Delegated 162 Bandwidth . . . . . . . . . . . . . . . . . . . . . . 63 163 6.3.3. Combination of NAS-Initiated Replication with 164 Other Capabilities . . . . . . . . . . . . . . . . . . 63 165 6.3.4. Combinations of Committed Bandwidth Reporting with 166 Other Multicast Capabilities . . . . . . . . . . . . . 64 167 7. Security Considerations . . . . . . . . . . . . . . . . . . . 65 168 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66 169 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 69 170 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70 171 10.1. Normative References . . . . . . . . . . . . . . . . . . . 70 172 10.2. Informative References . . . . . . . . . . . . . . . . . . 70 173 Appendix A. Example of Messages and Message Flows . . . . . . . . 72 174 A.1. Provisioning Phase . . . . . . . . . . . . . . . . . . . . 72 175 A.2. Handling a Grey-Listed Flow . . . . . . . . . . . . . . . 78 176 A.3. Handling White-Listed Flows . . . . . . . . . . . . . . . 83 177 A.4. Handling Of Black-Listed Join Requests . . . . . . . . . . 88 178 A.5. Handling Of Requests To Join and Leave the On-Line Game . 88 179 A.6. Example Flow For Multicast Flow Reporting . . . . . . . . 91 180 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 95 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. 189 [I-D.ietf-ancp-protocol] specifies a protocol for Access Node Control 190 in broadband networks in line with this framework. 192 [I-D.ietf-ancp-protocol] supports three use cases defined in 193 [RFC5851], specifically for DSL access: the DSL Topology Discovery 194 use case, the DSL Line Configuration use case and the DSL Remote 195 Connectivity Test use case. However, it does not support the 196 multicast use cases defined in [RFC5851]. The present document 197 specifies the extensions to the Access Node Control Protocol required 198 for support of these multicast use cases. In addition, it supports 199 the Committed Bandwidth Reporting use case, described below. In 200 terms of the ANCP protocol, these use cases are organized into five 201 capabilities: 203 o NAS-initiated multicast replication; 205 o conditional access with white and black lists; 207 o conditional access with grey lists; 209 o bandwidth delegation; 211 o committed bandwidth reporting. 213 NAS-initiated multicast replication assumes that multicast "join" and 214 "leave" requests are terminated on the NAS, or that the NAS receives 215 requests to establish multicast sessions through other means (e.g., 216 application-level signalling). The NAS sends commands to the AN to 217 start or stop replication of specific multicast flows on specific 218 subscriber ports. This use case is described briefly in the next-to- 219 last paragraph of Section 3.4 of [RFC5851]. 221 Conditional access is described in Sections 3.4.1 and 3.4.2.3 of 222 [RFC5851], with the latter section particularly applicable to 223 operation with white and black lists only. In case of "conditional 224 access with white and black lists", multicast join and leave requests 225 are terminated at the AN and accepted or ignored in accordance with 226 the direction provided by white and black lists respectively. The 227 white and black lists are provisioned per port at startup time and 228 may be modified thereafter. The NAS may enable admission control of 229 white-listed flows by appropriate provisioning. 231 Conditional access with grey lists is similar to conditional access 232 with white lists, except that before accepting any request matching a 233 grey list entry, the AN sends a request to the NAS for permission to 234 replicate the flow. Again, the NAS can enable admission control of 235 grey-listed flows at the AN. 237 Bandwidth delegation is described in Section 3.4.2.1 of [RFC5851]. 238 It allows flexible sharing of total video bandwidth on an access line 239 between the AN and the NAS. One application of such bandwidth 240 sharing is where the AN does multicast admission control, while the 241 NAS or Policy Server does unicast admission control. In that case, 242 bandwidth delegation allows dynamic sharing of bandwidth between 243 unicast and multicast video traffic on each access line. 245 Committed bandwidth reporting is described below, in Section 3.4. 246 The AN reports the amount of multicast bandwidth it has granted to a 247 given access line each time that value changes. These reports may be 248 buffered for a NAS-provisionable interval so that reports for 249 multiple access lines can be bundled into the same message. 251 The formal specification of the behaviours associated with each of 252 these capabilities, singly and in combination, is given in Section 6. 254 In addition to the multicast service processing behaviour just 255 sketched, the definition of each capability includes support for the 256 multicast accounting and reporting services described in Section 257 3.4.3 of [RFC5851]. Because of this common content and because of 258 other protocol overlaps between the different capabilities, the 259 protocol descriptions for the multicast extensions specified in this 260 document are merged into a single non-redundant narrative. Tables in 261 Section 6 then indicate the specific sub-sections of the protocol 262 description that have to be implemented to support each capability. 264 2. Terminology 266 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 267 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 268 document are to be interpreted as described in [RFC2119]. 270 The expression "delegated bandwidth" is used as a shorter way of 271 saying: "the total amount of video bandwidth delegated to the AN for 272 multicast admission control". 274 3. Multicast Use Cases 276 Quoting from [RFC5851]: 278 "... the Access Node, aggregation node(s) and the NAS must all be 279 involved in the multicast replication process. This avoids that 280 several copies of the same stream are sent within the access/ 281 aggregation network. In case of an Ethernet-based access/aggregation 282 network, this may, for example, be achieved by means of IGMP snooping 283 or IGMP proxy in the Access Node and aggregation node(s). By 284 introducing IGMP processing in the access/aggregation nodes, the 285 multicast replication process is now divided between the NAS, the 286 aggregation node(s) and Access Nodes. In order to ensure backward 287 compatibility with the ATM-based model, the NAS, aggregation node and 288 Access Node need to behave as a single logical device. This logical 289 device must have exactly the same functionality as the NAS in the ATM 290 access/aggregation network. The Access Node Control Mechanism can be 291 used to make sure that this logical/functional equivalence is 292 achieved by exchanging the necessary information between the Access 293 Node and the NAS. " 295 [RFC5851] describes the use cases for ANCP associated with such 296 multicast operations, and identifies the associated ANCP 297 requirements. The present section describes a subset of these use 298 cases as background to facilitate reading of this document, but the 299 reader is refered to [RFC5851] for a more exhaustive description of 300 the ANCP multicast use cases. Detailed example message flows can 301 also be found in Appendix A. 303 3.1. NAS Initiated Multicast Replication Control Use Case 305 3.1.1. Goals 307 One option for multicast handling is for the subscriber to 308 communicate the "join/leave" information to the NAS. This can be 309 done for instance by terminating all subscriber IGMP ([RFC3376]) or 310 MLD ([RFC2710], [RFC3810]) signaling on the NAS. Another example 311 could be a subscriber using some form of application level signaling, 312 which is redirected to the NAS. In any case, this option is 313 transparent to the access and aggregation network. In this scenario, 314 the NAS uses ANCP to create and remove replication state in the AN 315 for efficient multicast replication. Thus, the NAS only sends a 316 single copy of the multicast stream towards the AN, which in turn 317 performs replication to multiple subscribers as instructed by the NAS 318 via ANCP. The NAS first performs conditional access and multicast 319 admission control when processing multicast join requests, and only 320 creates replication state in the AN if admission succeeds. 322 3.1.2. Message Flow 324 With the NAS-initiated use case, a Multicast Replication Control 325 Message is sent by the NAS to the AN with a directive to either join 326 or leave one (or more) multicast flow(s). In the example message 327 flow, the AN uses a Generic Response message to convey the outcome of 328 the directive. Figure 1 illustrates such an ANCP message exchange as 329 well as the associated AN behavior. 331 +----------+ +-------+ +-----+ ANCP +-----+ 332 |Subscriber| | Home | | AN |<-------------------->| NAS | 333 +----------+ |Gateway| +-----+ +-----+ 334 | +-------+ | | 335 | | | (*) 336 | | | Multicast-Replication-Crl | 337 | | | (Target,add, Flow 1) | 338 | | |<--------------------------| 339 | Mcast Flow 1 | | 340 |<==========================+ | 341 | | | Generic Response | 342 | | |-------------------------->| 343 | | | | 344 | | | | 345 ~ ~ ~ ~ 346 | | | | 347 | | | Multicast-Replication-Crl | 348 | | | (Target,delete, Flow 1) | 349 | | |<--------------------------| 350 | | | | 351 | | Generic Response | 353 | | |-------------------------->| 355 (*) The NAS may optionally seek direction from an external 356 Authorization/Policy Server before admitting the flow. 358 Figure 1: NAS Initiated Multicast Replication Control 360 3.2. Conditional Access and Admission Control Use Case 362 3.2.1. Goals 364 One option for multicast handling is for the access/aggregation nodes 365 to participate in IGMP/MLD processing (e.g. via IGMP/MLD snooping). 366 In this scenario, on detecting a join/leave request from an enduser 367 for a multicast flow (in the grey list), the AN uses ANCP to request 368 conditional access and admission control decision from the NAS. In 369 turn, after conditional access and admission control checks, the NAS 370 uses ANCP to instruct the AN to change the replication states 371 accordingly. 373 3.2.2. Message Flow 375 For support of the conditional access and admission control use case, 376 on detection of an IGMP/MLD Join, the AN sends an Admission Control 377 message to the NAS to request conditional access and admission 378 control check. In case of positive outcome, the NAS sends a 379 Multicast Replication Control Message to the AN with a directive to 380 replicate the multicast flow to the corresponding user. Similarly on 381 detection of an IGMP/MLD leave, an Admission Control message is sent 382 by the AN to the NAS to keep the NAS aware of user departure for the 383 flow. This message flow is illustrated in Figure 2. 385 +----------+ +-------+ +-----+ ANCP +-----+ 386 |Subscriber| | Home | | AN |<------------------->| NAS | 387 +----------+ |Gateway| +-----+ +-----+ 388 | +-------+ | | 389 | | | | 390 | Join(Gr-Flow1) | Admission-Control | 391 |------------+---------->| (Target,add,Gr-Flow1) | 392 | | |-------------------------->| 393 | | | (*) 394 | | | Multicast-Replication-Crl | 395 | | | (Target,add,Gr-Flow 1) | 396 | | |<--------------------------| 397 | Mcast Gr-Flow1 | | 398 |<=======================+ | 399 | | | | 400 ~ ~ ~ ~ 401 | | | | 402 | Leave(Gr-Flow1) | Admission-Control | 403 |------------+---------->| (Target,delete,Gr-Flow1) | 404 | | |-------------------------->| 405 | | | 407 | | | | 409 Gr-Flow1: a multicast flow matching the grey list for that port 411 (*) The NAS may optionally seek direction from an external 412 Authorization/Policy Server before admitting the flow. 414 Figure 2: Multicast Conditional Access and Admission Control 416 3.3. Multicast Flow Reporting Use Case 418 3.3.1. Goals 420 The Multicast flow reporting use case allows the NAS to 421 asynchronously query the AN to obtain an instantaneous status report 422 related to multicast flows currently replicated by the AN. 424 3.3.2. Message Flow 426 The NAS sends a Multicast Flow Query Request message to the AN in 427 order to query the AN about information such as which multicast flows 428 are currently active on a given AN port or which ports are currently 429 replicating a given multicast flow. The AN conveys the requested 430 information to the NAS in a Multicast Flow Query Response message. 431 This message flow is illustrated in Figure 3. 433 +----------+ +-------+ +-----+ ANCP +-----+ 434 |Subscriber| | Home | | AN |<---------->| NAS | 435 +----------+ |Gateway| +-----+ +-----+ 436 | +-------+ | | 437 | | | Multicast Flow | 438 | | | Query Request | 439 | | |<------------------| 440 | | | | 441 | | | Multicast Flow | 442 | | | Query Response | 443 | | |------------------>| 444 | | | | 445 | | | | 447 Figure 3: Multicast Flow Reporting 449 3.4. Committed Bandwidth Reporting Use Case 451 3.4.1. Goals 453 The committed bandwidth reporting use case allows the NAS to maintain 454 current awareness of how much multicast bandwidth the AN has 455 committed to a given access line, so that the NAS can adjust its 456 forwarding scheduler to ensure the associated QoS. Note that this 457 involves a finer level of detail than provided by bandwidth 458 delegation, since the amount of delegated bandwidth is an upper limit 459 on the amount of bandwidth committed rather than an actual value. To 460 reduce the volume of messaging, reports from the AN may be buffered 461 so that one message reports on changes for multiple access lines. 463 3.4.2. Message Flow 465 The message flow associated with this use case is shown in Figure 4. 466 The figure assumes that a non-zero buffering interval was previously 467 provisioned on the AN. 469 +-----+ +-------+ +-----+ ANCP +-----+ 470 |Subs |+ | Home |+ | AN |<---------->| NAS | 471 |1,2 || |GW 1,2 || +-----+ +-----+ 472 +-----+| +-------+| | | 473 +|----+ +|------+ | | 474 | | | | | | 475 | |Join(Subs1, Ch1) | | 476 |----------+--------------->| Start buffering | 477 | | | Multicast flow | timer. Create | 478 |<==========================| message with | 479 | | | | | initial contents | 480 | | | | | reporting new | 481 | | | | | Subs1 bandwidth. | 482 | | Join(Subs2, Ch2) | | 483 | |----------+------------->| Add report for | 484 | | | Multicast flow | new Subs2 b/w. | 485 | |<========================| | 486 | | | | | | 487 | |Leave(Subs1, Ch1) | | 488 |----------+--------------->| Replace report | 489 | | | | | for Subs1 with | 490 | | Stop replication X new value (which | 491 | | | | | happens to be | 492 | | | | | the same as the | 493 | | | | | starting value. | 494 | | | | | | 495 | | | | >|< TIMER expires | 496 | | | | | | 497 | | | | |Committed | 498 | | | | | Bandwidth Report | 499 | | | | |------------------>| 500 | | | | | (for latest | 501 | | | | | Subs1 and Subs2 | 502 | | | | | bandwidth) | 503 | | | | | | 505 Figure 4: Message Flow For Committed Bandwidth Reporting 507 4. ANCP Messages 509 This section defines new ANCP messages and new usage of existing ANCP 510 messages as well as procedures associated with the use of these 511 messages. 513 4.1. Provisioning Message 515 Section 6.1.2 of [I-D.ietf-ancp-protocol] defines the Provisioning 516 message that is sent by the NAS to the AN to provision information in 517 the AN. 519 The present document specifies that the Provisioning message MAY be 520 used by the NAS to provision multicast-related information (e.g. 521 multicast service profiles). The ANCP Provisioning message payload 522 MAY contain: 524 o one or more instances of the Multicast-Service-Profile TLV. The 525 Multicast- Service-Profile TLV is defined in the present document 526 in Section 5.1. Each instance of the Multicast-Service-Profile 527 TLV contains a multicast service profile name and one or more list 528 actions. A list action consists of an action (add, delete, 529 replace), a list type (White, Black, or Grey), and list content 530 (multicast source and group addresses). 532 o an instance of the White-List-CAC TLV. The White-List-CAC TLV is 533 defined in Section 5.6. If present, this TLV indicates that the 534 AN is required to do admission control before replicating White- 535 listed flows. 537 o an instance of the MRepCtl-CAC TLV. The MRepCtl-CAC TLV is 538 defined in Section 5.7. If present, this TLV indicates that the 539 AN is required to do admission control before replicating flows 540 specified in Multicast Replication Control messages. 542 o an instance of the Report-Buffering-Time TLV. The Report- 543 Buffering-Time TLV is defined in Section 5.12. If present, this 544 TLV indicates Committed Bandwidth Report messages should be 545 buffered for the amount of time given by the TLV before being 546 transmitted to the NAS. 548 See Section 6 for information on which multicast capabilities require 549 support of these TLVs in the Provisioning message. 551 4.1.1. Sender Behaviour 553 When directed by the Policy Server or by management action, the NAS 554 sends the Provisioning message to initially provision or to update 555 the White, Black, and/or Grey multicast channel lists associated with 556 a set of named multicast service profiles, or to enable the AN to 557 perform admission control for specific classes of flows. 559 To provision or update a multicast service profile, the NAS MUST 560 include within the message one or more instances of the Multicast- 561 Service- Profile TLV specifying the content to be provisioned or 562 updated. The NAS SHOULD NOT include any list type (White, Black, or 563 Grey) that is not supported by the set of multicast capabilities 564 negotiated between the NAS and the AN. The NAS MUST NOT use the 565 Provisioning message to send instances of the Multicast- Service- 566 Profile TLV to the AN unless the Multicast-Service-Profile TLV is 567 supported by the set of multicast capabilities negotiated between the 568 NAS and the AN. 570 To require admission control to be performed at the AN on White- 571 listed flows, the NAS MUST include a copy of the White-List-CAC TLV 572 in the Provisioning message. The White-List-CAC TLV MUST NOT be 573 provided unless the negotiated set of capabilities includes 574 conditional access with White and Black lists. 576 To require admission control to be performed at the AN on Grey-listed 577 flows or on NAS-initiated flows, the NAS MUST include a copy of the 578 MRepCtl-CAC TLV in the Provisioning message. The MRepCtl-CAC TLV 579 MUST NOT be provided unless the negotiated set of capabilities 580 includes NAS-initiated replication control or conditional access with 581 Grey lists. 583 To require buffering of Committed Bandwidth Report messages so that 584 reports for multiple access lines can be included in the same 585 message, the NAS MUST include a copy of the Report-Buffering-Time TLV 586 containing a non-zero time value in a Provisioning message sent to 587 the AN. The Report-Buffering-Time TLV MUST NOT be provided unless 588 the negotiated set of capabilities includes committed bandwidth 589 reporting. 591 4.1.2. Receiver Behaviour 593 The receiving AN provisions/updates the White, Black, and/or Grey 594 lists associated with the multicast service profile names contained 595 in the Multicast-Service-Profile TLV instances within the message 596 according to the contents of the associated List-Action TLVs. The AN 597 MUST process List-Action TLVs in the order in which they appear 598 within the message. The AN MUST ignore instances of the List-Action 599 TLV referring to any list type (White, Black, or Grey) that is not 600 supported by the set of multicast capabilities negotiated between the 601 NAS and the AN. 603 When a new multicast service profile is identified by a Multicast- 604 Service-Profile TLV, the initial state of all lists associated with 605 that profile according to the negotiated set of multicast 606 capabilities is empty until changed by the contents of Multicast- 607 Service-Profile TLVs. 609 The receipt of a Provisioning message containing updates to an 610 existing multicast service profile subsequent to startup will cause 611 the AN to review the status of active flows on all ports to which 612 that profile has been assigned. For further details, see Section 6. 614 If the White-List-CAC and/or MRepCtl-CAC TLV is present in the 615 Provisioning message and the respective associated capabilities have 616 been negotiated, the AN prepares (or continues) to do connection 617 admission control on the indicated class(es) of flow. If one or both 618 of these TLVs was present in an earlier Provisioning message but is 619 absent in the latest message received, the AN ceases to do connection 620 admission control on the indicated class(es) of flow. 622 The buffering time specified in an instance of the Report-Buffering- 623 Time TLV applies to only to Committed Bandwidth Report messages 624 initiated after the new buffering time is received at the AN, not to 625 any message already in the process of accumulation. 627 As indicated in [I-D.ietf-ancp-protocol], the AN MUST NOT reply to 628 the Provisioning message if it processed it successfully. If an 629 error prevents successful processing of the message content, the AN 630 MUST return a Generic Response message as defined in 631 [I-D.ietf-ancp-protocol], containing a Status-Info TLV with the 632 appropriate content describing the error. For this purpose, the 633 presence of a list type in a Multicast-Service-Profile TLV which was 634 ignored because it was not supported by the negotiated set of 635 capabilities is not considered to be an error. 637 4.2. Port Management Message 639 As specified in [I-D.ietf-ancp-protocol], the NAS may send DSL line 640 configuration information to the AN ("ANCP based DSL Line 641 Configuration" use case) using GSMP Port Management messages modified 642 to contain additional information. See Section 5.3.3 of 643 [I-D.ietf-ancp-protocol] for details. 645 This document specifies that the Port Management message MAY also 646 include either or both of the following TLVs: 648 o Multicast-Service-Profile-Name TLV (defined in Section 5.2). This 649 TLV associates a Multicast Service Profile with the Access Port 650 specified by the extension block. 652 o Bandwidth-Allocation TLV (defined in Section 5.5). This TLV 653 specifies the total multicast bandwidth available to the AN for 654 admission control at the Access Port. 656 4.2.1. Sender Behaviour 658 The NAS sends the Port Management message at startup time to 659 initialize parameters associated with the Access Port specified in 660 the message and with the multicast capabilities negotiated between 661 the NAS and the AN. The NAS MAY send additional Port Management 662 messages subsequent to startup, to update or, in the case of the 663 Bandwidth-Allocation TLV, reset these parameters. If the NAS 664 includes a Multicast-Service-Profile-Name TLV in the Port Management 665 message, the name MUST match a profile name provided in a Multicast- 666 Service- Profile TLV in a prior Provisioning message. The NAS MUST 667 NOT include a TLV unless it is supported by the set of multicast 668 capabilities negotiated between the NAS and the AN. See Section 6 669 for further information. 671 4.2.2. Receiver Behaviour 673 If the Port Management message contains a Multicast-Service-Profile- 674 Name TLV, the AN associates the named profile with the specified 675 Access Port. This association replaces any previous association. 676 That is, a given Access Port is associated with at most one multicast 677 service profile. The replacement of one multicast service profile 678 with another will cause the AN to review the status of all active 679 flows on the target port. For further details see Section 6. 681 If the Port Management message contains a Bandwidth-Allocation TLV, 682 the AN adopts this as the current value of its total multicast 683 bandwidth limit for the target port. If the AN has already committed 684 multicast bandwidth exceeding the amount given in the Bandwidth- 685 Allocation TLV, the AN SHOULD NOT discontinue any multicast streams 686 in order to bring bandwidth down to within the new limit. However, 687 the AN MUST NOT admit new multicast streams that are subject to 688 admission control until it can do so within the limit specified by 689 the Bandwidth-Allocation TLV. 691 If the Port Management request cannot be processed due to error and 692 the Result field of the request is Nack (0x1) or AckAll (0x2), the AN 693 SHOULD add a Status-Info TLV to the Extension Value field in its 694 reply if this will provide useful information beyond what is provided 695 by the Code value returned in the response header. In particular, if 696 the name within the Multicast-Service-Profile-Name TLV does not match 697 a profile name given in a prior Provisioning message, the AN SHOULD 698 return a reply where the Code field in the header indicates "Invalid 699 TLV value" (85), the Error Message field in the Status-Info TLV 700 contains the text "Multicast profile name not provisioned", and the 701 Status-Info TLV contains a copy of the Multicast-Service-Profile-Name 702 TLV. 704 4.3. Multicast Replication Control Message 706 This section defines a new message called the Multicast Replication 707 Control message. The Multicast Replication Control message is sent 708 by the NAS to the AN with one or more directives to add (join) or 709 delete (leave) a multicast flow on a target object identified in the 710 content of the message. 712 The Message Type for the Multicast Replication Control message is 713 144. 715 The ANCP Multicast Replication Control message payload contains the 716 following TLVs: 718 o Target TLV: The Target TLV is defined in [I-D.ietf-ancp-protocol]. 719 It MUST appear once and only once. It is encoded as specified in 720 [I-D.ietf-ancp-protocol] or extensions and identifies the AN port 721 subject to the request for admission or release. 723 o Command TLV: The Command TLV is defined in 724 [I-D.ietf-ancp-protocol]. It MUST be present. It MAY appear 725 multiple times. 727 As [I-D.ietf-ancp-protocol] indicates, the contents of the Command 728 Info field within the Command TLV are specific to the message in 729 which the TLV occurs. For the Multicast Replication Control Message, 730 these contents consist of: 732 o a Command Code field; 734 o an Accounting field; 736 o an instance of the Multicast-Flow TLV. 738 Figure 5 illustrates the complete Command TLV with the contents 739 specific to the Multicast Replication Control message. 741 1 2 3 742 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 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | TLV Type = Command | Command-TLV Length | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 |Command Code | Accounting | Reserved | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | Multicast-Flow TLV | 749 | ... | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Other embedded TLV Type | Other embedded TLV Length | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | | 754 ~ Other embedded TLV data ~ 755 | | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 Figure 5: Contents of the Command TLV in the Multicast Replication 759 Control Message 761 Command Code: 762 Command directive: 764 0x01 - Add; 766 0x02 - Delete; 768 0x03 - Delete All; 770 0x04 - Admission Control Reject; 772 0x05 - Conditional Access Reject; 774 0x06 - Admission Control and Conditional Access 775 Reject. 777 Directives 0x04 through 0x06 are used as described in 778 Section 4.4.2 780 Accounting: 781 Meaningful only when the Command Code is "Add" (0x01). In 782 that case, 0x00 indicates no flow accounting, 0x01 783 indicates that octet accounting for the flow is to 784 commence. The Accounting field MUST be set to 0x00 for 785 other Command Code values. 787 Reserved: 788 Reserved for future use. MUST be set to 0x0000 by the 789 sender and ignored by the receiver. 791 Multicast-Flow TLV: 792 An instance of the Multicast-Flow TLV (Section 5.11) 793 specifying the flow to be added or deleted. The Multicast- 794 Flow TLV MUST be omitted if the Command Code has value 795 "Delete All" (0x03). 797 Other embedded TLV: 798 No other embedded TLVs are currently specified within the 799 Multicast Replication Control message/Command TLV. 800 Unrecognized embedded TLVs SHOULD be silently discarded. 802 The figure below is an example of a Multicast Replication Control 803 message that would result in a swap from multicast SSM flows 804 192.0.2.1, 233.252.0.2, to 192.0.2.2, 233.252.0.3 on the Target 805 identified by the "Access Loop Circuit ID": 807 1 2 3 808 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 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | Type (0x88-0C) | Length | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | Vers | Sub |MessageType=144| 0x02 | Code | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | Partition ID | Transaction Identifier = 0001 | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 |I| SubMessage Number | Length | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | Type = Target 0x1000 | Target TLV Length | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | | 823 ~ Access Loop Circuit ID ~ 824 | | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | Type = Command TLV | Command-TLV Length = 0x0014 | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | Cmd Code=0x02 |Acctg = 0x00 | Reserved = 0x0000 | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 |TLV Type = Multicast-Flow | TLV Length = 0x000C | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 |Flow Type=0x02 |AddrFam = 0x01 | Reserved = 0x0000 | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | Multicast Group Address: 233.252.0.2 | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 836 | Source Address = 192.0.2.1 | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 838 | Type = Command-TLV | Command-TLV Length = 0x0014 | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | Cmd Code=0x01 |Acctg = 0x01 | Reserved = 0x0000 | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 |TLV Type = Multicast-Flow | TLV Length = 0x000C | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 |Flow Type=0x02 |AddrFam = 0x01 | Reserved = 0x0000 | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Multicast Group Address = 233.252.0.3 | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | Source Address = 192.0.2.2 | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 851 4.3.1. Sender Behaviour 853 The NAS MAY issue a Multicast Replication Control message to the AN 854 to convey one or more directives to add (join) or delete (leave) one 855 or more multicast flows. 857 The NAS MAY send this message on its own initiative to support the 858 NAS initiated Multicast Control use case presented in [RFC5851] and 859 summarized in Section 3.1. In that case, the NAS MUST set the Result 860 field to AckAll (0x2) or Nack (0x1) according to its requirements. 862 The NAS MAY also send this message in response to a Multicast 863 Admission Control message (defined in Section 4.4) received from the 864 AN to support the conditional access and admission control use case 865 presented in [RFC5851] and summarized in Section 3.2. In that case, 866 the NAS MUST set the Result field to NAck (0x1). 868 In either case, the sender MUST populate the Code field with the 869 value 0x000 and the ANCP Transaction Identifier field with a unique 870 value, as described in Section 4.4.1 of [I-D.ietf-ancp-protocol]. 872 Each Multicast Replication Control Message MUST contain one or more 873 commands, each encapsulated in its own Command TLV. The sender MUST 874 use a separate Command TLV for each distinct multicast flow. 876 When the order of processing of two commands does not matter, the 877 commands MUST be transmitted in separate Multicast Replication 878 Control messages. 880 4.3.2. Receiver Behaviour 882 When successive commands (in the same or different messages) relate 883 to the same Target and multicast flow, the state of each feature 884 controlled or affected by attributes received in the Multicast 885 Replication Control message, SHALL be as set by the last command or 886 message referring to that target and flow and containing the 887 controlling attribute. As an example, successive Multicast 888 Replication Control messages containing add commands for a given port 889 and flow, but differing only in the Accounting field setting SHALL be 890 interpreted to mean that the state of the accounting feature is as 891 set in the final command received, but all other features are as set 892 in the initial message. 894 If more than one Command TLV is present in a Multicast Replication 895 Control message, the AN MUST act on the commands in the order in 896 which they are presented in the message. The AN SHALL assign a 897 sequence number to each command in a given Multicast Replication 898 Control message, starting from 0x01 for the first command. 900 If a Command TLV adds a flow and the AN is performing admission 901 control for Multicast Replication Control messages, then the AN MUST 902 perform admission control before replicating the flow. If the 903 admission control check fails, the AN MUST treat the failure as an 904 error as described below. The appropriate Code value for the 905 response is 18 (0x012) "Insufficient resources". 907 If the AN processes the complete Multicast Replication Control 908 message successfully and the Result field of the Multicast 909 Replication Control message was set to AckAll (0x2), the AN MUST 910 respond with a Generic Response message where the Result field is set 911 to Success (0x3), the Code field is set to 0x000, and the Transaction 912 Identifier field is copied from the Multicast Replication Control 913 message. The body of the response MAY be empty or MAY be copied from 914 the Multicast Replication Control message. 916 If the AN processes the complete Multicast Replication Control 917 message successfully and the Result field of the Multicast 918 Replication Control message was set to Nack (0x1), the AN MUST NOT 919 respond to the message. 921 The processing/execution of multiple commands contained in a single 922 Multicast Control message MUST be interrupted at the first error 923 encountered, and the remaining commands in the Multicast Replication 924 Control message discarded. 926 If the AN detects an error in a received Multicast Replication 927 Control message and the Result field in that message was set to Nack 928 (0x1) or AckAll(0x2), the AN MUST generate a Generic Response message 929 providing error information to the NAS. This specification 930 identifies the following new Code values beyond those specified in 931 [I-D.ietf-ancp-protocol], which MAY be used in a Generic Response 932 sent in reply to a Multicast Replication Control message: 934 100 Command error. This SHOULD be reported for the case that an 935 invalid command code has been received. 937 101 Bad flow address. This SHOULD be reported for the following 938 cases: 940 * unsupported address family; 942 * source address present for an ASM flow, or absent for an SSM 943 flow. 945 102 Multicast flow does not exist. This SHOULD be reported if the 946 NAS attempts to delete a flow that is not enabled. 948 A Generic Response message responding to the Multicast Replication 949 Control message and containing one of the above Code values MUST 950 include a Status-Info TLV which includes one or two embedded TLVs as 951 follows: 953 o a Sequence-Number TLV as described in Section 5.4, giving the 954 sequence number of the failed command, MUST be included; 956 o the failed Command TLV itself SHOULD be included. 958 Note that the Error Message field of the Status-Info TLV MAY be 959 used to report more details than implied by the Code value in the 960 message header. For example, the Code value could be 101 and the 961 Error Message field could contain the text: "Source address 962 present for ASM flow". 964 4.4. Multicast Admission Control Message 966 This section defines a new message called the Multicast Admission 967 Control message. The Multicast Admission Control message is sent by 968 the AN to the NAS to request admission of a multicast flow, or to 969 notify of the removal of a multicast flow, for a given target. 971 The Message Type for the Multicast Admission Control message is 145. 973 The ANCP Multicast Admission Control message payload contains two 974 TLVs: 976 o Target TLV: The Target TLV is defined in [I-D.ietf-ancp-protocol]. 977 It MUST appear once and only once in the Multicast Admission 978 Control message. It is encoded as specified in 979 [I-D.ietf-ancp-protocol] or extensions and identifies the AN port 980 subject to the request for admission or release. 982 o Command TLV: The Command TLV is defined in 983 [I-D.ietf-ancp-protocol]. It MUST be present. If it appears more 984 than once, only the first instance is considered meaningful in the 985 present version of this specification and the other instances are 986 ignored. 988 Informative note: 990 In the future, the specification of the Admission Control message 991 may be extended to allow transport of more than a single directive 992 (e.g. to carry both a leave from one group and a join to another 993 group for the same Target). It is expected that this would 994 support a similar notion of strict sequenced processing as 995 currently defined for handling multiple directives in the 996 Multicast Replication Control message whereby all directives 997 following the first directive that can not be executed are not 998 executed either. When the strict sequenced processing of the 999 directives is not required the directives are distributed across 1000 separate messages. 1002 The Command TLV has the same contents as were described above for the 1003 Multicast Replication Control message, with the following additions: 1005 o a Request-Source-IP TLV MAY be appended to the Command TLV as an 1006 additional embedded TLV; 1008 o similarly, a Request-Source-MAC TLV MAY be appended to the Command 1009 TLV as an additional embedded TLV. 1011 Note that the Command TLV length includes the length of any embedded 1012 TLVs, including the embedded TLV headers. 1014 4.4.1. Sender Behaviour 1016 The AN sending the Multicast Admission Control message MUST set the 1017 Result field to Ignore (0x0). 1019 The AN MUST populate the ANCP Transaction Identifier field with a 1020 unique value, as described in Section 4.4.1 of 1021 [I-D.ietf-ancp-protocol] . 1023 The AN MUST encode the Command TLV as specified in Section 4.3 with 1024 the following additional rules: 1026 o the Accounting field MUST be set to 0; 1028 o the Command Code field MUST be set to "0x01 - Add" when the 1029 message conveys a Join , to "0x02 - Delete" when the message 1030 conveys a Leave and to "0x03 - Delete All" when the message 1031 conveys a Leave of all channels (on the target); 1033 o The Multicast-Flow TLV within the Command TLV identifies the 1034 multicast flow subject to the request for admission or release. 1035 When the Command Code is 0x03, the Multicast-Flow TLV is 1036 meaningless and MUST be omitted. 1038 o the Request-Source-IP embedded TLV MAY be included by the AN to 1039 convey the IP address of the sender of the join/leave message 1040 (e.g. IGMP/MLD Join/Leave) that triggered the AN to include the 1041 corresponding Command TLV in the Admission Control message. If it 1042 appears more than once, only the first instance is considered 1043 meaningful and the other instances are ignored. 1045 o the Request-Source-MAC embedded TLV MAY be included by the AN to 1046 convey the MAC address of the sender of the join/leave message 1047 (e.g. IGMP/MLD Join/Leave) that triggered the AN to include the 1048 corresponding Command TLV in the Admission Control message. If it 1049 appears more than once, only the first instance is considered 1050 meaningful and the other instances are ignored. 1052 4.4.2. Receiver Behaviour 1054 On receipt of an Multicast Admission Control message, the NAS: 1056 o MUST ignore the Result field; 1058 o if the directive in the Multicast Admission Control message is 1059 "0x02 - Delete" or "0x03 - Delete All" and is processed correctly 1060 by the NAS, the NAS MUST NOT generate any ANCP message in response 1061 to the Multicast Admission Control message; 1063 o if the directive in the Multicast Admission Control message is 1064 "0x01 - Add" and is accepted by the NAS, the NAS MUST generate a 1065 Multicast Replication Control in response to the Multicast 1066 Admission Control message. The Multicast Replication Control 1067 message: 1069 * MUST contain a Result set to Nack (0x1); 1071 * MUST contain a Transaction ID generated by the NAS (distinct 1072 non-zero, and linearly incremented by NAS for each request per 1073 adjacency); 1075 * MUST contain the directive as accepted by the NAS. The NAS MAY 1076 modify the Accounting field if flow accounting is required. 1078 o if the directive in the Multicast Admission Control message is 1079 "0x01 - Add", is processed correctly but not accepted by the NAS 1080 (i.e. it does not pass the admission control or conditional access 1081 check), the NAS MAY generate a Multicast Replication Control 1082 message in response to the Multicast Admission Control message. 1083 This optional message can be used by the AN to maintain statistics 1084 about admission control rejections. 1086 In the future, the AN may be able to notify the subscriber that 1087 the request was rejected (e.g. using 1088 [I-D.morin-mboned-igmpmld-error-feedback]). 1090 When used in this situation, the Multicast Replication Control 1091 message: 1093 * MUST contain a Result set to 0x0; 1095 * MUST contain a Transaction ID generated by the NAS (distinct 1096 non-zero, and linearly incremented by NAS for each request per 1097 adjacency); 1099 * MUST contain the directive rejected by the NAS (i.e. Target 1100 TLV and Command TLV) but with a Command Code set to "0x04 - 1101 Admission Control Reject", "0x05 - Conditional Access Reject", 1102 or "0x06 - Admission Control and Conditional Access Reject". 1104 o if the Multicast Admission Control message cannot be processed 1105 correctly by the NAS (e.g. the message is malformed, the multicast 1106 flow does not exist etc.), the NAS MUST generate a Generic 1107 Response message (defined in Section 6.1.3 of 1108 [I-D.ietf-ancp-protocol]) with appropriate content indicating the 1109 reason for the failure. 1111 4.5. Bandwidth Reallocation Request Message 1113 The Bandwidth Reallocation Request message is used when the bandwidth 1114 delegation capability is included in the negotiated set. It MAY be 1115 sent either by the NAS or by the AN to request an adjustment in the 1116 amount of delegated bandwidth. It will be sent by the NAS typically 1117 to reduce the multicast bandwidth allocated to the AN in order for 1118 the NAS to satisfy a request to add one or more flows. Conversely, 1119 the AN will send a Bandwidth Reallocation Request to obtain 1120 additional bandwidth to satisfy a request to add a multicast channel. 1121 In each case, the requestor has a minimum requirement for additional 1122 bandwidth, and MAY ask for additional bandwidth beyond this amount 1123 (e.g., to handle anticipated future requests). 1125 The Bandwidth Reallocation Request message contains two TLVs: 1127 o the Target TLV (Section 6.2.1 of [I-D.ietf-ancp-protocol] or an 1128 extension), specifying a single access line; 1130 o the Bandwidth-Request TLV (Section 5.8), specifying the required 1131 and preferred amounts of delegated bandwidth. 1133 The Message Type for the Bandwidth Reallocation Request message is 1134 146. 1136 4.5.1. Sender Behaviour 1138 The Result field in the header of the Bandwidth Reallocation Request 1139 message is not used and the sender MUST set it to Ignore (0x0). 1141 The bandwidth values in the Bandwidth-Request TLV are expressed in 1142 terms of total multicast bandwidth allocated to the AN. 1144 The choice of "total bandwidth" rather than "incremental 1145 bandwidth" was made so that it would be easier for the AN and NAS 1146 to keep their respective views of the current amount of delegated 1147 bandwidth synchronized. 1149 Because the values are totals rather than desired increments/ 1150 decrements, the relationship between the required amount and the 1151 preferred amount will differ depending on whether the Bandwidth 1152 Reallocation Request message is issued by the NAS or the AN. 1154 o If the NAS is making the request, the preferred amount MUST be 1155 less than or equal to the required amount. The required amount 1156 MUST be less than the currently amount of delegated bandwidth. 1158 o If the AN is making the request, the preferred amount MUST be 1159 greater than or equal to the required amount. The required amount 1160 MUST be greater than the currently amount of delegated bandwidth. 1162 4.5.2. Receiver Behaviour 1164 When the peer receives a valid Bandwidth Reallocation Request 1165 message, it SHOULD determine whether it can satisfy the request from 1166 its existing allocation of unused video bandwidth. If it decides 1167 that it can reallocate bandwidth to the peer, it MAY choose to return 1168 any amount between the required and the preferred amounts indicated 1169 in the Bandwidth Reallocation Request message. 1171 The peer MUST return a Bandwidth Transfer message Section 4.6 1172 indicating its decision. If the request is met, the Result field of 1173 the Bandwidth Transfer message MUST be set to Success (0x3), the Code 1174 field MUST be set to 0x000, and the Bandwidth-Allocation TLV 1175 (Section 5.5) MUST contain the new value of total multicast 1176 bandwidth. This new value MUST lie between the required and 1177 preferred values, inclusive, from the request message. If the 1178 request is not met, the Result field of the Bandwidth Transfer 1179 message MUST be set to Failure (0x4), the Code field MUST be set to 1180 0x000, and the Bandwidth Allocation TLV MUST contain the value of the 1181 currently allocated amount of delegated bandwidth as the responder 1182 views it. 1184 The following cases indicate that the sender holds a different view 1185 of the amount of delegated bandwidth from the receiver: 1187 o the NAS receives a request where the required amount is less than 1188 its view of the current amount of delegated bandwidth; 1190 o the AN receives a request where the required amount is greater 1191 than its view of the current amount of delegated bandwidth. 1193 If one of these cases occurs, the receiver with one exception MUST 1194 send a Bandwidth Transfer message indicating Success. 1196 o If the NAS received the request, the allocated amount in the NAS's 1197 response MUST be at least equal to NAS's view of the current 1198 amount of delegated bandwidth. 1200 o If the AN received the request, the allocated amount in the AN's 1201 response MUST be no greater than the AN's view of the current 1202 amount of delegated bandwidth. 1204 The exception is when the NAS receives a request while it has a 1205 request of its own outstanding. Handling of that case is described 1206 below. 1208 While the cases just described are an error condition, the success 1209 response achieves a graceful recovery. 1211 To avoid deadlock due to race conditions, the following rules MUST be 1212 applied: 1214 a. If the NAS receives a Bandwidth Reallocation Request message 1215 while it has a Bandwidth Reallocation Request message of its own 1216 outstanding for the same access line, the NAS MUST provide an 1217 immediate failure response to the request from the AN, with a 1218 Code value set to 105 "Bandwidth request conflict". 1220 b. If the AN receives a Bandwidth Reallocation Request message while 1221 it has a Bandwidth Reallocation Request message of its own 1222 outstanding for the same access line, the AN MUST release any 1223 bandwidth it has already committed to an outstanding Join request 1224 while it is awaiting a response from the NAS. It MUST decide 1225 upon and send its response to the NAS taking the released 1226 bandwidth into account. 1228 If the receiver is unable to process the Bandwidth Reallocation 1229 Request message due to an error, then the receiver MUST return a 1230 Bandwidth Transfer message where: 1232 o the Result field is set to Failure (0x4), 1234 o the Code field is set appropriately to indicate the type of error 1235 that was detected, 1237 o the Bandwidth Allocation TLV contains the value of the current 1238 amount of delegated bandwidth as the responder views it, and 1240 o a Status-Info TLV MAY follow the Bandwidth Allocation TLV giving 1241 further information about the error. 1243 This specification provides three new Code values applicable 1244 specifically to the contents of the Bandwidth-Request TLV. These 1245 Code values by their nature MUST only be used when the error is being 1246 reported in a Bandwidth Transfer message rather than a Generic 1247 Response message. 1249 103 invalid preferred bandwidth amount. This indicates that the 1250 preferred and required amounts of bandwidth in the TLV do not have 1251 the numerical relationship described in the previous section. 1253 104 inconsistent views of delegated bandwidth amount. This will 1254 appear only in a Bandwidth Transfer message from the NAS to the AN 1255 in the case where the NAS has an outstanding Bandwidth 1256 Reallocation Request. The recommended procedure for recovery is 1257 described in Section 4.6.2. 1259 105 bandwidth request conflict. The NAS has rejected the AN's 1260 request for more bandwidth because the NAS has an outstanding 1261 bandwidth request. 1263 4.6. Bandwidth Transfer Message 1265 The Bandwidth Transfer message is used to transfer video bandwidth 1266 from the sender to the peer for a specific access line. This message 1267 MAY be sent either from the AN or from the NAS. As described in the 1268 previous section, it is the required response to a valid Bandwidth 1269 Reallocation Request message. 1271 The Bandwidth Transfer message MAY also be used to transfer bandwidth 1272 autonomously from one peer to another. One example of this usage is 1273 to release bandwidth borrowed earlier by means of the Bandwidth 1274 Reallocation Request message. When the message is used in this way, 1275 the Result field in the Bandwidth Transfer message MUST be set to 1276 Ignore (0x0). 1278 This allows the receiver to distinguish between an autonomous 1279 transfer and a response to a previous Bandwidth Reallocation 1280 Request, for purposes of validation. 1282 The Message Type for the Bandwidth Transfer message is 147. The 1283 Bandwidth Transfer message contains the following TLVs: 1285 o the Target TLV, designating the access line concerned; 1287 o an instance of the Bandwidth-Allocation TLV (Section 5.5). The 1288 bandwidth value in the Bandwidth-Allocation TLV is the new amount 1289 of delegated bandwidth allocated to the target. 1291 4.6.1. Sender Behaviour 1293 When sending a Bandwidth Transfer message where the Result value is 1294 Ignore (0x0) or Success (0x3), the following relationships MUST hold: 1296 o if the message is sent by the NAS, the bandwidth value in the 1297 Bandwidth-Allocation TLV MUST be greater than or equal to the 1298 sender's view of the current amount of delegated bandwidth for the 1299 access line concerned; 1301 o if the message is sent by the AN, the bandwidth value in the 1302 Bandwidth-Allocation TLV MUST be less than or equal to the 1303 sender's view of the current amount of delegated bandwidth for the 1304 access line concerned. 1306 Further sender behaviour is specified above, in Section 4.5.2. 1308 4.6.2. Receiver Behaviour 1310 4.6.2.1. Behaviour of the NAS 1312 If the amount of delegated bandwidth provided in the Bandwidth- 1313 Allocation TLV is not greater than the NAS's view of the current 1314 amount of delegated bandwidth, the NAS MUST update its view of the 1315 current amount of delegated bandwidth to the amount indicated in the 1316 Bandwidth Transfer message. This is required regardless of whether 1317 the Result field of that message indicates Success or Failure. 1319 If the amount of delegated bandwidth provided in the Bandwidth- 1320 Allocation TLV is greater than the NAS's view of the current amount 1321 of delegated bandwidth, the NAS MAY accept the given value as its new 1322 value of delegated bandwidth. Alternatively, the NAS MAY force the 1323 AN to modify its view of the amount of delegated bandwidth to that 1324 held by the NAS, by sending a Port Management message for the target 1325 access line concerned, containing a Bandwidth-Allocation TLV with a 1326 value equal to the amount of delegated bandwidth the NAS wishes to 1327 enforce. 1329 4.6.2.2. Behaviour of the AN 1331 If the amount of delegated bandwidth provided in the Bandwidth- 1332 Allocation TLV of the Bandwidth Transfer message differs from the 1333 AN's view of the current amount of delegated bandwidth, the AN MUST 1334 update its view of the current amount of delegated bandwidth to the 1335 amount indicated in the Bandwidth Transfer message. This is required 1336 with the exception of a Bandwidth Transfer message with a Result 1337 field equal to Failure (0x4) and a Code field equal to 104 1338 "Inconsistent views of delegated bandwidth amount" or 105 "Bandwidth 1339 request conflict". If Code value 104 is received, the AN MUST issue 1340 a Delegated Bandwidth Query Request message to determine the NAS's 1341 current view of the amount of delegated bandwidth. The AN MUST 1342 update its own view based on the value returned in the Delegated 1343 Bandwidth Query Response. If Code value 105 is received, the AN 1344 SHOULD carry out this procedure unless it can account for the 1345 discrepancy as a result of a transfer of bandwidth to the NAS that 1346 was carried out just before the incoming Bandwidth Transfer message 1347 was processed. 1349 The two Code values indicate a race condition where the AN may 1350 have just completed a transfer of bandwidth to the NAS. As a 1351 result, the value given in the Bandwidth Transfer message may be 1352 outdated, and the AN needs to query the NAS to find its latest 1353 view. The procedure assumes that ordering is preserved between 1354 the Bandwidth Transfer message sent by the AN in response to the 1355 NAS's request and the subsequent Delegated Bandwidth Query Request 1356 message. 1358 If as the result of the procedures just described the AN determines 1359 that it has over-committed multicast bandwidth, it MUST NOT terminate 1360 any currently-active programs, but MUST NOT honour any more "join" 1361 requests until it is possible to do so within the limit set by its 1362 current value of delegated bandwidth. 1364 4.7. Delegated Bandwidth Query Request Message 1366 The Message Type for the Delegated Bandwidth Query Request (and 1367 Response) messages is 148. 1369 The Delegated Bandwidth Query Request message MAY be sent either by 1370 the NAS or by the AN to retrieve the peer's view of the amount of 1371 delegated bandwidth. The request contains one TLV: 1373 o a Target TLV designating the access line for which the information 1374 is requested. 1376 4.7.1. Sender Behaviour 1378 The sender MUST set the Result field in the header of the Delegated 1379 Bandwidth Query Request message to AckAll (0x2). The Code value MUST 1380 be set to 0x000. The sender MUST populate the ANCP Transaction 1381 Identifier field with a unique value, as described in Section 4.4.1 1382 of [I-D.ietf-ancp-protocol]. 1384 4.7.2. Receiver Behaviour 1386 If the AN or NAS receives a valid Delegated Bandwidth Query Request 1387 message, it MUST respond with a Delegated Bandwidth Query Response 1388 message. The Result field in the header of the response MUST be set 1389 to Success (0x3). The Code field MUST be set to 0x000. The 1390 Transaction-Id field MUST be copied from the request message. The 1391 body of the response MUST contain the Target TLV, copied from the 1392 request message. Finally, the body of the response MUST contain a 1393 Bandwidth-Allocation TLV, containing the current amount of delegated 1394 bandwidth from the point of view of the receiver of the request. 1396 If the contents of the Delegated Bandwidth Query Request message are 1397 in error, the receiver MUST return a Delegated Bandwidth Query 1398 Response message with the Result field in the header set to Failure 1399 (0x3). The Code field MUST be set to the value that indicates the 1400 nature of the error (e.g., 4 "Unrecognized target"). The 1401 Transaction-Id field MUST be copied from the request. The body of 1402 the response MUST contain the Target TLV copied from the request. 1403 This MAY be followed by a Status-Info TLV giving further information 1404 about the error. 1406 4.8. Delegated Bandwidth Query Response Message 1408 The Delegated Bandwidth Query Response message is sent in reply to a 1409 Delegated Bandwidth Query Request. The response to a valid request 1410 contains two TLVs: 1412 o the Target TLV, copied from the request; 1414 o a Bandwidth-Allocation TLV, giving the responder's view of the 1415 current amount of multicast bandwidth delegated to the AN. 1417 The Message Type for the Delegated Bandwidth Query Response message 1418 is 148. 1420 4.8.1. Sender Behaviour 1422 Sender behaviour for the Delegated Bandwidth Query Response message 1423 is specified in Section 4.7.2. 1425 4.8.2. Receiver Behaviour 1427 If the Delegated Bandwidth Query Response message indicates Success 1428 (0x3), the following actions apply. 1430 4.8.2.1. Behaviour at the NAS 1432 If the amount of delegated bandwidth provided in the Bandwidth- 1433 Allocation TLV is less than the NAS's view of the current amount of 1434 delegated bandwidth, the NAS MUST update its view of the current 1435 amount of delegated bandwidth to the amount indicated in the 1436 Delegated Bandwidth Query Response message. 1438 If the amount of delegated bandwidth provided in the Bandwidth- 1439 Allocation TLV is greater than the NAS's view of the current amount 1440 of delegated bandwidth, the NAS MAY accept the given value as its new 1441 value of delegated bandwidth. Alternatively, the NAS MAY force the 1442 AN to modify its view of the amount of delegated bandwidth to that 1443 held by the NAS, by sending a Port Management message for the target 1444 access line concerned, containing a Bandwidth-Allocation TLV with a 1445 value equal to the amount of delegated bandwidth the NAS wishes to 1446 enforce. 1448 4.8.2.2. Behaviour at the AN 1450 The AN SHOULD accept the value returned in the Bandwidth-Allocation 1451 TLV of the Delegated Bandwidth Query Response message as the correct 1452 value of the current amount of delegated bandwidth. If the AN has 1453 currently committed more than this amount to active programs, it MUST 1454 NOT cease replicating the flows concerned, but MUST NOT honour any 1455 more Join requests until possible to do so within the new limit. 1457 A race condition is possible, where the AN sends a query, the NAS 1458 requests more bandwidth, then receives and responds to the query, 1459 then receives the Bandwidth Transfer message responding to its 1460 request. It is up to the AN to take appropriate action in this 1461 case. The best action appears to be not to act on the result of 1462 the first query, but to repeat the query after sending the 1463 Bandwidth Transfer message. Similar considerations apply to a 1464 race between queries from both sides. 1466 4.9. Multicast Flow Query Request and Response Messages 1468 This section defines two new messages called the Multicast Flow Query 1469 Request and Multicast Flow Query Response. The Multicast Flow Query 1470 Request is sent by the NAS to request information about the multicast 1471 flows that are active on the AN. The Multicast Flow Query Response 1472 is sent in response by the AN to provide the requested information to 1473 the NAS. 1475 The Message Type for the Multicast Flow Query Request and Multicast 1476 Flow Query Response messages is 149. 1478 The contents of the Multicast Flow Query Request and Response depend 1479 on the nature of the query, as described below. 1481 4.9.1. Sender Behaviour 1483 The sender of a Multicast Flow Query Request message MUST set the 1484 Result field to AckAll (0x2). The Code field MUST be set to 0x000. 1485 The sender MUST populate the ANCP Transaction Identifier field with a 1486 unique value, as described in section 4.4.1 of [I-D.ietf-ancp- 1487 protocol]. 1489 The Multicast Flow Query Request MAY be used by the NAS to retrieve: 1491 o the AN's view of which multicast flows are currently active on a 1492 specified set of access ports; or 1494 o the AN's view of the access ports on which a specified set of 1495 multicast flows are currently active; or 1497 o the AN's view of all the multicast flows currently active on each 1498 and every port of the AN. 1500 To retrieve the AN's view of which multicast flows are currently 1501 active on a given port of the AN, the NAS MUST include a Target TLV 1502 in the Multicast Flow Query Request payload identifying that port. 1503 The Target TLV is encoded as specified in [I-D.ietf-ancp-protocol]. 1505 To retrieve the AN's view of the ports currently receiving a given 1506 multicast flow, the NAS MUST include a Multicast-Flow TLV in the 1507 Multicast Flow Query Request payload identifying that flow. The 1508 Multicast-Flow TLV is encoded as specified in Section 5.11. 1510 The NAS MAY include multiple Target TLVs or multiple Multicast-Flow 1511 TLVs in the Multicast Flow Query Request, but MUST NOT include both 1512 Target and Multicast-Flow TLVs in the same message. 1514 To retrieve the AN's view of all of the multicast flows currently 1515 active on each port of the AN, the NAS MUST send a Multicast Flow 1516 Query Request which does not contain any instance of the Target TLV 1517 or the Multicast-Flow TLV. 1519 4.9.2. Receiver Behaviour 1521 The AN MUST respond to a Multicast Flow Query Request message that 1522 has a valid format and a valid content with a Multicast Flow Query 1523 Response message. The Result field in the response MUST be set to 1524 Success (0x3). The Code field MUST be set to 0x000. The 1525 Transaction-Id field MUST be copied from the request. 1527 If the Multicast Flow Query Request contained one (or more) Target 1528 TLVs, the AN MUST include, for each of these Target TLVs, the 1529 following set of TLVs: 1531 o Target TLV. This MUST be identical to the Target TLV in the 1532 received Multicast Flow Query Request message. 1534 o Multicast-Flow TLV(s). The Multicast-Flow TLV MUST appear once 1535 per multicast flow that is currently active on the AN port 1536 identified in the preceding Target TLV. 1538 The Target TLVs MUST appear in the response from the AN in the same 1539 order as in the query from the NAS. 1541 If the Multicast Flow Query Request contained one (or more) 1542 Multicast-Flow TLVs, the AN MUST include, for each of these 1543 Multicast-Flow TLVs, the following set of TLVs: 1545 o Multicast-Flow TLV. This MUST be identical to the Multicast- Flow 1546 TLV in the received Multicast Flow Query Request message. 1548 o Target TLV(s). The Target TLV MUST appear once per AN port on 1549 which the multicast flow identified in the preceding Multicast 1550 Flow TLV is active. 1552 The Multicast-Flow TLVs MUST appear in the response from the AN in 1553 the same order as in the query from the NAS. 1555 If the Multicast Flow Query Request contained no Target TLV and no 1556 Multicast Flow TLV, the AN MUST include, for each AN port currently 1557 receiving multicast flow(s), the following set of TLVs: 1559 o Target TLV. This MUST identify one AN port. 1561 o Multicast-Flow TLV(s). The Multicast-Flow TLV MUST appear once 1562 per Multicast Flow that is currently active on the AN port 1563 identified in the preceding Target TLV. 1565 If the contents of the Multicast Flow Query Request are in error, the 1566 AN MUST reply with a Multicast Flow Query Response message with the 1567 Result field set to Failure (0x4) and the Code field set to indicate 1568 the nature of the error. If the request contained multiple instances 1569 of the Target TLV or the Multicast-Flow TLV and one of these is in 1570 error, the response message MUST contain the results for the 1571 preceding instances of the TLV as if there had been no error. These 1572 successful results MUST be followed by the TLV in error, copied from 1573 the request. The AN MUST NOT do further processing of the request. 1574 The AN MAY add a Status-Info TLV to provide further information on 1575 the nature of the error. 1577 4.10. Committed Bandwidth Report Message 1579 This section describes the Committed Bandwidth Report message, which 1580 is sent from the AN to the NAS to report the most recent amount of 1581 multicast bandwidth usage committed to one or more access lines. 1583 The Message Type for the Committed Bandwidth Report message is 150. 1585 The Committed Bandwidth Report message contains one or more instances 1586 of the Committed-Bandwidth TLV, as described in Section 5.13. 1588 4.10.1. Sender Behaviour 1590 The sender of a Committed Bandwidth Report message MUST set the 1591 Result field to Ignore (0x0). The Code field MUST be set to 0x000. 1592 The sender MUST populate the ANCP Transaction Identifier field with a 1593 unique value, as described in section 4.4.1 of [I-D.ietf-ancp- 1594 protocol]. 1596 Each instance of the Committed-Bandwidth TLV included in the message 1597 MUST identify an access line for which the amount of committed 1598 multicast bandwidth has changed since the previous Committed 1599 Bandwidth Report message was sent and MUST report the latest amount 1600 of multicast bandwidth committed to that line. There MUST be only 1601 one instance of the Committed-Bandwidth TLV present in the message 1602 for any given access line. The message MUST include an instance of 1603 the Committed-Bandwidth TLV for every access line for which committed 1604 multicast bandwidth has changed since the previous Committed 1605 Bandwidth Report message was sent. 1607 Further behaviour at the AN is specified in Section 6.2.2. 1609 4.10.2. Receiver Behaviour 1611 The usage of the contents of a Committed Bandwidth Report message 1612 received by the NAS is implementation-dependent. One example is that 1613 the NAS uses the reports of multicast bandwidth commitments to adjust 1614 its forwarding scheduler operation to provide the intended level of 1615 QoS. 1617 The NAS MUST NOT reply to a valid Committed Bandwidth Report message. 1618 The NAS MAY send a Generic Response message indicating the nature of 1619 any errors detected in a Committed Bandwidth Report message that it 1620 has received. 1622 5. ANCP TLVs For Multicast 1624 This section defines new ANCP TLVs for the control of multicast 1625 flows. 1627 5.1. Multicast-Service-Profile TLV 1629 This document defines the new Multicast-Service-Profile TLV. 1631 The Multicast-Service-Profile TLV MAY be included in a Provisioning 1632 message as specified in Section 4.1. 1634 The Multicast-Service-Profile TLV is illustrated in Figure 6. It 1635 consists of a TLV header encapsulating a single instance of the 1636 Multicast-Service- Profile-Name TLV and one or more instances of the 1637 List-Action TLV. 1639 1 2 3 1640 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 1641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1642 |TLV Type = Mcast Serv Profile | TLV Length | 1643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1644 | Multicast-Service-Profile-Name TLV | 1645 | | 1646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1647 | List-Action TLV | 1648 | | 1649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1650 | ... | 1651 | | 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1653 | List-Action TLV | 1654 | | 1655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1657 Figure 6: Multicast-Service-Profile TLV 1659 The Multicast-Service-Profile TLV has the following fields: 1661 o The Multicast-Service-Profile TLV Type is 0x13. 1663 o The TLV length is determined by the contents following the TLV 1664 header. 1666 o The Multicast-Service-Profile-Name TLV is described in 1667 Section 5.2. The Multicast-Service-Profile-Name TLV MUST contain 1668 an identifier which is unique over all profiles provisioned to the 1669 same AN partition. This identifier will be used to refer to the 1670 profile when activating it for a given target within a Port 1671 Management message (see Section 4.2). 1673 o The List-Action TLV is described in Section 5.3. The List-Action 1674 TLV(s) provide the content of a newly defined multicast service 1675 profile or modify the existing content. If more than one List- 1676 Action TLV is present, the order of the TLVs may be significant, 1677 since List- Action TLVs are processed in the order in whch they 1678 appear. 1680 5.2. Multicast-Service-Profile-Name TLV 1682 The Multicast-Service-Profile-Name TLV carries the identifier of a 1683 multicast service profile provisioned on the AN. It is illustrated 1684 in Figure 7. 1686 1 2 3 1687 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 1688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1689 |TLV Type = MSP Name | TLV Length | 1690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1691 | Multicast service profile identifier | 1692 | | 1693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1695 Figure 7: Multicast-Service-Profile-Name TLV 1697 The Multicast-Service-Profile-Name TLV has the following fields: 1699 o The Multicast-Service-Profile-Name TLV Type is 0x18. 1701 o TLV Length: up to 255 octets. 1703 o Multicast service profile identifier: an opaque sequence of bits 1704 identifying a specific multicast service profile. 1706 The identifier could have the form of human-readable text or an 1707 arbitrary binary value, depending on the operator's practices. 1709 5.3. List-Action TLV 1711 The List-Action TLV identifies multicast flows to be added to or 1712 removed from a list of White-, Black-, or Grey-listed flows. It is 1713 meaningful only in association with a Multicast-Service-Profile-Name 1714 TLV identifying the profile to which the List-Action TLV applies. 1715 Such an association can be achieved by placing both TLVs in the same 1716 base message payload or as embedded TLVs of another TLV such as the 1717 Multicast-Service-Profile. The List-Action TLV is shown in Figure 8. 1719 1 2 3 1720 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 1721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1722 | TLV Type = List-Action TLV | TLV Length | 1723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1724 | Operation | List Type | Reserved | 1725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1726 | Address Family | Number of flow fields | 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1728 | Multicast flow fields | 1729 ...... 1730 | | 1731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1732 | Address Family | Number of flow fields | 1733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1734 | Multicast flow fields | 1735 ...... 1736 | | 1737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1739 Figure 8: List-Action TLV 1741 The List-Action TLV contains the following fields: 1743 o The List-Action TLV Type is 0x21. 1745 o TLV Length: length of the subsequent contents. 1747 o Operation: operation to be performed upon the White, Black, or 1748 Grey list identified by the List Type field within the profile 1749 identified by the associated Multicast-Service-Profile-Name 1750 embedded TLV. The possible values are: 1752 * Add (0x01): the multicast flow fields are to be added to the 1753 list. 1755 * Delete (0x02): the multicast flow fields are to be removed from 1756 the list. Each multicast flow field in the List-Action MUST 1757 match exactly an existing entry in the list concerned. Thus to 1758 remove part of the range provided by a wildcarded list entry, 1759 it is necessary to remove the entire entry and add back the 1760 remaining partial range(s). 1762 * Replace (0x03): the multicast flow fields replace the existing 1763 contents of the list. 1765 o List Type: the list type being modified by this List-Action. The 1766 possible values are White (0x01), Black (0x02), or Grey (0x03). 1768 o Reserved: a sender MUST set this field to 0x0000. A receiver MUST 1769 ignore the contents of this field. 1771 o Address Family: the IP version of the set of multicast flow fields 1772 that follow, encoded according to [PIMreg]. Possible values are 1773 0x0001 (IPv4) or 0x0002 (IPv6). Either an IPv4 list or an IPv6 1774 list or both MAY be present in the List-Action TLV. 1776 o Number of flow fields: the number of multicast flow fields of the 1777 given address family which follow. 1779 o Multicast flow field: a field identifying one or more multicast 1780 flows. It consists of an 8-bit group address prefix length, an 1781 8-bit source address prefix length, a 0-16 octet group prefix, and 1782 a 0-16 octet source prefix, as shown in Figure 9. 1784 Each multicast flow field refers either to a Source-Specific 1785 Multicast (SSM) channel or to an Any Source Multicast (ASM) group. 1786 The scope of the designation may be broadened to multiple channels or 1787 groups through use of prefix length values smaller than the total 1788 address length for the given address family. Multicast flow fields 1789 MUST be placed consecutively within the embedded TLV without 1790 intervening padding except to round out individual addresses to the 1791 nearest octet boundary. 1793 A multicast flow field consists of two single-octet prefix lengths 1794 followed by zero to two prefix values as shown in Figure 9: 1796 +-+-+-+-+-+-+-+-+ 1797 | Group PrefLen | 1798 +-+-+-+-+-+-+-+-+ 1799 | Source PrefLen| 1800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1801 | Group Prefix (multicast) (0 to 16 octets) | 1802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1803 | Source Prefix (unicast, SSM only) (0 to 16 octets) | 1804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 Figure 9: Organization of a Single Multicast Flow Field 1808 The prefix length has its usual meaning. It is the number of most- 1809 significant bits specified within the corresponding prefix. The 1810 prefix length MAY vary from 0 to 32 in the IPv4 sub-list, and from 0 1811 to 128 in the IPv6 sub-list. 1813 A value of 0x00 for either the Group PrefLen (prefix length) or the 1814 Source PrefLen indicates that any value of the corresponding address 1815 will match (wild card). If the value 0x00 is provided for a 1816 particular prefix length, the corresponding prefix MUST be omitted 1817 from the field contents. In particular, a value of 0x00 for the 1818 Source PrefLen indicates an ASM multicast entry, and the Source 1819 Prefix will be absent. 1821 The length of a Source or Group Prefix field is equal to (PrefLen + 1822 7)/8 octets, truncated to the nearest integer. Unused bits at the 1823 end of the prefix MUST be set to zeroes. 1825 5.4. Sequence-Number TLV 1827 The Sequence-Number TLV conveys a sequence number of some sort. The 1828 specific meaning of the sequence number is message-specific. Within 1829 this specification, the Sequence-Number TLV is used as a embedded TLV 1830 within a Status-Info TLV, in a Generic Response reporting a failed 1831 command within a Multicast Replication Control or Multicast Admission 1832 Request message. It identifies the sequence number within the 1833 message of the command that failed. 1835 The Sequence-Number TLV has the format shown in Figure 10. 1837 1 2 3 1838 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 1839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1840 |TLV Type = Sequence-Number | TLV Length = 4 | 1841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1842 | Sequence number | 1843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1845 Figure 10: Sequence-Number TLV 1847 The Sequence-Number TLV has the following fields: 1849 o The Sequence-Number TLV Type is 0x22. 1851 o TLV length is 0x0004. 1853 o Sequence number: the sequence number of a specific entity within a 1854 series, where numbering starts from 1 for the first entity in the 1855 series. Represented as a 32-bit binary number, most significant 1856 bit first. 1858 5.5. Bandwidth-Allocation TLV 1860 The Bandwidth-Allocation TLV is used to indicate the total amount of 1861 video bandwidth delegated to the AN for multicast admission control 1862 for a given access line, in kilobits per second. The TLV has the 1863 format shown in Figure 11. 1865 1 2 3 1866 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 1867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1868 |TLV Type = BW-Allocation | TLV Length = 4 | 1869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1870 | Delegated amount (kbits/s) | 1871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1873 Figure 11: The Bandwidth-Allocation TLV 1875 The Bandwidth-Allocation TLV has the following fields: 1877 o The Bandwidth-Allocation TLV Type is 0x15. 1879 o TLV length is 4. 1881 o Delegated amount: the bandwidth amount delegated to the AN for 1882 admission of multicast video on a given port, kilobits per second. 1883 Presented as a 32-bit binary value, most significant bit first. 1885 5.6. White-List-CAC TLV 1887 The White-List-CAC TLV is used to indicate that the NAS wishes the AN 1888 to do admission control for White-listed flows. Details on when the 1889 White-List-CAC TLV may be provisioned are specified in Section 6. 1890 The White- List-CAC TLV is illustrated in Figure 12. 1892 1 2 3 1893 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 1894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1895 |TLV Type = White-List-CAC | TLV Length = 0 | 1896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1898 Figure 12: White-List-CAC TLV 1900 The White-List-CAC TLV contains the following fields: 1902 o The White-List-CAC TLV Type is 0x24. 1904 o TLV length is 0, since the TLV contains no data other than the TLV 1905 header. 1907 5.7. MRepCtl-CAC TLV 1909 The MRepCtl-CAC TLV is used to indicate that the NAS wishes the AN to 1910 do admission control for flows added by the Multicast Replication 1911 Control message. Details on when the MRepCtl-CAC TLV may be 1912 provisioned are specified in Section 6. The MRepCtl-CAC TLV is 1913 illustrated in Figure 13. 1915 1 2 3 1916 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 1917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1918 |TLV Type = MRepCtl-CAC | TLV Length = 0 | 1919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1921 Figure 13: MRepCtl-CAC TLV 1923 The MRepCtl-CAC TLV contains the following fields: 1925 o The MRepCtl-CAC TLV Type is 0x25. 1927 o TLV length is 0, since the TLV contains no data other than the TLV 1928 header. 1930 5.8. Bandwidth-Request TLV 1932 The Bandwidth-Request TLV is used to request an adjustment of the 1933 total amount of video bandwidth allocated to the AN for multicast 1934 admission control for a given line. The "Required amount" field 1935 indicates the minimum adjustment required to meet the request. The 1936 "Preferred amount" field indicates the adjustment the requestor would 1937 prefer to have, if possible. Section 4.5 discusses the required 1938 relationships between the "Required amount", "Preferred amount", and 1939 current values of total bandwidth allocated to the AN. 1941 The Bandwidth-Request TLV has the format shown in Figure 14. 1943 1 2 3 1944 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 1945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1946 |TLV Type = Bandwidth-Request | TLV Length = 8 | 1947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1948 | Required amount (kbits/s) | 1949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1950 | Preferred amount (kbits/s) | 1951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1953 Figure 14: The Bandwidth-Request TLV 1955 The Bandwidth-Request TLV has the following fields: 1957 o The Bandwidth-Request TLV Type is 0x16. 1959 o The TLV length is 8 octets. 1961 o Required amount: the minimum or maximum amount, depending on 1962 whether the sender is the AN or the NAS respectively, of delegated 1963 video bandwidth that is being requested, in kilobits per second. 1964 Presented as a 32-bit binary value, most significant bit first. 1966 o Preferred amount: the preferred amount of delegated video 1967 bandwidth that is being requested, in kilobits per second. 1968 Presented as a 32-bit binary value, most significant bit first. 1970 5.9. Request-Source-IP TLV 1972 The Request-Source-IP TLV provides the IP address of the entity that 1973 originated a specific request to join or leave a multicast channel. 1974 The TLV is illustrated in Figure 15. 1976 1 2 3 1977 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 1978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1979 | TLV Type = Request-Source-IP | TLV length = 4 or 16 | 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 | Unicast Address | 1982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1984 Figure 15: Request-Source-IP TLV 1986 The Request-Source-IP TLV contains the following fields: 1988 o The Request-Source-IP TLV Type is 0x92. 1990 o TLV length is 4 for an IPv4 address or 16 for an IPv6 address. 1992 o Unicast address: IP address of the source of a multicast flow join 1993 request, in network byte order. 1995 5.10. Request-Source-MAC TLV 1997 The Request-Source-MAC TLV provides the MAC address of the entity 1998 that originated a specific request to join or leave a multicast 1999 channel. The TLV is illustrated in Figure 16. 2001 1 2 3 2002 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2004 |TLV Type=Request-Source-MAC | TLV Length = 6 or 8 | 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2006 | | 2007 +-+-+- IEEE MAC Address +-+-+-+ 2008 | | 2009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2011 Figure 16: Request-Source-MAC TLV 2013 The Request-Source-MAC TLV contains the following fields: 2015 o The Request-Source-MAC TLV Type is 0x93. 2017 o TLV length is either 6 octets (MAC-48 or EUI-48) or 8 octets 2018 (EUI-64). 2020 o IEEE MAC Address: MAC address of the device originating the 2021 request to join a multicast flow. Within the address, bytes and 2022 bits respectively shall be ordered from most to least significant, 2023 consistently with [IEEE48] for MAC-48 and EUI-48, and with 2024 [IEEE64] for EUI-64. 2026 EUI-48 and EUI-64 are registered trademarks of the IEEE. 2028 5.11. Multicast-Flow TLV 2030 The Multicast-Flow TLV specifies a multicast flow in terms of its 2031 multicast group address and, if applicable, its unicast source 2032 address. It is illustrated in Figure 17. 2034 1 2 3 2035 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 2036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2037 |TLV Type = Multicast-Flow | TLV Length | 2038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2039 | Flow Type | Addr Family | Reserved | 2040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2041 | Multicast Group Address | 2042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 2043 | Unicast Source Address (for SSM flows only) | 2044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2046 Figure 17: Multicast-Flow TLV 2048 The Multicast-Flow TLV has the following fields: 2050 o The Multicast-Flow TLV Type is 0x19. 2052 o TLV Length: ranges from a minimum of 8 (for an ASM IPv4 flow) to 2053 36 (for an IPv6 SSM flow. 2055 o Flow Type: 0x01 for Any Source Multicast (ASM), 0x02 for Specific- 2056 Source Multicast (SSM). 2058 o Addr Family: address family of the multicast source and group 2059 addresses, encoded in accordance with the IANA PIM Address Family 2060 registry ([PIMreg]). 0x01 indicates IPv4, 0x02 indicates IPv6. 2062 o Reserved: MUST be set to 0x0000 by the sender and MUST be ignored 2063 by the receiver. 2065 One possible use for this field in the future is to indicate 2066 the presence of PIM Join attributes attached to the source 2067 address (see [RFC5384]). The applicability of PIM attributes 2068 in the context of ANCP is for further study. 2070 o Multicast Group Address: a multicast group address within the 2071 given address family. The group address MUST always be present. 2073 o Unicast Source Address: unicast address within the given address 2074 family. If the Flow Type is 0x01 (ASM), a source address MUST NOT 2075 be present. If the Flow Type is 0x02 (SSM), a source address MUST 2076 be present. 2078 5.12. Report-Buffering-Time TLV 2080 The Report-Buffering-Time TLV provides the time for which a Committed 2081 Bandwidth Report message must be held with the intention of 2082 accumulating multiple reports of changed committed multicast 2083 bandwidth in one report, to reduce the volume of messages sent to the 2084 NAS. For further information see Section 6.2.2. The TLV is 2085 illustrated in Figure 18. 2087 1 2 3 2088 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 2089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2090 |TLV Type=Report-Buffering-Time | TLV Length = 4 | 2091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2092 | Buffering Time (ms) | 2093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2095 Figure 18: Report-Buffering-Time TLV 2097 The Report-Buffering-Time TLV contains the following fields: 2099 o The Report-Buffering-Time TLV Type is 0x94. 2101 o TLV length is 4 octets. 2103 o Buffering Time is a 32-bit unsigned integer containing a time 2104 value in ms. 2106 5.13. Committed-Bandwidth TLV 2108 The Committed-Bandwidth TLV identifies an access line and provides 2109 the current amount of multicast bandwidth that the AN has committed 2110 to it. The TLV is illustrated in Figure 19. 2112 1 2 3 2113 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 2114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2115 |TLV Type=Committed-Bandwidth | TLV Length (variable) | 2116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2117 | Committed Multicast Bandwidth (kbits/s) | 2118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2119 | | 2120 +-+-+- Target TLV +-+-+-+ 2121 | | 2122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2124 Figure 19: Committed-Bandwidth TLV 2126 The Committed-Bandwidth TLV contains the following fields: 2128 o The Committed-Bandwidth TLV Type is 0x95. 2130 o TLV length is 4 octets plus the length of the Target TLV including 2131 its header and any padding. 2133 o Committed Multicast Bandwidth is a 32-bit unsigned integer 2134 providing a bandwidth amount in kbits/s. 2136 o The Target TLV identifies the access line to which this amount of 2137 multicast bandwidth is currently committed. 2139 6. Multicast Capabilities 2141 Section 4.3 of [I-D.ietf-ancp-protocol] defines a capability 2142 negotiation mechanism as well as a number of capabilities. This 2143 section defines five new capabilities in support of different modes 2144 of multicast operation: 2146 o NAS-initiated replication (capability type 0x03); 2148 o committed multicast bandwidth reporting (capability type 0x05); 2150 o conditional access with white and black lists (capability type 2151 0x06); 2153 o conditional access with grey lists (capability type 0x07); 2155 o bandwidth delegation (capability type 0x08). 2157 The "Capability Data" field within the Capability TLV for all of 2158 these capabilities is empty. All of these capabilities are 2159 independent of the access technology. 2161 The remainder of this section consists of three sub-sections. 2162 Section 6.1 specifies the protocol elements that must be implemented 2163 in order to support each capability. Section 6.2 specifies the 2164 procedures that apply to each capability on its own. Section 6.3 2165 specifies how the capabilities interact if more than one multicast 2166 capability is included in the set of capabilities negotiated between 2167 the AN and the NAS. 2169 Note that if a request contains content that is not supported 2170 (according to the tables in Section 6.1) by the negotiated set of 2171 multicast capabilities, the appropriate response is to return a 2172 Generic Response message indicating Failure (0x4) with an appropriate 2173 code value (e.g., 84 "TLV or value not supported by negotiated 2174 capability set"). The body of the message MUST contain a Status-Info 2175 TLV. See Sections 6.1.3 and 6.2.3 in [I-D.ietf-ancp-protocol] for 2176 more details. 2178 6.1. Required Protocol Support 2180 This section specifies the protocol elements that MUST be implemented 2181 to support each of the four multicast capabilities. Support of 2182 multiple multicast capabilities requires implementation of the union 2183 of the sets of protocol elements applying to each of the individual 2184 capabilities in the supported set. 2186 6.1.1. Protocol Requirements For NAS-initiated Replication 2188 Table 1 specifies the protocol elements within Section 4 and 2189 Section 5 that MUST be implemented to support the NAS-initiated 2190 replication multicast capability. 2192 +--------------+----------------------------------------------------+ 2193 | Reference | Protocol Element | 2194 +--------------+----------------------------------------------------+ 2195 | Section 4.1 | Provisioning message with MRepCtl-CAC TLV | 2196 | | | 2197 | Section 4.2 | Port Management message with Bandwidth-Allocation | 2198 | | TLV. | 2199 | | | 2200 | Section 4.3 | Multicast Replication Control message | 2201 | | | 2202 | Section 4.9 | Multicast Flow Query Request and Response messages | 2203 | | | 2204 | Section 5.4 | Command Number TLV | 2205 | | | 2206 | Section 5.7 | MRepCtl-CAC TLV | 2207 | | | 2208 | Section 5.11 | Multicast-Flow TLV | 2209 +--------------+----------------------------------------------------+ 2211 Table 1: Protocol Requirements For NAS-initiated Replication 2213 6.1.2. Protocol Requirements For Committed Multicast Bandwidth 2214 Reporting 2216 Table 2 specifies the protocol elements within Section 4 and 2217 Section 5 that MUST be implemented to support the NAS-initiated 2218 replication multicast capability. 2220 +--------------+----------------------------------------------------+ 2221 | Reference | Protocol Element | 2222 +--------------+----------------------------------------------------+ 2223 | Section 4.1 | Provisioning message with Report-Buffering-Time | 2224 | | TLV | 2225 | | | 2226 | Section 4.10 | Committed Bandwidth Report message | 2227 | | | 2228 | Section 4.9 | Multicast Flow Query Request and Response messages | 2229 | | | 2230 | Section 5.12 | Report-Buffering-Timer TLV | 2231 | | | 2232 | Section 5.13 | Committed-Bandwidth TLV | 2233 | | | 2234 | Section 5.11 | Multicast-Flow TLV | 2235 +--------------+----------------------------------------------------+ 2237 Table 2: Protocol Requirements For Committed Multicast Bandwidth 2238 Reporting 2240 6.1.3. Protocol Requirements For Conditional Access With White and 2241 Black Lists 2243 Table 3 specifies the protocol elements within Section 4 and 2244 Section 5 that MUST be implemented to support the conditional access 2245 with white and black lists multicast capability. 2247 +--------------+----------------------------------------------------+ 2248 | Reference | Protocol Element | 2249 +--------------+----------------------------------------------------+ 2250 | Section 4.1 | Provisioning message with | 2251 | | Multicast-Service-Profile TLV, White and Black | 2252 | | lists only, and White-List-CAC TLV | 2253 | | | 2254 | Section 4.2 | Port Management message with | 2255 | | Multicast-Service-Profile-Name and | 2256 | | Bandwidth-Allocation TLVs. | 2257 | | | 2258 | Section 4.9 | Multicast Flow Query Request and Response messages | 2259 | | | 2260 | Section 5.1 | Multicast-Service-Profile TLV | 2261 | | | 2262 | Section 5.2 | Multicast-Service-Profile-Name TLV | 2263 | | | 2264 | Section 5.3 | List-Action TLV, White and Black lists only | 2265 | | | 2266 | Section 5.5 | Bandwidth-Allocation TLV | 2267 | | | 2268 | Section 5.6 | White-List-CAC TLV | 2269 | | | 2270 | Section 5.11 | Multicast-Flow TLV | 2271 +--------------+----------------------------------------------------+ 2273 Table 3: Protocol Requirements For Conditional Access with White and 2274 Black Lists 2276 6.1.4. Protocol Requirements For Conditional Access With Grey Lists 2278 Table 4 specifies the protocol elements within Section 4 and 2279 Section 5 that MUST be implemented to support the conditional access 2280 with grey lists multicast capability. 2282 +--------------+----------------------------------------------------+ 2283 | Reference | Protocol Element | 2284 +--------------+----------------------------------------------------+ 2285 | Section 4.1 | Provisioning message with | 2286 | | Multicast-Service-Profile TLV, Grey lists only, | 2287 | | and MRepCtl-CAC TLV | 2288 | | | 2289 | Section 4.2 | Port Management message with | 2290 | | Multicast-Service-Profile-Name and | 2291 | | Bandwidth-Allocation TLVs. | 2292 | | | 2293 | Section 4.3 | Multicast Replication Control message | 2294 | | | 2295 | Section 4.4 | Multicast Admission Control Message | 2296 | | | 2297 | Section 4.9 | Multicast Flow Query Request and Response messages | 2298 | | | 2299 | Section 5.1 | Multicast-Service-Profile TLV, Grey lists only | 2300 | | | 2301 | Section 5.2 | Multicast-Service-Profile-Name TLV | 2302 | | | 2303 | Section 5.3 | List-Action TLV, Grey lists only | 2304 | | | 2305 | Section 5.4 | Command Number TLV | 2306 | | | 2307 | Section 5.5 | Bandwidth-Allocation TLV | 2308 | | | 2309 | Section 5.7 | MRepCtl-CAC TLV | 2310 | | | 2311 | Section 5.9 | Request-Source-IP TLV | 2312 | | | 2313 | Section 5.10 | Request-Source-MAC TLV | 2314 | | | 2315 | Section 5.11 | Multicast-Flow TLV | 2316 +--------------+----------------------------------------------------+ 2318 Table 4: Protocol Requirements For Conditional Access with Grey Lists 2320 6.1.5. Protocol Requirements For Delegated Bandwidth 2322 Table 5 specifies the protocol elements within Section 4 and 2323 Section 5 that MUST be implemented to support the delegated bandwidth 2324 multicast capability. 2326 +--------------+----------------------------------------------------+ 2327 | Reference | Protocol Element | 2328 +--------------+----------------------------------------------------+ 2329 | Section 4.2 | Port Management message with Bandwidth-Allocation | 2330 | | TLV. | 2331 | | | 2332 | Section 4.5 | Bandwidth Reallocation Request Message | 2333 | | | 2334 | Section 4.6 | Bandwidth Transfer Message | 2335 | | | 2336 | Section 4.7 | Delegated Bandwidth Query Request Message | 2337 | | | 2338 | Section 4.8 | Delegated Bandwidth Query Response Message | 2339 | | | 2340 | Section 4.9 | Multicast Flow Query Request and Response messages | 2341 | | | 2342 | Section 5.5 | Bandwidth-Allocation TLV | 2343 | | | 2344 | Section 5.8 | Bandwidth-Request TLV | 2345 | | | 2346 | Section 5.11 | Multicast-Flow TLV | 2347 +--------------+----------------------------------------------------+ 2349 Table 5: Protocol Requirements For Delegated Bandwidth 2351 6.2. Capability-Specific Procedures for Providing Multicast Service 2353 This section describes multicast service procedures for each 2354 capability as if it were the only multicast capability within the 2355 negotiated set. Procedures involving combinations of multicast 2356 capabilities are described in Section 6.3. 2358 The use of the Multicast Flow Query Request and Response messages to 2359 determine the association between multicast flows and ports is common 2360 to all multicast capabilities. No additional text is required here, 2361 beyond that already given in Section 4.9 to describe the use of those 2362 messages. 2364 6.2.1. Procedures For NAS-Initiated Replication 2366 NAS-initiated replication MAY be negotiated to support a mode of 2367 operation where IGMP/MLD requests are terminated on the NAS. 2368 Alternatively, it MAY be negotiated to allow the NAS to respond to 2369 requests sent by other means (e.g., through application signalling) 2370 that require the replication of multicast channels to a given access 2371 line. 2373 6.2.1.1. Provisioning 2375 The NAS MAY perform admission control for NAS-initiated replication. 2376 In this case, it MUST NOT include the MRepCtl-CAC TLV in a 2377 Provisioning message sent to the AN. Alternatively, the NAS MAY 2378 enable admission control at the AN for NAS-initiated replication. To 2379 do this, it MUST include the MRepCtl-CAC TLV in a Provisioning 2380 message sent to the AN and it MUST also include a Bandwidth- 2381 Allocation TLV in a Port Management message for each access line. 2383 6.2.1.2. Multicast Service Procedures 2385 The procedures associated with NAS-initiated replication are 2386 straightforward. To initiate replication, the NAS MUST send a 2387 Multicast Replication Control message to the AN, containing one or 2388 more commands adding flows, as described in Section 4.3.1. To 2389 terminate replication the NAS MUST send a Multicast Replication 2390 Control message where the commands delete instead of adding the 2391 flows. The AN acts upon these messages as specified in 2392 Section 4.3.2. 2394 6.2.2. Procedures For Committed Bandwidth Reporting 2396 Committed bandwidth reporting MAY be negotiated if the NAS requires 2397 current knowledge of the amount of multicast bandwidth committed to 2398 each access line and cannot obtain this information by other means. 2400 6.2.2.1. Provisioning 2402 The default buffering time when committed bandwidth reporting is 2403 enabled is zero (immediate reporting). To change this, the NAS MAY 2404 send an instance of the Report-Buffering-Time TLV containing a non- 2405 zero time value to the AN in a Provisioning message. If the NAS 2406 subsequently wishes to change the buffering time again, it MAY do so 2407 in another Provisioning message. 2409 6.2.2.2. Multicast Service Procedures 2411 If the buffering time for committed bandwidth reporting is zero, the 2412 AN MUST send a Committed Bandwidth Report message to the NAS each 2413 time the amount of multicast bandwidth committed to any access line 2414 under its control changes. 2416 If a non-zero value is provided in the Report-Buffering-Time TLV, the 2417 AN at any given moment is in one of two states: not-buffering, or 2418 buffering. The AN enters buffering state if it is in not-buffering 2419 state and the multicast bandwidth amount committed to some access 2420 line changes. It leaves buffering state when the AN sends a 2421 Committed Bandwidth Report. 2423 Upon entry to the buffering state, the AN MUST start a buffering 2424 timer and create a Committed Bandwidth Report message containing a 2425 Committed-Bandwidth TLV for the triggering access line, but MUST NOT 2426 send it. If a multicast bandwidth change occurs for another access 2427 line, the AN MUST add a new Committed-Bandwidth TLV to the message 2428 for that additional line. If a multicast bandwidth change occurs for 2429 a line for which a Committed-Bandwidth TLV is already present in the 2430 buffered report, the AN MUST update the Committed-Bandwidth TLV to 2431 contain the new bandwidth value, rather than adding another 2432 Committed-Bandwidth TLV for the same access line. 2434 The buffering timer expires after the period provided by the Report- 2435 Buffering-Time TLV. When it expires, the AN MUST send the Committed 2436 Bandwidth Report message that it has been accumulating to the NAS. 2437 Exceptionally, the AN MAY choose to send the message before the timer 2438 expires, in which case it MUST clear the buffering timer when the 2439 message is sent. In either case, the AN enters the not-buffering 2440 state as a result. 2442 Report buffering implies that NAS reaction to changes in multicast 2443 bandwidth usage is delayed by the amount of the buffering period. 2444 The choice of buffering period must take this into consideration. 2446 6.2.3. Procedures For Conditional Access With Black and White Lists 2448 6.2.3.1. Provisioning 2450 The NAS provisions named multicast service profiles containing White 2451 and Black lists on the AN using the Provisioning message containing 2452 one or more Multicast-Service-Profile TLVs. The NAS MAY update the 2453 contents of these profiles from time to time as required, by sending 2454 additional Provisioning messages with Multicast-Service-Profile TLVs 2455 containing incremental modifications to the existing White and Black 2456 lists or replacements for them. 2458 The NAS assigns a specific multicast service profile to an individual 2459 access line using the Port Management message containing a Multicast- 2460 Service-Profile-Name TLV. The NAS MAY change the multicast service 2461 profile for a given access line at any time by sending a Port 2462 Management message identifying a new multicast service profile. 2464 The NAS MAY choose to enable admission control at the AN for White- 2465 listed flows. To do this, it MUST send a Provisioning message as 2466 described in Section 4.1, which includes the White-List-CAC TLV and 2467 it MUST provide a multicast bandwidth allocation for each access line 2468 by including a Bandwidth-Allocation TLV in a Port Management message. 2470 6.2.3.2. Multicast Service Procedures 2472 The conditional access with White and Black lists capability assumes 2473 that IGMP/MLD requests are terminated on the AN. When the AN 2474 receives a "join" request, it MUST check to see whether the requested 2475 flow is White-listed or Black-listed as described below. Requests 2476 for Black-listed flows MUST be discarded. If the NAS has enabled 2477 admission control on the AN as described in the previous section, but 2478 a White-listed flow would cause the amount of committed multicast 2479 bandwidth to exceed the provisioned limit, the request MUST be 2480 discarded. The AN replicates flows passing these checks to the 2481 access line. 2483 To determine if a requested flow is White-listed, the AN searches for 2484 a best match to the flow in the applicable multicast service profile. 2485 Matching is done on the prefixes specified in the profile, ignoring 2486 the address bits of lower order than those in the prefix. 2488 If the requested multicast flow matches multiple lists associated 2489 with the access line, then the most specific match will be considered 2490 by the AN. If the most specific match occurs in multiple lists, the 2491 Black list entry takes precedence over the White list. In this 2492 context, the most specific match is defined as: 2494 o first, most specific match (longest prefix length) on the 2495 multicast flow address (i.e., on G of ) 2497 o then, most specific match (longest prefix length) on the unicast 2498 source address (i.e. on S of ) 2500 If the requested multicast flow is not part of any list, the join 2501 message SHOULD be discarded by the AN. This default behavior can 2502 easily be changed by means of a "catch-all" statement in the White 2503 list. For instance, adding () in the White List would make 2504 the default behavior to accept join messages for a multicast flow 2505 that has no other match on any list. 2507 When the AN receives a "leave" request, it terminates replication of 2508 the multicast flow. 2510 If the AN receives a Provisioning message which updates an existing 2511 multicast service profile, the AN MUST review the status of active 2512 flows on all ports to which the updated profile is currently 2513 assigned. Similarly, if a Port Management message assigns a new 2514 multicast service profile to a given port, the AN MUST review all 2515 active flows on that port. If the most specific match for any flow 2516 is a Black list entry, the flow MUST be terminated immediately. If 2517 any of the remaining flows do not match an entry in the White list, 2518 they also MUST be terminated immediately. White listed flows MUST be 2519 allowed to continue. 2521 6.2.4. Procedures For Conditional Access With Grey Lists 2523 6.2.4.1. Provisioning 2525 The NAS provisions named multicast service profiles containing Grey 2526 lists on the AN using the Provisioning message containing one or more 2527 Multicast-Service-Profile TLVs. The NAS MAY update the contents of 2528 these profiles from time to time as required, by sending additional 2529 Provisioning messages with Multicast-Service-Profile TLVs containing 2530 incremental modifications to the existing Grey lists or replacements 2531 for them. 2533 The NAS assigns a specific multicast service profile to an individual 2534 access line using the Port Management message containing a Multicast- 2535 Service-Profile-Name TLV. The NAS MAY change profiles on the line by 2536 sending a subsequent Port Management message identifying a new 2537 profile. 2539 The NAS MAY perform admission control for grey-listed flows. In that 2540 case, the NAS MUST NOT include the MRepCtl-CAC TLV in a Provisioning 2541 message sent to the AN. Alternatively, the NAS MAY enable admission 2542 control at the AN for Grey-listed flows. To do this, it MUST include 2543 the MRepCtl-CAC TLV in a Provisioning message sent to the AN and MUST 2544 also provide a Bandwidth- Allocation TLV in a Port Management message 2545 for each access line. 2547 6.2.4.2. Multicast Service Procedures 2549 The conditional access with Grey lists capability assumes that IGMP/ 2550 MLD requests are terminated on the AN. When the AN receives a "join" 2551 request, it MUST determine whether there is a match to the requested 2552 flow in the Grey list of the multicast service profile provisioned 2553 against the given access line. If there is no match, the request is 2554 discarded. Otherwise, the AN MUST send a Multicast Admission Control 2555 message to the NAS with content identifying the access line and the 2556 multicast flow to be added. As indicated in Section 4.4, the AN MAY 2557 add information identifying the requestor by IP address and/or MAC 2558 address. 2560 If the NAS decides to enable the flow, it MUST send a Multicast 2561 Replication Control request to the AN to replicate the flow to the 2562 access line with the Result field set to Nack (0x1), as described in 2563 Section 4.3.1. 2565 When the AN receives the Multicast Replication Control request, it 2566 performs admission control if admission control has been enabled as 2567 described in the previous section. If admitting the flow would cause 2568 the committed multicast bandwidth at the access line to exceed the 2569 provisioned limit, the AN reports an error to the NAS as described in 2570 Section 4.3.2. Otherwise it replicates the multicast flow as 2571 requested. 2573 If the NAS decides not to permit the flow, it MAY send a Multicast 2574 Replication Control message in response to the Multicast Admission 2575 Control message to allow the AN to update its internal records. The 2576 content of this message is described in Section 4.4.2. 2578 When the AN receives a "leave" request, it MUST terminate replication 2579 of the flow to the access line. It MUST then send a Multicast 2580 Admission Control message to the NAS indicating the deletion. The 2581 NAS updates its internal records but MUST NOT respond to the message. 2583 If the AN receives a Provisioning message which updates an existing 2584 multicast service profile, the AN MUST review the status of active 2585 flows on all ports to which the updated profile has been assigned. 2586 Similarly, if a Port Management message that assigns a new profile to 2587 a given port, the AN MUST review all active flows on that port. In 2588 either case, if any flow does not match an entry in the Grey list, it 2589 MUST be terminated immediately. 2591 6.2.5. Procedures For Delegated Bandwidth 2593 6.2.5.1. Provisioning 2595 The NAS SHOULD provision an initial amount of delegated multicast 2596 bandwidth for each access line using the Port Management message 2597 containing the Bandwidth-Allocation TLV. 2599 If it fails to do so and a value has not been provisioned on the 2600 AN by other means, the AN will be forced to request a bandwidth 2601 allocation as soon as it receives a "join" request. 2603 The NAS MAY at any time force an update of the amount of delegated 2604 bandwidth by the same means. 2606 6.2.5.2. Multicast Service Procedures 2608 The delegated bandwidth capability assumes that IGMP/MLD requests are 2609 terminated on the AN. When the AN receives a "join" request, it 2610 checks whether it has sufficient remaining uncommitted multicast 2611 bandwidth on the access line to accommodate the new multicast flow. 2612 If not, it MAY send a request to the NAS for an increased allocation 2613 of delegated bandwidth, using the Bandwidth Reallocation Request 2614 message. The NAS MUST return a Bandwidth Transfer message indicating 2615 whether it has granted the request, and if so, what is the new amount 2616 of delegated bandwidth. 2618 If the AN has sufficient uncommitted multicast capacity to admit the 2619 request, either originally or as the result of a successful request 2620 to the NAS, it replicates the requested flow to the access line. 2621 Otherwise it discards the request. 2623 When the AN receives a "leave" request for an active flow, it ceases 2624 replication. 2626 The NAS or AN MAY at some point detect that their respective views of 2627 the amount of delegated bandwidth are inconsistent. If so, they can 2628 recover using procedures described in Section 4.5 and Section 4.6. 2629 As a further aid to synchronization, either the NAS or the AN MAY 2630 from time to time check the peer's view of the amount of delegated 2631 bandwidth using the Delegated Bandwidth Query message. 2633 The NAS or AN MAY at any time release bandwidth to the peer using an 2634 autonomous Bandwidth Transfer message. The contents of this message 2635 are described in Section 4.6. 2637 6.3. Combinations of Multicast Capabilities 2639 6.3.1. Combination of Conditional Access With White and Black Lists and 2640 Conditional Access With Grey Lists 2642 If conditional access with White and Black lists is combined with 2643 conditional access with Grey lists, provisioning of the multicast 2644 service profiles is as described in Section 6.2.3.1 except that 2645 multicast service profiles will also include Grey lists. Admission 2646 control is enabled independently on the AN for White lists by 2647 including the White-list-CAC TLV in the Provisioning message and for 2648 Grey lists by including the MRepCtl-CAC TLV in the Provisioning 2649 message. The Bandwidth-Allocation TLV provisions an amount that 2650 applies to both White- and Grey- listed flows if admission control is 2651 enabled for both. 2653 With regard to multicast service procedures, one point of difference 2654 from the individual capabilities must be noted. This is an 2655 interaction during the profile matching procedure. The AN MUST seek 2656 the best match amongst multiple lists as described in 2657 Section 6.2.3.2. However, if there are multiple matches of equal 2658 precision, the order of priority is Black list first, Grey list 2659 second, and White list last. 2661 Once profile matching has been completed, processing of a "join" 2662 request is as described in Section 6.2.3.2 for White or Black listed 2663 flows or Section 6.2.4.2 for Grey listed flows. Requests that do not 2664 match any list SHOULD be discarded. 2666 When the AN receives a "leave" request, it MUST terminate replication 2667 of the flow to the access line. If the flow was Grey-listed, the AN 2668 MUST then send a Multicast Admission Control message to the NAS 2669 indicating the deletion. Thus the AN needs to retain the fact that 2670 the flow was Grey-listed for the life of the flow. 2672 If the AN receives a Provisioning message which updates an existing 2673 multicast service profile, the AN MUST review the status of active 2674 flows on all ports to which the updated profile is currently 2675 assigned. Similarly, if a Port Management message assigns a new 2676 multicast service profile to a given port, the AN MUST review all 2677 active flows on that port. If any flow has its most specific match 2678 in a Black list entry, it MUST be terminated immediately. If any of 2679 the remaining flows do not match an entry in the White or Grey list, 2680 they MUST also be terminated immediately. Finally, if any remaining 2681 flows were originally admitted because they were White-listed, but 2682 after the change they are Grey- listed, the AN MUST generate a 2683 Multicast Flow Query response message autonomously as if it were 2684 responding to a Multicast Flow Query request, listing all such flows. 2685 These flows MUST be allowed to continue until the NAS or the 2686 subscriber terminates them. Flows with their most specific match in 2687 the White list MUST be allowed to continue. 2689 The autonomously-generated Multicast Flow Query response message MUST 2690 be formatted as if it were a successful response to a request 2691 containing no Target and no Multicast-Flow TLV, as described in 2692 Section 4.9.2, with the exception that the Transaction-Id MUST be set 2693 to all zeroes. 2695 6.3.2. Combination of Conditional Access With Delegated Bandwidth 2697 The provisioning and bandwidth management procedures of Section 6.2.5 2698 apply in addition to the procedures in Section 6.2.3, Section 6.2.4, 2699 or Section 6.3.1 as applicable. Admission control follows the rules 2700 for conditional access in terms of matching flows against White and 2701 Black and/or Grey lists and performing or not performing bandwidth 2702 checks at the AN, but the amount of bandwidth used by the AN to 2703 perform admission control is negotiable as described in 2704 Section 6.2.5.2. 2706 6.3.3. Combination of NAS-Initiated Replication with Other Capabilities 2708 NAS-initiated replication can coexist with the other capabilities, 2709 but some means must exist to prevent double replication of flows. 2711 The simplest way to do this is to terminate all IGMP/MLD requests on 2712 the AN, so that NAS-initiated replication is stimulated only by 2713 signalling through other channels. Other arrangements are possible, 2714 but need not be discussed here. 2716 Assuming the necessary separation of responsibilities, the only point 2717 of interaction between NAS-initiated replication and the other 2718 multicast capabilities is in the area of admission control. 2719 Specifically, inclusion of the MRepCtl-CAC TLV in a Provisioning 2720 message and the Bandwidth-Allocation TLV in a Port Management message 2721 enables admission control by the AN for flows added by Multicast 2722 Replication Control messages, regardless of whether they are part of 2723 NAS-initiated replication or Grey list multicast service processing. 2724 Conversely, non inclusion of the MRepCtl-CAC TLV in Provisioning 2725 messages to the AN enables admission control by the NAS for flows 2726 added by Multicast Replication Control messages, regardless of 2727 whether they are part of NAS- initiated replication or Grey list 2728 multicast service processing. Admission Control for white flows can 2729 also be enabled independently on the AN by inclusion by the NAS of 2730 the White-List-CAC TLV in the Provisioning message. 2732 6.3.4. Combinations of Committed Bandwidth Reporting with Other 2733 Multicast Capabilities 2735 Committed bandwidth reporting can take independently of which other 2736 multicast capabilities have been negotiated. However, some 2737 combinations do not make sense because of redundancy. In particular, 2738 the NAS obtains the same information that committed bandwidth 2739 reporting gives if the only other capabilities operating are NAS- 2740 initiated replication and/or conditional access with Grey lists. 2742 7. Security Considerations 2744 The security considerations of ANCP are discussed in 2745 [I-D.ietf-ancp-protocol] and in [I-D.ietf-ancp-security-threats]. 2746 [Probably need to say more, but will do so later.] 2748 8. IANA Considerations 2750 RFC EDITOR'S NOTE: Please replace XXXX with the RFC number of this 2751 document. 2753 This document defines the following additional values within the 2754 GSMPv3 Message Type Name Space registry, under the new heading 2755 "Multicast Extensions To ANCP/GSMPv3": 2757 +-----------------------------+----------------+--------+-----------+ 2758 | Message Name | Message Number | Status | Reference | 2759 +-----------------------------+----------------+--------+-----------+ 2760 | Multicast Replication | 144 | | RFC XXXX | 2761 | Control | | | | 2762 | | | | | 2763 | Multicast Admission Control | 145 | | RFC XXXX | 2764 | | | | | 2765 | Bandwidth Reallocation | 146 | | RFC XXXX | 2766 | Request | | | | 2767 | | | | | 2768 | Bandwidth Transfer | 147 | | RFC XXXX | 2769 | | | | | 2770 | Delegated Bandwidth Query | 148 | | RFC XXXX | 2771 | | | | | 2772 | Multicast Flow Query | 149 | | RFC XXXX | 2773 | | | | | 2774 | Committed Bandwidth Report | 150 | | RFC XXXX | 2775 +-----------------------------+----------------+--------+-----------+ 2777 This document defines the following additional values for the GSMPv3 2778 Failure Response Message Name Space registry: 2780 +-------+-----------------------------------------------+-----------+ 2781 | Value | Failure Response Message Name | Reference | 2782 +-------+-----------------------------------------------+-----------+ 2783 | 100 | Command error. | RFC XXXX | 2784 | | | | 2785 | 101 | Bad flow address. | RFC XXXX | 2786 | | | | 2787 | 102 | Multicast flow does not exist. | RFC XXXX | 2788 | | | | 2789 | 103 | Invalid preferred bandwidth amount. | RFC XXXX | 2790 | | | | 2791 | 104 | Inconsistent views of delegated bandwidth | RFC XXXX | 2792 | | amount. | | 2793 | | | | 2794 | 105 | Bandwidth request conflict. | RFC XXXX | 2795 +-------+-----------------------------------------------+-----------+ 2796 This document defines the following additional values within the ANCP 2797 TLV Type Registry: 2799 +--------------------------------+-----------+-----------+ 2800 | TLV Name | Type Code | Reference | 2801 +--------------------------------+-----------+-----------+ 2802 | Multicast-Service-Profile | 0x13 | RFC XXXX | 2803 | | | | 2804 | Bandwidth-Allocation | 0x15 | RFC XXXX | 2805 | | | | 2806 | Bandwidth-Request | 0x16 | RFC XXXX | 2807 | | | | 2808 | Multicast-Service-Profile-Name | 0x18 | RFC XXXX | 2809 | | | | 2810 | Multicast-Flow | 0x19 | RFC XXXX | 2811 | | | | 2812 | List-Action | 0x21 | RFC XXXX | 2813 | | | | 2814 | Sequence-Number | 0x22 | RFC XXXX | 2815 | | | | 2816 | White-List-CAC | 0x24 | RFC XXXX | 2817 | | | | 2818 | MRepCtl-CAC | 0x25 | RFC XXXX | 2819 | | | | 2820 | Request-Source-IP | 0x92 | RFC XXXX | 2821 | | | | 2822 | Request-Source-MAC | 0x93 | RFC XXXX | 2823 | | | | 2824 | Report-Buffering-Time | 0x94 | RFC XXXX | 2825 | | | | 2826 | Committed-Bandwidth | 0x95 | RFC XXXX | 2827 +--------------------------------+-----------+-----------+ 2829 This document defines the following additional values for the ANCP 2830 Command Code registry: 2832 +--------------------------------------+----------------+-----------+ 2833 | Command Code Directive Name | Command Code | Reference | 2834 | | Value | | 2835 +--------------------------------------+----------------+-----------+ 2836 | Add | 0x01 | RFC XXXX | 2837 | | | | 2838 | Delete | 0x02 | RFC XXXX | 2839 | | | | 2840 | Delete All | 0x03 | RFC XXXX | 2841 | | | | 2842 | Admission Control Reject | 0x04 | RFC XXXX | 2843 | | | | 2844 | Conditional Access Reject | 0x05 | RFC XXXX | 2845 | | | | 2846 | Admission Control and Conditional | 0x06 | RFC XXXX | 2847 | Access Reject | | | 2848 +--------------------------------------+----------------+-----------+ 2850 This document defines the following additional values for the ANCP 2851 Capability registry: 2853 +------------------------------------+------------------+-----------+ 2854 | Capability Type Name | Capability Type | Reference | 2855 | | Code | | 2856 +------------------------------------+------------------+-----------+ 2857 | NAS-initiated replication | 0x3 | RFC XXXX | 2858 | | | | 2859 | Committed bandwidth reporting | 0x5 | RFC XXXX | 2860 | | | | 2861 | Conditional access with white and | 0x6 | RFC XXXX | 2862 | black lists | | | 2863 | | | | 2864 | Conditional access with grey lists | 0x7 | RFC XXXX | 2865 | | | | 2866 | Bandwidth delegation | 0x8 | RFC XXXX | 2867 +------------------------------------+------------------+-----------+ 2869 9. Acknowledgements 2871 The authors would like to acknowledge Wojciech Dec for providing 2872 useful input to this document, Robert Rennison for his help in 2873 shaping the definition of the Multicast-Service-Profile TLV, Shridhar 2874 Rao for his comments and suggestions and Aniruddha A for his proposal 2875 that formed the base of the Multicast Flow Reporting solution. 2876 Philippe Champagne, Sanjay Wadhwa and Stefaan De Cnodder provided 2877 substantial contributions on the solution for the NAS initiated 2878 multicast control use case. Kristian Poscic provided the committed 2879 bandwidth reporting use case. 2881 10. References 2883 10.1. Normative References 2885 [I-D.ietf-ancp-protocol] 2886 Wadhwa, S., Moisand, J., Haag, T., Voigt, N., and T. 2887 Taylor, "Protocol for Access Node Control Mechanism in 2888 Broadband Networks", draft-ietf-ancp-protocol-15 (work in 2889 progress), February 2011. 2891 [IEEE48] IEEE, "http://standards.ieee.org/regauth/oui/tutorials/ 2892 EUI48.html", 2010. 2894 [IEEE64] IEEE, "http://standards.ieee.org/regauth/oui/tutorials/ 2895 EUI64.html", 2010. 2897 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2898 Requirement Levels", BCP 14, RFC 2119, March 1997. 2900 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 2901 Listener Discovery (MLD) for IPv6", RFC 2710, 2902 October 1999. 2904 [RFC3292] Doria, A., Hellstrand, F., Sundell, K., and T. Worster, 2905 "General Switch Management Protocol (GSMP) V3", RFC 3292, 2906 June 2002. 2908 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 2909 Thyagarajan, "Internet Group Management Protocol, Version 2910 3", RFC 3376, October 2002. 2912 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 2913 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 2915 10.2. Informative References 2917 [I-D.ietf-ancp-security-threats] 2918 Moustafa, H., Tschofenig, H., and S. Cnodder, "Security 2919 Threats and Security Requirements for the Access Node 2920 Control Protocol (ANCP)", 2921 draft-ietf-ancp-security-threats-08 (work in progress), 2922 July 2009. 2924 [I-D.morin-mboned-igmpmld-error-feedback] 2925 Morin, T. and B. Haberman, "IGMP/MLD Error Feedback", 2926 draft-morin-mboned-igmpmld-error-feedback-02 (work in 2927 progress), November 2008. 2929 [PIMreg] IANA, "http://www.iana.org/assignments/pim-parameters/pim- 2930 parameters.xhtml", 2005. 2932 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 2933 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 2934 Protocol Specification (Revised)", RFC 4601, August 2006. 2936 [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol 2937 Independent Multicast (PIM) Join Attribute Format", 2938 RFC 5384, November 2008. 2940 [RFC5851] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. 2941 Wadhwa, "Framework and Requirements for an Access Node 2942 Control Mechanism in Broadband Multi-Service Networks", 2943 RFC 5851, May 2010. 2945 Appendix A. Example of Messages and Message Flows 2947 This appendix provides an example in which most of the possible 2948 message flows for multicast control are illustrated. This appendix 2949 is for informational purposes only. In case of discrepancy with text 2950 of the body of this document, the text in the body of the document is 2951 to be considered as the normative text. 2953 Assume the following, for a given access port: 2955 o The basic subscribed service is white-listed. The AN will be 2956 responsible for admission control for this service. 2958 o Some premium services are available, but requests for these 2959 services must be referred to the policy server for proper credit 2960 processing. For this reason they are grey-listed. The NAS will 2961 be responsible for admission control for these services. 2963 o The subscriber has asked that certain services be blocked so that 2964 his children cannot view them. These services are black-listed. 2966 o All of the above services are Source-Specific Multicast (SSM). In 2967 addition, by means which bypass the AN, the subscriber can signal 2968 intent to join an on- line game service which is Any-Source 2969 Multicast (ASM). The NAS is responsible for admission control for 2970 this service. 2972 o Bandwidth delegation is in effect to share video bandwidth between 2973 the AN and the NAS. 2975 The stated conditions require the use of four of the five 2976 capabilities specified in this memo. 2978 A.1. Provisioning Phase 2980 Assume that capability negotiation has been completed between the AN 2981 and NAS and that the set of negotiated capabilities includes the 2982 following four multicast capabilities: NAS-initiated replication, 2983 conditional access with white and black list, conditional access with 2984 grey list, and bandwidth delegation. At this point, the NAS can 2985 provision the service profiles on the AN and enable admission control 2986 at the AN for white-listed flows. To do this, the NAS sends the AN a 2987 Provisioning message containing this information. An example message 2988 providing the profile for our assumed subscriber is shown in 2989 Figure 20. The message has the following contents: 2991 o Message type is 93. 2993 o The Result and Code fields in the header are set to zeroes, as 2994 specified in the ANCP base protocol document. 2996 o A Transaction identifier is assigned by the NAS. 2998 o The Multicast-Service-Profile TLV (of which typically there would 2999 be multiple instances) contains a Multicast-Service-Profile-Name 3000 TLV (with a length of 20 octets assumed for the example) and three 3001 List-Action TLVs, one each for the White, Grey, and Black lists 3002 within the profile. The White list flows come in two sets of 3003 group addresses: 233.252.0.0/29, coming from a server at 3004 192.0.2.15, and 233.252.0.32/29, coming from a server at 3005 192.0.2.16. The Grey listed flows are in the band 3006 233.252.0.64/29, coming from a server at 192.0.2.21. Finally, the 3007 Black list flows are two individual flows that happen to overlap 3008 with the Grey list band: 233.252.0.65, and 233.252.0.69, also with 3009 source 192.0.2.21. 3011 o The White-List-CAC TLV indicates that the AN does admission 3012 control on White-listed flows. 3014 1 2 3 3015 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 3016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3017 | Type (0x88-0C) | Length = 132 | 3018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3019 | Vers | Sub | Msg Type = 93 | 0x00 | Code = 0x000 | 3020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3021 | Partition ID | Transaction Identifier | 3022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3023 |I| SubMessage Number | Length = 132 | 3024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3025 | M-Serv-Prof TLV Type = 0x13 | TLV Length = 112 | 3026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3027 | M-S-Prof-Name TLV Type = 0x18 | Embedded TLV Length = 20 | 3028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3029 | Multicast service profile name | 3030 ~ = "Cust 0127-53681-0003" ~ 3031 | | 3032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3033 | List-Action TLV Type = 0x21 | Embedded TLV Length = 28 | 3034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3035 | Oper = 0x01 |Lst Typ = 0x01 | Reserved = 0x0000 | 3036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3037 | Address Family = 0x01 | List Length = 20 | 3038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3039 | G Preflen = 29| S Preflen = 32| Group prefix = | 3040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3041 | 233.252.0.0 | Source prefix = | 3042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3043 | 192.0.2.15 | G Preflen = 29| S Preflen = 32| 3044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3045 | Group prefix = 233.252.0.32 | 3046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3047 | Source prefix = 192.0.2.15 | 3048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3049 | List-Action TLV Type = 0x21 | Embedded TLV Length = 18 | 3050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3051 | Oper = 0x01 |Lst Typ = 0x03 | Reserved = 0x0000 | 3052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3053 | Address Family = 0x01 | List Length = 10 | 3054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3055 | G Preflen = 29| S Preflen = 32| Group prefix = / 3056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3057 / 233.252.0.64 | Source prefix = / 3058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3059 / 192.0.2.21 | Padding = 0x0000 | 3060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3061 | List-Action TLV Type = 0x21 | Embedded TLV Length = 28 | 3062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3063 | Oper = 0x01 |Lst Typ = 0x02 | Reserved = 0x0000 | 3064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3065 | Address Family = 0x01 | List Length = 20 | 3066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3067 | G Preflen = 32| S Preflen = 32| Group prefix = / 3068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3069 / 233.252.0.65 | Source prefix = / 3070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3071 / 192.0.2.21 | G Preflen = 32| S Preflen = 32| 3072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3073 | Group prefix = 233.252.0.69 | 3074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3075 | Source prefix = 192.0.2.21 | 3076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3077 |White-List-CAC TLV Type = 0x24 | TLV Length = 0 | 3078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3080 TLV lengths are given in decimal for easier understanding. Note that 3081 the padding after the middle List-Action TLV is counted as part of 3082 length of the Multicast-Service-Profile TLV, but is not included in 3083 the length of that List-Action TLV. Note also that the Length field 3084 in the message header, unlike those in the TLVs, includes the message 3085 header itself, as required by [RFC3292]. Finally, note that the 3086 Provisioning message does not include a MRepCtl-CAC TLV since in our 3087 example admission control for Grey listed flows and for NAS-initiated 3088 replication is performed by the NAS. 3090 Figure 20: Example Provisioning Message 3092 As soon as the AN port comes up, the AN sends an ANCP PORT_UP message 3093 to the NAS specifying the Access Loop Circuit ID. The NAS replies 3094 with an ANCP Port Management message that, together with the other 3095 parameters, includes the multicast service profile name to be 3096 associated to that port along with the initial amount of delegated 3097 bandwidth. The corresponding message flow is illustrated in 3098 Figure 21. 3100 +----------+ +---------+ +--- 3101 --+ +-----+ 3102 |Subscriber| | Home | | AN | | NAS | 3103 +----------+ | Gateway | +-----+ +-----+ 3104 | +---------+ | | 3105 | | | | 3106 | | | | 3107 | | DSL Synch. | | 3108 | |--------------------->| | 3109 | | |(M1)PORT_UP(Port ID) | 3110 | | |-------------------->| 3111 | | | (*) 3112 | | |(M2) PORT_MNGT | 3113 | | | (Port ID, | 3114 | | |Mcast S Profile Name,| 3115 | | |Bandwidth Allocation)| 3116 | | |<--------------------| 3118 (*) The NAS may optionally seek direction from an external 3119 Autorization/Policy Server 3121 Figure 21: Configuring an AN Port With Multicast Service Profile ID 3122 and Delegated Bandwidth amount 3124 The Port Management message will typically contain other TLVs but our 3125 example (Figure 22) just shows the Target, Multicast- Service- 3126 Profile-Name, and Bandwidth-Allocation TLVs. The Target TLV 3127 identifies the subscriber line, the Multicast-Service-Profile-Name 3128 TLV is identical to the one contained in the Provisioning message, 3129 and the Bandwidth-Allocation TLV provides just enough bandwidth (2000 3130 kbits/s) for one channel to start with. 3132 The following fields in the Port Management message header are shown 3133 with specific values either as directed by the base protocol document 3134 or for the sake of our example: 3136 o Message Type is 32. 3138 o Result is set to Nack (0x01) for this example. 3140 o Code is 0x000. 3142 o Port is set to 0. 3144 o Event Sequence Number, the R flag and the other bits marked x, 3145 Duration, the Event Flags, and the Flow Control Flags are all 3146 irrelevant for this function and are set to 0. 3148 o Function is set to 0x8, "Configure Connection Service Data". 3150 o X-Function is set to 0. 3152 o Tech Type is 0x05 (DSL). 3154 o Block lengths are calculated assuming a Circuit-Id length of 4 in 3155 our example. Recall that the example Multicast-Service-Profile- 3156 Name TLV length is 20. 3158 1 2 3 3159 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 3160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3161 | Type (0x88-0C) | Length = 84 | 3162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3163 | Vers | Sub | Msg Type = 32 | 0x01 | Code = 0x000 | 3164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3165 | Partition ID | Transaction Identifier | 3166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3167 |I| SubMessage Number | Length = 84 | 3168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3169 | Port = 0 | 3170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3171 | Port Session Number | 3172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3173 | Event Sequence Number = 0 | 3174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3175 |R|x|x|x|x|x|x|x| Duration = 0 | Function = 0x8| X-Function = 0| 3176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3177 | Event Flags | Flow Control Flags | 3178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3179 |x|x|x|x|x|x|x|x| Msg Type = 32 |Tech Type=0x05 | Blk Len = 56 | 3180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3181 | # of TLVs = 3 | Extension Block length = 44 | 3182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3183 | Target TLV Type = 0x1000 | Target TLV Length = 8 | 3184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3185 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3187 | Access Loop Circuit ID | 3188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3189 | M-S-Prof-Name TLV Type = 0x18 | TLV Length = 20 | 3190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3191 | Multicast service profile name | 3192 ~ = "Cust 0127-53681-0003" ~ 3193 | | 3194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3195 | BW Alloc TLV Type = 0x15 | TLV Length = 4 | 3196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3197 | Bandwidth value = 0x000007D0 (2000 kbits/s) | 3198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3200 Figure 22: Example Port Management Message 3202 A.2. Handling a Grey-Listed Flow 3204 Suppose now that the subscriber chooses to watch the premium channel 3205 characterized by source 192.0.2.21, group 233.252.0.67. Upon 3206 receiving the Join request, the AN matches it against the multicast 3207 service profile for the port and determines that it is a Grey-listed 3208 flow. Figure 23 illustrates the resulting ANCP message flow for the 3209 case of a simple join and leave, when admission control for Grey- 3210 listed flows is not activated on the AN. To start the flow, the AN 3211 sends a Multicast Admission Control request (M1) to the NAS. The NAS 3212 decides whether flow can be admitted, applying both policy and 3213 bandwidth criteria. It returns its decision (positive in this 3214 example) in a Multicast Replication Control message (M2). Later, 3215 when the subscriber leaves the flow, the AN informs the NAS by 3216 sending another Multicast Admission Control message. 3218 +----------+ +-------+ +-----+ ANCP +-----+ 3219 |Subscriber| | Home | | AN |<---------->| NAS | 3220 +----------+ |Gateway| +-----+ +-----+ 3221 | +-------+ | | 3222 | | | Multicast | 3223 | Join(Grey-Fl) | Admission | 3224 |-----------+---------->| Control (M1) | 3225 | | |------------------>| 3226 | | | | (NAS performs 3227 | | | Multicast | admission 3228 | | | Replication (*) control) 3229 | | | Control (M2) | 3230 | Mcast Grey Flow |<------------------| 3231 |<======================+ | 3232 | | | | 3233 ~ ~ ~ ~ 3234 | | | Multicast | 3235 | Leave(Grey-Fl) | Admission | 3236 |-----------+---------->| Control (M3) | 3237 | | |------------------>| 3238 | | | | 3240 Grey-Fl : Multicast Flow matching an entry in Grey List 3242 (*) The NAS may optionally seek direction from an external 3243 Authorization/Policy Server 3245 Figure 23: Successful Join/Leave Operations, Grey- Listed Flow 3247 The Multicast Admission Control message M1 contains: 3249 o an ANCP Header with: 3251 * Message-Type = 145 - Multicast Admission Control; 3253 * Result= 0x0 (Ignore); 3255 * Transaction-ID = Transaction-ID maintained by AN; 3257 o a Target TLV identifying the AN Port 3259 o a Command TLV containing: 3261 * Command Code = Add (0x01); 3263 * Accounting = 0; 3265 * a Multicast-Flow embedded TLV indicating the SSM multicast flow 3266 (Flow Type = 0x02) for which the AN received the IGMP Join: 3267 IPv4 (0x01) Group address= 233.252.0.67, IPv4 (0x01) Source 3268 Address = 192.0.2.21; 3270 * a Request-Source-IP embedded TLV containing the IGMP join 3271 source IP (192.0.2.100). 3273 The Multicast Admission Control message M1 is illustrated below: 3275 1 2 3 3276 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 3277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3278 | Type (0x88-0C) | Length = 98 | 3279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3280 | Vers | Sub | Msg Type=145 | 0x0 | Code = 0x000 | 3281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3282 | Partition ID | Transaction Identifier | 3283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3284 |I| SubMessage Number | Length = 98 | 3285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3286 | Type = 0x1000 (Target) | Target TLV Length = 8 | 3287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3288 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3290 | Access Loop Circuit ID | 3291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3292 | Command TLV Type = 0x11 | TLV Length = 28 | 3293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3294 | Cmd Code=0x01 |Acctg = 0x00 | Reserved = 0x0000 | 3295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3296 |Multicast-Flow TLV Type = 0x19 | Embedded TLV Length = 12 | 3297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3298 |Flow Type=0x02 |Addr Fam =0x01 | Reserved = 0x0000 | 3299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3300 | Multicast Group Address = 233.252.0.67 | 3301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3302 | Unicast Source Address = 192.0.2.21 | 3303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 3304 | Req-Src-IP TLV Type = 0x92 | Embedded TLV length = 4 | 3305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3306 | Unicast Address = 192.0.2.100 | 3307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3309 Multicast Admission Control Message Seeking To Add A Flow 3311 The Multicast Replication Control message M2 contains: 3313 o an ANCP Header with: 3315 * Message Type = 144 - Multicast Replication Control; 3317 * Result= 0x1 (NAck); 3319 * Transaction-ID = Transaction-ID maintained by NAS; 3321 o a Target TLV identifying the AN Port; 3323 o a Command TLV containing: 3325 * Command Code = Add (0x01); 3327 * Accounting = 1 (begin flow accounting), since in our example 3328 the operator wants accounting on this flow. 3330 * a Multicast-Flow embedded TLV indicating the SSM multicast flow 3331 (Flow Type = 0x02) that the NAS is admitting for this access 3332 port: IPv4 (0x01) Group address= 233.252.0.67, IPv4 (0x01) 3333 Source Address = 192.0.2.21. 3335 The Multicast Admission Control message M2 is illustrated below. 3337 1 2 3 3338 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 3339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3340 | Type (0x88-0C) | Length = 48 | 3341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3342 | Vers | Sub | Msg Type=144 | 0x1 | Code = 0x000 | 3343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3344 | Partition ID | Transaction Identifier | 3345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3346 |I| SubMessage Number | Length = 48 | 3347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3348 | Type = 0x1000 (Target) | Target TLV Length = 8 | 3349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3350 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3352 | Access Loop Circuit ID | 3353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3354 | Command TLV Type = 0x11 | TLV Length = 20 | 3355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3356 | Cmd Code=0x01 | Acctg = 0x01 | Reserved = 0x0000 | 3357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3358 |Multicast-Flow TLV Type = 0x19 | Embedded TLV Length = 12 | 3359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3360 |Flow Type=0x02 |Addr Fam =0x01 | Reserved = 0x0000 | 3361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3362 | Multicast Group Address = 233.252.0.67 | 3363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3364 | Unicast Source Address = 192.0.2.21 | 3365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3367 Figure 24: Multicast Replication Control Message Admitting A Flow 3369 The Multicast Admission Control message M3 advising the NAS that the 3370 flow has been terminated contains: 3372 o an ANCP Header with: 3374 * Message-Type = 145 - Multicast Admission Control 3376 * Result= 0x0 (Ignore) 3378 * Transaction-ID = Transaction-ID maintained by AN 3380 o a Target TLV identifying the AN Port 3382 o a Command TLV containing: 3384 * a Command Code = Delete (0x02); 3386 * Accounting = 0; 3388 * a Multicast-Flow embedded TLV indicating the SSM multicast flow 3389 (Flow Type = 0x02) for which the AN received the IGMP leave: 3390 IPv4 (0x01) Group address= 233.252.0.67, IPv4 (0x01) Source 3391 Address = 192.0.2.21. 3393 * a Request-Source-IP embedded TLV containing the IGMP leave 3394 request source, IPv4 (0x01) address 192.0.2.100. 3396 The Multicast Admission Control message M3 is illustrated below. 3398 1 2 3 3399 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 3400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3401 | Type (0x88-0C) | Length | 3402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3403 | Vers | Sub | Msg Type=145 | 0x0 | Code = 0x000 | 3404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3405 | Partition ID | Transaction Identifier | 3406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3407 |I| SubMessage Number | Length | 3408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3409 | Type = 0x1000 (Target) | Target TLV Length = 8 | 3410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3411 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3413 | Access Loop Circuit ID | 3414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3415 | Command TLV Type = 0x11 | TLV Length = 28 | 3416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3417 | Cmd Code=0x02 |Acctg = 0x00 | Reserved = 0x0000 | 3418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3419 |Multicast-Flow TLV Type = 0x19 | Embedded TLV Length = 12 | 3420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3421 |Flow Type=0x02 |Addr Fam =0x01 | Reserved = 0x0000 | 3422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3423 | Multicast Group Address = 233.252.0.67 | 3424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3425 | Unicast Source Address = 192.0.2.21 | 3426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3427 | Req-Src-IP TLV Type = 0x92 | Embedded TLV length = 4 | 3428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3429 | Unicast Address = 192.0.2.100 | 3430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3432 Multicast Admission Control Message Signalling flow Termination 3434 A.3. Handling White-Listed Flows 3436 The NAS has enabled White list admission control on the AN, and the 3437 bandwidth delegation capability has been negotiated. White listed 3438 flows in themselves require no messages to the NAS, either upon 3439 admission or upon termination, but the AN may request an increase in 3440 the amount of delegated bandwidth if it needs the increase to admit a 3441 flow. 3443 Consider an example where the AN has already admitted one White- 3444 listed flow, thereby using up the initially provisioned amount of 3445 delegated bandwidth (2000 kbits/s). A request is received to join a 3446 new flow in the White list range. The AN chooses to send a Bandwidth 3447 Reallocation Request message to the NAS, requesting that the 3448 delegated bandwidth allocation be increased to 4000 kbits/s at a 3449 minimum, and preferably to 6000 kbits/s. 3451 In our example, the NAS is managing bandwidth tightly, as witnessed 3452 by its minimal initial allocation of just enough for one flow. It is 3453 willing to provide the minimum additional amount only, and therefore 3454 returns a Bandwidth Transfer message where the delegated bandwidth 3455 value is given as 4000 kbits/s. With this amount, the AN is able to 3456 admit the second White-listed flow. The AN could send a similar 3457 Bandwidth Transfer message back to the NAS bringing the delegated 3458 bandwidth amount back down to 2000 kbits/s when one of the flows is 3459 terminated, but this shows nothing new and is omitted. 3461 As one more point of illustration, suppose that the NAS chooses to 3462 audit the current amount of delegated bandwidth to ensure it is 3463 synchronized with the AN. It sends a Delegated Bandwidth Query 3464 request message to the AN, and receives a Delegated Bandwidth Query 3465 response message with the current allocation as the AN sees it. 3467 The complete message flow is shown in Figure 25. 3469 +----------+ +-------+ +-----+ ANCP +-----+ 3470 |Subscriber| | Home | | AN |<---------->| NAS | 3471 +----------+ |Gateway| +-----+ +-----+ 3472 | +-------+ | | 3473 | | | | 3474 | Join(White-F1) | | 3475 |-----------+---------->| | 3476 | | |AN performs | 3477 | Mcast White Flow 1 | admission control | 3478 |<======================+ | 3479 | | | | 3480 | Join(White-F2) | | 3481 |-----------+---------->|No bandwidth left | 3482 | | | | 3483 | | |Bandwidth | 3484 | | | Reallocation Req | 3485 | | |------------------>|(M1) 3486 | | | | 3487 | | | (*) 3488 | | |Bandwidth Transfer | 3489 | AN can now |<------------------|(M2) 3490 | admit flow | | 3491 | Mcast White Flow 2 | | 3492 |<======================+ | 3493 | | | | 3494 ~ ~ ~ ~ 3495 | | |Delegated Bandwidth| 3496 | | | Query request | 3497 | | |<------------------|(M3) 3498 | | | | 3499 | | |Delegated Bandwidth| 3500 | | | Query response | 3501 | | |------------------>|(M4) 3502 | | | | 3504 (*) The NAS may optionally seek direction from an external 3505 Authorization/Policy Server 3507 Figure 25: Successful Join/Leave Operations, Grey-Listed Flow 3509 The Bandwidth Reallocation Request message (M1) is shown in 3510 Figure 26. The contents require little explanation. The Message 3511 Type for the Bandwidth Reallocation Request is 146. The Result field 3512 is set to 0x0 (Ignore). Besides the Target, the message has one 3513 other TLV, the Bandwidth- Request, with a TLV Type of 0x16. The TLV 3514 contains Required Amount and Preferred Amount fields, set to 4000 and 3515 6000 kbits/s respectively. 3517 1 2 3 3518 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 3519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3520 | Type (0x88-0C) | Length = 36 | 3521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3522 | Vers | Sub | Msg Type=146 | 0x0 | Code = 0x000 | 3523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3524 | Partition ID | Transaction Identifier | 3525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3526 |I| SubMessage Number | Length = 36 | 3527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3528 | Type = 0x1000 (Target) | Target TLV Length = 8 | 3529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3530 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3532 | Access Loop Circuit ID | 3533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3534 |Bandwidth-Req TLV Type = 0x16 | TLV Length = 8 | 3535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3536 | Required Amount = 0x00000FA0 (4000 kbits/s) | 3537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3538 | Preferred Amount = 0x00001770 (6000 kbits/s) | 3539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3541 Figure 26: Bandwidth Reallocation Request Message 3543 The Bandwidth Transfer message (M2) is shown in Figure 27. Again, 3544 the contents are easily understood. The Message Type for the 3545 Bandwidth Transfer message is 147. The Result field is set to 3546 Success (0x3). The message contains the Target TLV and the 3547 Bandwidth- Allocation TLV. The latter has a TLV Type of 0x15 and 3548 contains a Delegated Amount field, set to 4000 kbits/s. 3550 1 2 3 3551 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 3552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3553 | Type (0x88-0C) | Length = 32 | 3554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3555 | Vers | Sub | Msg Type=147 | 0x3 | Code = 0x000 | 3556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3557 | Partition ID | Transaction Identifier | 3558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3559 |I| SubMessage Number | Length = 32 | 3560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3561 | Type = 0x1000 (Target) | Target TLV Length = 8 | 3562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3563 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3565 | Access Loop Circuit ID | 3566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3567 |BW-Allocation TLV Type = 0x15 | TLV Length = 4 | 3568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3569 | Delegated Amount = 0x00000FA0 (4000 kbits/s) | 3570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3572 Figure 27: NAS Response, Bandwidth Transfer Message 3574 The Delegated Bandwidth Query request message (M3) is shown in 3575 Figure 28. The Message Type for the Delegated Bandwidth Query 3576 request message is 148. The Result field is set to AckAll (0x2). 3577 The message contains the Target TLV only. 3579 1 2 3 3580 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 3581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3582 | Type (0x88-0C) | Length = 24 | 3583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3584 | Vers | Sub | Msg Type=148 | 0x2 | Code = 0x000 | 3585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3586 | Partition ID | Transaction Identifier | 3587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3588 |I| SubMessage Number | Length = 24 | 3589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3590 | Type = 0x1000 (Target) | Target TLV Length = 8 | 3591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3592 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3594 | Access Loop Circuit ID | 3595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3597 Figure 28: Delegated Bandwidth Query Request Message 3599 Finally, the Delegated Bandwidth Query response message (M4) is shown 3600 in Figure 29. The Message Type for the Delegated Bandwidth Query 3601 response message is 148. The Result field is set to Success (0x3). 3602 The message contains the Target TLV and the Bandwidth-Allocation TLV 3603 with the Delegated Amount field set to 4000 kbits/s. 3605 1 2 3 3606 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3608 | Type (0x88-0C) | Length = 32 | 3609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3610 | Vers | Sub | Msg Type=148 | 0x3 | Code = 0x000 | 3611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3612 | Partition ID | Transaction Identifier (copied from request) | 3613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3614 |I| SubMessage Number | Length = 32 | 3615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3616 | Type = 0x1000 (Target) | Target TLV Length = 8 | 3617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3618 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3620 | Access Loop Circuit ID | 3621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3622 |BW-Allocation TLV Type = 0x15 | TLV Length = 4 | 3623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3624 | Delegated Amount = 0x00000FA0 (4000 kbits/s) | 3625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3627 Figure 29: Delegated Bandwidth Query Response Message 3629 A.4. Handling Of Black-Listed Join Requests 3631 This section introduces no new messages, since requests for flows in 3632 the Black list are simply ignored. The one thing to point out is the 3633 overlap in our example between the set of flows in the Grey list and 3634 the flows in the Black list. This does not create any ambiguity, 3635 since not only does the Black list have priority for equally good 3636 matches, but also the Black list entries are more specific (group 3637 prefix lengths of 32 versus 29 in the Grey list) than the Grey list 3638 flow prefixes. 3640 A.5. Handling Of Requests To Join and Leave the On-Line Game 3642 The final class of multicast control actions in our example allows 3643 the subscriber to enter and leave the on-line game. As described at 3644 the beginning of this example, the game uses Any Source Multicast 3645 (ASM). Subscriber signalling bypasses the AN, going directly to the 3646 NAS (e.g., through a web interface). 3648 When the subscriber requests to join the game, the NAS (after 3649 applying policy and bandwidth checks) sends a Multicast Replication 3650 Control message to the AN to enable the flow on the port concerned. 3651 The AN knows not to apply admission control, since it has not 3652 received an MRepCtl-CAC TLV in the Provisioning message. When the 3653 subscriber leaves, the NAS sends another Multicast Replication 3654 Control message to delete the flow. This message sequence is shown 3655 in Figure 30. 3657 It is possible that the NAS finds that there is not enough bandwidth 3658 available to accommodate the subscriber's request. In this case, the 3659 NAS could send a Bandwidth Reallocation Request message to the AN, 3660 asking it to release some of the bandwidth delegated to it. This is 3661 not shown in the present example, since the messages are the same as 3662 those already presented with the exception that the Preferred Amount 3663 in the request will be *less than* or equal to the Required amount, 3664 rather than *greater than* or equal to it. 3666 +----------+ +-------+ +-----+ ANCP +-----+ 3667 |Subscriber| | Home | | AN |<---------->| NAS | 3668 +----------+ |Gateway| +-----+ +-----+ 3669 | +-------+ | | 3670 | | | | 3671 | Join game | | 3672 |-----------+------------------------------>| 3673 | | | Multicast | NAS performs 3674 | | | Replication (*) admission 3675 | | | Control (M1) | control 3676 | Mcast Game Flow |<------------------| 3677 |<=====================>+ | 3678 | | | | 3679 ~ ~ ~ ~ 3680 | | | | 3681 | Leave game | | 3682 |-----------+------------------------------>| 3683 | | | Multicast | 3684 | | | Replication | 3685 | | | Control (M2) | 3686 | Mcast Game Flow |<------------------| 3687 | discontinued | | 3688 | | | | 3690 (*) The NAS may optionally seek direction from an external 3691 Authorization/Policy Server 3693 Figure 30: NAS-Initiated Flows For On-Line Gaming 3695 Multicast Replication Control message (M1) in Figure 31 looks like 3696 the message in Figure 24 with two exceptions. The first is that the 3697 NAS has the option to set the Result field to AckAll (0x02) if it 3698 needs positive reassurance that the flow has been enabled. This was 3699 not done here to save having to depict a response differing only in 3700 the Result field. The larger difference in this example is that the 3701 flow description in the Multicast-Flow embedded TLV is that of an ASM 3702 multicast group (Flow Type = 0x01) with IPv4 (0x01) group address 3703 233.252.1.100. 3705 1 2 3 3706 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 3707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3708 | Type (0x88-0C) | Length = 44 | 3709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3710 | Vers | Sub | Msg Type=144 | 0x1 | Code = 0x000 | 3711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3712 | Partition ID | Transaction Identifier | 3713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3714 |I| SubMessage Number | Length = 44 | 3715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3716 | Type = 0x1000 (Target) | Target TLV Length = 8 | 3717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3718 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | 3719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3720 | Access Loop Circuit ID | 3721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3722 | Command TLV Type = 0x11 | TLV Length = 16 | 3723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3724 | Cmd Code=0x01 | Acctg = 0x01 | Reserved = 0x0000 | 3725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3726 |Multicast-Flow TLV Type = 0x19 | Embedded TLV Length = 8 | 3727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3728 |Flow Type=0x01 |Addr Fam =0x01 | Reserved = 0x0000 | 3729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3730 | Multicast Group Address = 233.252.1.100 | 3731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 3733 Figure 31: Enabling The Subscriber To Join An On- Line Game 3735 Message M2 terminating the flow when the subscriber leaves the game 3736 looks the same as the message in Figure 31 with two exceptions: the 3737 Command Code becomes Delete (0x02), and Accounting is set to 0 to 3738 turn off flow accounting. Of course, the Transaction Identifier 3739 values will differ between the two messages. 3741 A.6. Example Flow For Multicast Flow Reporting 3743 The example in this section is independent of the example in the 3744 preceding sections. 3746 Figure 32 illustrates a message flow in a case where the NAS queries 3747 the AN about which multicast flows are active on port 10, on port 20 3748 and on port 11 of the AN. 3750 +----------+ +-------+ +-----+ ANCP 3751 +-----+ 3752 |Subscriber| | Home | | AN |<---------->| NAS | 3753 +----------+ |Gateway| +-----+ +-----+ 3754 | +-------+ | | 3755 | | | Multicast Flow | 3756 | | | Query Request | 3757 | | | (M1) | 3758 | | |<------------------| 3759 | | | | 3760 | | | Multicast Flow | 3761 | | | Query Response | 3762 | | | (M2) | 3763 | | |------------------>| 3764 | | | | 3765 | | | | 3767 Figure 32: Per Port Multicast Flow Reporting 3769 The Multicast Flow Query Request message (M1) is illustrated in 3770 Figure 33. The Message Type is 149. The Result field is set to 3771 AckAll (0x2). Three Target TLVs are present, identifying port 10, 3772 port 20, and port 11 respectively. 3774 0 1 2 3 3775 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 3776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3777 | Type (0x88-0C) | Length | 3778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3779 | Vers | Sub | Msg Type = 149|Rslt=2 | Code = 0 | 3780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3781 | Partition ID | Transaction Identifier | 3782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3783 |I| SubMessage Number | Length | 3784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3785 | Type = 0x1000 (Target) | Target TLV Length | 3786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3787 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 3788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3789 | | 3790 ~ Access Loop Circuit ID (port10) ~ 3791 | | 3792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3793 | Type = 0x1000 (Target) | Target TLV Length | 3794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3795 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 3796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3797 | | 3798 ~ Access Loop Circuit ID (port20) ~ 3799 | | 3800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3801 | Type = 0x1000 (Target) | Target TLV Length | 3802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3803 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 3804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3805 | | 3806 ~ Access Loop Circuit ID (port11) ~ 3807 | | 3808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3810 Figure 33: Multicast Flow Query Request Message For Per-Port 3811 Multicast Flow Reporting 3813 The Multicast Flow Query Response message (M2) is illustrated in 3814 Figure 34. It indicates that there is one active multicast flow 3815 [(192.0.2.1, 233.252.2.4)] on port 10, no active multicast flow on 3816 port 20 and two active multicast flows [(192.0.2.1, 233.252.2.4) and 3817 (192.0.2.2, 233.252.2.10)] on port 11. 3819 0 1 2 3 3820 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 3822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3823 | Type (0x88-0C) | Length | 3824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3825 | Vers | Sub | Msg Type = 149|Rslt=3 | Code = 0 | 3826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3827 | Partition ID | Transaction Identifier | 3828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3829 |I| SubMessage Number | Length | 3830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3831 | Type = 0x1000 (Target) | Target TLV Length | 3832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3833 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 3834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3835 | | 3836 ~ Access Loop Circuit ID (port10) ~ 3837 | | 3838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3839 |Multicast-Flow TLV Type = 0x19 | Embedded TLV Length = 12 | 3840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3841 |Flow Type=0x02 |Addr Fam =0x01 | Reserved = 0x0000 | 3842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3843 | Multicast Group Address = 233.252.2.4 | 3844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3845 | Unicast Source Address = 192.0.2.1 | 3846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 3847 | Type = 0x1000 (Target) | Target TLV Length | 3848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3849 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 3850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3851 | | 3852 ~ Access Loop Circuit ID (port20) ~ 3853 | | 3854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3855 | Type = 0x1000 (Target) | Target TLV Length | 3856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3857 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 3858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3859 | | 3860 ~ Access Loop Circuit ID (port11) ~ 3861 | | 3862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3863 |Multicast-Flow TLV Type = 0x19 | Embedded TLV Length = 12 | 3864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3865 |Flow Type=0x02 |Addr Fam =0x01 | Reserved = 0x0000 | 3866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3867 | Multicast Group Address = 233.252.2.4 | 3868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3869 | Unicast Source Address = 192.0.2.1 | 3870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 3871 |Multicast-Flow TLV Type = 0x19 | Embedded TLV Length = 12 | 3872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3873 |Flow Type=0x02 |Addr Fam =0x01 | Reserved = 0x0000 | 3874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3875 | Multicast Group Address: 233.252.2.10 | 3876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3877 | Unicast Source Address = 192.0.2.2 | 3878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 3880 Figure 34: Multicast Flow Query Response message for per-port 3881 Mulicast Flow Reporting 3883 Authors' Addresses 3885 Francois Le Faucheur 3886 Cisco Systems 3887 Greenside, 400 Avenue de Roumanille 3888 Sophia Antipolis 06410 3889 France 3891 Phone: +33 4 97 23 26 19 3892 Email: flefauch@cisco.com 3894 Roberta Maglione 3895 Telecom Italia 3896 Via Reiss Romoli 274 3897 Torino 10148 3898 Italy 3900 Phone: 3901 Email: roberta.maglione@telecomitalia.it 3903 Tom Taylor 3904 Huawei Technologies 3905 Ottawa 3906 Canada 3908 Email: tom111.taylor@bell.net