idnits 2.17.1 draft-ietf-ancp-mc-extensions-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == 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 18 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 == Line 2888 has weird spacing: '...licated x ...' == Line 2979 has weird spacing: '...licated x ...' == 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 (October 26, 2009) is 5290 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) == Outdated reference: A later version (-13) exists of draft-ietf-ancp-framework-12 ** Downref: Normative reference to an Informational draft: draft-ietf-ancp-framework (ref. 'I-D.ietf-ancp-framework') == Outdated reference: A later version (-17) exists of draft-ietf-ancp-protocol-07 -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 3 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: April 29, 2010 Telecom Italia 6 T. Taylor 7 Huawei 8 October 26, 2009 10 Additional Multicast Control Extensions for ANCP 11 draft-ietf-ancp-mc-extensions-01.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on April 29, 2010. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 This document specifies the extensions to the Access Node Control 60 Protocol required for support of the multicast use cases defined in 61 the Access Node Control Protocol framework document. Those use cases 62 are organized into the following ANCP capabilities: 64 o NAS-initiated multicast replication; 66 o conditional access with white and black lists; 68 o conditional access with grey lists; 70 o bandwidth delegation. 72 These capabilities may be combined according to the rules given in 73 this specification. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 3. Multicast Use Cases . . . . . . . . . . . . . . . . . . . . . 10 80 3.1. NAS Initiated Multicast Replication Control Use Case . . . 10 81 3.1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 10 82 3.1.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 11 83 3.2. Conditional Access and Admission Control Use Case . . . . 11 84 3.2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 11 85 3.2.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 12 86 3.3. Multicast Flow Reporting Use Case . . . . . . . . . . . . 13 87 3.3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 13 88 3.3.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 13 89 4. ANCP Messages . . . . . . . . . . . . . . . . . . . . . . . . 14 90 4.1. Provisioning Message . . . . . . . . . . . . . . . . . . . 14 91 4.1.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 14 92 4.1.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 15 93 4.2. Port Management Message . . . . . . . . . . . . . . . . . 16 94 4.2.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 16 95 4.2.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 17 96 4.3. Multicast Replication Control Message . . . . . . . . . . 17 97 4.3.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 21 98 4.3.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 22 99 4.4. Multicast Admission Control Message . . . . . . . . . . . 24 100 4.4.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 25 101 4.4.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 26 102 4.5. Bandwidth Reallocation Request Message . . . . . . . . . . 27 103 4.5.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 28 104 4.5.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 28 105 4.6. Bandwidth Transfer Message . . . . . . . . . . . . . . . . 30 106 4.6.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 31 107 4.6.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 31 108 4.7. Delegated Bandwidth Query Request Message . . . . . . . . 32 109 4.7.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 33 110 4.7.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 33 111 4.8. Delegated Bandwidth Query Response Message . . . . . . . . 33 112 4.8.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 34 113 4.8.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 34 114 4.9. Multicast Flow Query Request and Response Messages . . . . 35 115 4.9.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 35 116 4.9.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 36 117 5. ANCP TLVs and Sub-TLVs . . . . . . . . . . . . . . . . . . . . 38 118 5.1. Multicast-Service-Profile TLV . . . . . . . . . . . . . . 38 119 5.2. Command Number TLV . . . . . . . . . . . . . . . . . . . . 41 120 5.3. Bandwidth-Allocation TLV . . . . . . . . . . . . . . . . . 41 121 5.4. White-List-CAC TLV . . . . . . . . . . . . . . . . . . . . 42 122 5.5. MRepCtl-CAC TLV . . . . . . . . . . . . . . . . . . . . . 42 123 5.6. Bandwidth-Request TLV . . . . . . . . . . . . . . . . . . 42 124 5.7. Multicast-Service-Profile-Name TLV . . . . . . . . . . . . 43 125 5.8. Request-Source-IP sub-TLV . . . . . . . . . . . . . . . . 43 126 5.9. Request-Source-MAC sub-TLV . . . . . . . . . . . . . . . . 44 127 5.10. Multicast-Flow TLV . . . . . . . . . . . . . . . . . . . . 45 128 6. Multicast Capabilities . . . . . . . . . . . . . . . . . . . . 46 129 6.1. Required Protocol Support . . . . . . . . . . . . . . . . 46 130 6.1.1. Protocol Requirements For NAS-initiated Replication . 46 131 6.1.2. Protocol requirements For Conditional Access With 132 White and Black Lists . . . . . . . . . . . . . . . . 47 133 6.1.3. Protocol requirements For Conditional Access With 134 Grey Lists . . . . . . . . . . . . . . . . . . . . . . 48 135 6.1.4. Protocol requirements For Delegated Bandwidth . . . . 49 136 6.2. Capability-Specific Procedures for Providing Multicast 137 Service . . . . . . . . . . . . . . . . . . . . . . . . . 50 138 6.2.1. Procedures For NAS-initiated Replication . . . . . . . 50 139 6.2.2. Procedures For Conditional Access With Black and 140 White Lists . . . . . . . . . . . . . . . . . . . . . 51 141 6.2.3. Procedures For Conditional Access With Grey Lists . . 52 142 6.2.4. Procedures For Delegated Bandwidth . . . . . . . . . . 53 143 6.3. Combinations of Multicast Capabilities . . . . . . . . . . 54 144 6.3.1. Combination of NAS-Initiated Replication with 145 Other Capabilities . . . . . . . . . . . . . . . . . . 54 146 6.3.2. Conditional Access With White, Black, and Grey 147 Lists . . . . . . . . . . . . . . . . . . . . . . . . 55 148 6.3.3. Conditional Access Combined With Delegated 149 Bandwidth . . . . . . . . . . . . . . . . . . . . . . 56 150 7. Security Considerations . . . . . . . . . . . . . . . . . . . 57 151 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 152 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 62 153 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 154 10.1. Normative References . . . . . . . . . . . . . . . . . . . 63 155 10.2. Informative References . . . . . . . . . . . . . . . . . . 63 156 Appendix A. Example of Messages and Message Flows . . . . . . . . 65 157 A.1. Multicast Conditional Access and CAC without AN 158 bandwidth delegation . . . . . . . . . . . . . . . . . . . 65 159 A.1.1. List/Profile Provisioning . . . . . . . . . . . . . . 65 160 A.1.2. Profile Mapping . . . . . . . . . . . . . . . . . . . 67 161 A.1.3. Successful Join/Leave Operations . . . . . . . . . . . 67 162 A.1.4. Admission Control Reject without NAS Response . . . . 73 163 A.1.5. Admission Control Reject with NAS Response . . . . . . 75 164 A.2. Example Flows For bandwidth delegation . . . . . . . . . . 79 165 A.2.1. Activation and Provisioning of total multicast 166 Bandwidth . . . . . . . . . . . . . . . . . . . . . . 80 167 A.2.2. Successful Request For More Multicast Bandwidth . . . 81 168 A.2.3. Failed Autonomous Transfer With Reset . . . . . . . . 83 169 A.3. Example Flows For Multicast Flow Reporting . . . . . . . . 86 170 A.3.1. Per Port Multicast Flow Reporting . . . . . . . . . . 86 172 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 91 174 1. Introduction 176 [I-D.ietf-ancp-framework] defines a framework and requirements for an 177 Access Node control mechanism between a Network Access Server (NAS) 178 and an Access Node (e.g. a Digital Subscriber Line Access Multiplexer 179 (DSLAM)) in a multi-service reference architecture in order to 180 perform QoS-related, service-related and subscriber-related 181 operations. [I-D.ietf-ancp-protocol] specifies a protocol for Access 182 Node Control in broadband networks in line with this framework. 184 The Access Node Control Protocol (ANCP) specified in 185 [I-D.ietf-ancp-protocol] supports a number of use cases defined in 186 [I-D.ietf-ancp-framework] such as the Access Topology Discovery use 187 case, the Access Loop Configuration use case and the Remote 188 Connectivity Test use case. However, it does not support the 189 multicast use cases defined in [I-D.ietf-ancp-framework]. The 190 present document specifies the extensions to the Access Node Control 191 Protocol required for support of these multicast use cases. In terms 192 of the ANCP protocol, these use cases are organized into four 193 capabilities: 195 o NAS-initiated multicast replication; 197 o conditional access with white and black lists; 199 o conditional access with grey lists; 201 o bandwidth delegation. 203 NAS-initiated multicast replication assumes that multicast "join" and 204 "leave" requests are terminated on the NAS, or that the NAS receives 205 requests to establish multicast sessions through other means (e.g., 206 application-level signalling). The NAS sends commands to the AN to 207 start or stop replication of specific multicast flows on specific 208 subscriber ports. This use case is described briefly in the next-to- 209 last paragraph of section 3.4 of [I-D.ietf-ancp-framework]. 211 Conditional access is described in sections 3.4.1 and 3.4.2.3 of 212 [I-D.ietf-ancp-framework], with the latter section particularly 213 applicable to operation with white and black lists only. In case of 214 "conditional access with white and black lists", multicast join and 215 leave requests are terminated at the AN and accepted or ignored in 216 accordance with the direction provided by white and black lists 217 respectively. The white and black lists are provisioned per port at 218 startup time and may be modified thereafter. The NAS may enable 219 admission control of White-listed flows by appropriate provisioning. 220 If the bandwidth delegation capability has also been negotiated, that 221 capability provides a means to adjust the multicast bandwidth limits 222 at the AN. 224 Conditional access with grey lists is similar to conditional access 225 with white lists, except that before accepting any request matching a 226 grey list entry, the AN sends a request to the NAS for permission to 227 replicate the flow. Again, the NAS can enable admission control of 228 Grey-listed flows at the AN. It can control the application of 229 admission control on a per-flow basis. 231 Bandwidth delegation is described in section 3.4.2.1 of 232 [I-D.ietf-ancp-framework]. It allows flexible sharing of total video 233 bandwidth on an access line between the AN and the NAS. One 234 application of such bandwidth sharing is where the AN does multicast 235 admission control, while the NAS or Policy Server does unicast 236 admission control. In that case, bandwidth delegation allows dynamic 237 sharing of bandwidth between unicast and multicast video traffic on 238 each access line. 240 The formal specification of the behaviours associated with each of 241 these capabilities, singly and in combination, is given in Section 6. 243 In addition to the multicast service processing behaviour just 244 sketched, the definition of each capability includes support for the 245 multicast accounting and reporting services described in section 246 3.4.3 of [I-D.ietf-ancp-framework]. Because of this common content 247 and because of other protocol overlaps between the different 248 capabilities, the protocol descriptions for the multicast extensions 249 specified in this document are merged into a single non-redundant 250 narrative. Tables in Section 6 then indicate the specific sub- 251 sections of the protocol description that have to be implemented to 252 support each capability. 254 2. Terminology 256 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 257 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 258 document are to be interpreted as described in [RFC2119]. 260 The expression "delegated bandwidth" is used as a shorter way of 261 saying: "the total amount of video bandwidth delegated to the AN for 262 multicast admission control". 264 3. Multicast Use Cases 266 Quoting from [I-D.ietf-ancp-framework]: 268 "... the Access Node, aggregation node(s) and the NAS must all be 269 involved in the multicast replication process. This avoids that 270 several copies of the same stream are sent within the access/ 271 aggregation network. In case of an Ethernet-based access/aggregation 272 network, this may, for example, be achieved by means of IGMP snooping 273 or IGMP proxy in the Access Node and aggregation node(s). By 274 introducing IGMP processing in the access/aggregation nodes, the 275 multicast replication process is now divided between the NAS, the 276 aggregation node(s) and Access Nodes. In order to ensure backward 277 compatibility with the ATM-based model, the NAS, aggregation node and 278 Access Node need to behave as a single logical device. This logical 279 device must have exactly the same functionality as the NAS in the ATM 280 access/aggregation network. The Access Node Control Mechanism can be 281 used to make sure that this logical/functional equivalence is 282 achieved by exchanging the necessary information between the Access 283 Node and the NAS. " 285 [I-D.ietf-ancp-framework] describes the use cases for ANCP associated 286 with such multicast operations, and identifies the associated ANCP 287 requirements. The present section describes a subset of these use 288 cases as background to facilitate reading of this document, but the 289 reader is refered to [I-D.ietf-ancp-framework] for a more exhaustive 290 description of the ANCP multicast use cases. Detailed example 291 message flows can also be found in Appendix A. 293 3.1. NAS Initiated Multicast Replication Control Use Case 295 3.1.1. Goals 297 One option for multicast handling is for the subscriber to 298 communicate the "join/leave" information to the NAS. This can be 299 done for instance by terminating all subscriber IGMP ([RFC3376]) or 300 MLD ([RFC2710], [RFC3810]) signaling on the NAS. Another example 301 could be a subscriber using some form of application level signaling, 302 which is redirected to the NAS. In any case, this option is 303 transparent to the access and aggregation network. In this scenario, 304 the NAS uses ANCP to create and remove replication state in the AN 305 for efficient multicast replication. Thus, the NAS only sends a 306 single copy of the multicast stream towards the AN, which in turn 307 performs replication to multiple subscribers as instructed by the NAS 308 via ANCP. The NAS first performs conditional access and multicast 309 admission control when processing multicast join requests, and only 310 creates replication state in the AN if admission succeeds. 312 3.1.2. Message Flow 314 With the NAS-initiated use case, a Multicast Replication Control 315 Message is sent by the NAS to the AN with a directive to either join 316 or leave one (or more) multicast flow(s). The AN uses a Generic 317 Response message to convey the outcome of the directive. Figure 1 318 illustrates such an ANCP message exchange as well as the associated 319 AN behavior. 321 +----------+ +-------+ +-----+ ANCP +-----+ 322 |Subscriber| | Home | | AN |<-------------------->| NAS | 323 +----------+ |Gateway| +-----+ +-----+ 324 | +-------+ | | 325 | | | Multicast-Replication-Crl | 326 | | | (Target,add, Flow 1) | 327 | | |<--------------------------| 328 | Mcast Flow 1 | | 329 |<==========================+ | 330 | | | Generic Response | 331 | | |-------------------------->| 332 | | | | 333 | | | | 334 ~ ~ ~ ~ 335 | | | | 336 | | | Multicast-Replication-Crl | 337 | | | (Target,delete, Flow 1) | 338 | | |<--------------------------| 339 | | | | 340 | | Generic Response | 342 | | |-------------------------->| 344 Figure 1: NAS Initiated Multicast Replication Control 346 3.2. Conditional Access and Admission Control Use Case 348 3.2.1. Goals 350 One option for multicast handling is for the access/aggregation nodes 351 to participate in IGMP/MLD processing (e.g. via IGMP/MLD snooping). 352 In this scenario, on detecting a join/leave request from an enduser 353 for a multicast flow (in the grey list), the AN uses ANCP to request 354 conditional access and admission control decision from the NAS. In 355 turn, after conditional access and admission control checks, the NAS 356 uses ANCP to instruct the AN to change the replication states 357 accordingly. 359 3.2.2. Message Flow 361 For support of the conditional access and admission control use case, 362 on detection of an IGMP/MLD Join, the AN sends an Admission Control 363 message to the NAS to request conditional access and admission 364 control check. In case of positive outcome, the NAS sends a 365 Multicast Replication Control Message to the AN with a directive to 366 replicate the multicast flow to the corresponding user. Similarly on 367 detection of an IGMP/MLD leave, an Admission Control message is sent 368 by the AN to the NAS to keep the NAS aware of user departure for the 369 flow. This message flow is illustrated in Figure 2. 371 +----------+ +-------+ +-----+ ANCP +-----+ 372 |Subscriber| | Home | | AN |<------------------->| NAS | 373 +----------+ |Gateway| +-----+ +-----+ 374 | +-------+ | | 375 | | | | 376 | Join(Gr-Flow1) | Admission-Control | 377 |------------+---------->| (Target,add,Gr-Flow1) | 378 | | |-------------------------->| 379 | | | (*) 380 | | | Multicast-Replication-Crl | 381 | | | (Target,add,Gr-Flow 1) | 382 | | |<--------------------------| 383 | Mcast Gr-Flow1 | | 384 |<=======================+ | 385 | | | | 386 ~ ~ ~ ~ 387 | | | | 388 | Leave(Gr-Flow1) | Admission-Control | 389 |------------+---------->| (Target,delete,Gr-Flow1) | 390 | | |-------------------------->| 391 | | | 393 | | | | 395 Gr-Flow1: a multicast flow matching the grey list for that port 397 (*) The NAS may optionally seek direction from an external 398 Authorization/Policy Server 400 Figure 2: Multicast Conditional Access and Admission Control 402 3.3. Multicast Flow Reporting Use Case 404 3.3.1. Goals 406 The Multicast flow reporting use case allows the NAS to 407 asynchronously query the AN to obtain an instantaneous status report 408 related to multicast flows currently replicated by the AN. 410 3.3.2. Message Flow 412 The NAS sends a Multicast Flow Query Request message to the AN in 413 order to query the AN about information such as which multicast flows 414 are currently active on a given AN port or which ports are currently 415 replicating a given multicast flow. The AN conveys the requested 416 information to the NAS in a Multicast Flow Query Response message. 417 This message flow is illustrated in Figure 3. 419 +----------+ +-------+ +-----+ ANCP +-----+ 420 |Subscriber| | Home | | AN |<---------->| NAS | 421 +----------+ |Gateway| +-----+ +-----+ 422 | +-------+ | | 423 | | | Multicast Flow | 424 | | | Query Request | 425 | | |<------------------| 426 | | | | 427 | | | Multicast Flow | 428 | | | Query Response | 429 | | |------------------>| 430 | | | | 431 | | | | 433 Figure 3: Multicast Flow Reporting 435 4. ANCP Messages 437 This section defines new ANCP messages and new usage of existing ANCP 438 messages as well as procedures associated with the use of these 439 messages. 441 4.1. Provisioning Message 443 Section 5.4.3.1 of [I-D.ietf-ancp-protocol] defines the Provisioning 444 message that is sent by the NAS to the AN to provision information in 445 the AN. 447 The present document specifies that the Provisioning message MAY be 448 used by the NAS to provision multicast-related information (e.g. 449 multicast service profiles). The ANCP Provisioning message payload 450 MAY contain: 452 o one or more instances of the Multicast-Service-Profile TLV. The 453 Multicast-Service-Profile TLV is defined in the present document 454 in Section 5.1. Each instance of the Multicast-Service-Profile 455 TLV contains a Multicast Service Profile name and one or more list 456 actions. A list action consists of an action (add, delete, 457 replace), a list type (White, Black, or Grey), and list content 458 (multicast source and group addresses). 460 o an instance of the White-List-CAC TLV. The White-List-CAC TLV is 461 defined in section TLV_White_AC. If present, this TLV indicates 462 that the AN is required to do admission control before replicating 463 White-listed flows. 465 o an instance of the MRepCtl_CAC TLV. The MRepCtl-CAC TLV is 466 defined in section TLV_MRepCtl_AC. If present, this TLV indicates 467 that the AN may be required to do admission control before 468 replicating flows specified in Multicast Replication Control 469 messages. 471 See Section 6 for information on which multicast capabilities require 472 support of these TLVs in the Provisioning message. 474 4.1.1. Sender Behaviour 476 When directed by the Policy Server or by management action, the NAS 477 sends the Provisioning message to initially provision or to update 478 the White, Black, and/or Grey multicast channel lists associated with 479 a set of named multicast service profiles, or to enable the AN to 480 perform admission control for specific classes of flows. 482 To provision or update a multicast service profile, the NAS MUST 483 include within the message one or more instances of the Multicast- 484 Service-Profile TLV specifying the content to be provisioned or 485 updated. The NAS SHOULD NOT include any list type (White, Black, or 486 Grey) that is not supported by the set of multicast capabilities 487 negotiated between the NAS and the AN. The NAS MUST NOT use the 488 Provisioning message to send instances of the Multicast-Service- 489 Profile TLV to the AN unless the Multicast-Service-Profile TLV is 490 supported by the set of multicast capabilities negotiated between the 491 NAS and the AN. 493 To require admission control to be performed at the AN on White- 494 listed flows, the NAS MUST include a copy of the White-List-CAC TLV 495 in the Provisioning message. The White-List-CAC TLV MUST NOT be 496 provided unless the negotiated set of capabilities includes 497 conditional access with White and Black lists. 499 To require admission control to be performed at the AN on Grey-listed 500 flows or on NAS-initiated flows, the NAS MUST include a copy of the 501 MRepCtl-CAC TLV in the Provisioning message. The MRepCtl-CAC TLV 502 MUST NOT be provided unless the negotiated set of capabilities 503 includes NAS-initiated replication control or conditional access with 504 Grey lists. 506 4.1.2. Receiver Behaviour 508 The receiving AN provisions/updates the White, Black, and/or Grey 509 lists associated with the Multicast Service Profile names contained 510 in the Multicast-Service-Profile TLV instances within the message. 511 The AN MUST ignore instances of the Multicast-Service-Profile TLV 512 referring to any list type (White, Black, or Grey) that is not 513 supported by the set of multicast capabilities negotiated between the 514 NAS and the AN. 516 When a new Multicast Service Profile is identified by a Multicast- 517 Service-Profile TLV, the initial state of all lists associated with 518 that profile according to the negotiated set of multicast 519 capabilities is empty until changed by the contents of Multicast- 520 Service-Profile TLVs. 522 If the White-List-CAC and/or MRepCtl-CAC TLV is present in the 523 Provisioning message and the respective associated capabilities have 524 been negotiated, the AN prepares to do connection admission control 525 on the indicated class(es) of flow. 527 As indicated in [I-D.ietf-ancp-protocol], the AN MUST NOT reply to 528 the Provisioning message if it processed it successfully. If an 529 error prevents successful processing of the message content, the AN 530 MUST return a Generic Response message as defined in 532 [I-D.ietf-ancp-protocol], containing a Status-Info TLV with the 533 appropriate content describing the error. For this purpose, the 534 presence of a list typein a Multicast-Service-Profile TLV which was 535 ignored because it was not supported by the negotiated set of 536 capabilities is not considered to be an error. 538 Editor's note: that means that if a NAS mistakenly adds the wrong 539 list types there will be no debugging feedback. On the other 540 hand, this adds flexibility for handling pre-assembled sets of 541 list updates being sent out to multiple ANs. If there are no 542 comments on this feature/bug, this Editor's note will be removed 543 in the next version of the draft. 545 When a new Multicast Service Profile is identified by a Multicast- 546 Service-Profile TLV, the initial state of all lists associated with 547 that profile according to the negotiated set of multicast 548 capabilities is empty until changed by the contents of Multicast- 549 Service-Profile TLVs. 551 4.2. Port Management Message 553 As specified in [I-D.ietf-ancp-protocol], the NAS may send line 554 configuration information to the AN ("ANCP based Line Configuration" 555 use case) using GSMP Port Management messages modified to contain an 556 extension block. Section 5.4.3 of [I-D.ietf-ancp-protocol] defines a 557 number of TLVs that can be included in the Extension Value field 558 inside a Port Management message to support line configuration. 560 This document specifies that the Port Management message MAY also 561 include the following TLVs: 563 o "Multicast-Service-Profile-Name" TLV (defined in Section 5.7). 564 This TLV associates a Multicast Service Profile with the Access 565 Port specified by the extension block. 567 o "Bandwidth-Allocation" TLV (defined in Section 5.3). This TLV 568 specifies the total multicast bandwidth available to the AN for 569 admission control at the Access Port. 571 4.2.1. Sender Behaviour 573 The NAS sends the Port Management message at startup time to 574 initialize parameters associated with the Access Port specified in 575 the message and with the multicast capabilities negotiated between 576 the NAS and the AN. The NAS MAY send additional Port Management 577 messages subsequent to startup, to update or, in the case of the 578 Bandwidth-Allocation TLV, reset these parameters. The NAS MUST NOT 579 include a TLV unless it is supported by the set of multicast 580 capabilities negotiated between the NAS and the AN. See Section 6 581 for further information. 583 4.2.2. Receiver Behaviour 585 If the Port Management message contains a Multicast-Service-Profile- 586 Name TLV, the AN associates the named profile with the specified 587 Access Port. This association replaces any previous association. 588 That is, a given Access Port is associated with at most one Multicast 589 Service Profile. 591 As specified in [I-D.ietf-ancp-framework], if a join request is later 592 received by the AN for a multicast flow that is part of multiple 593 lists in the Multicast Service Profile associated with the Access 594 Port, then the most specific match MUST be used by the AN. If the 595 most specific match occurs in multiple lists, the Black list entry 596 MUST take precedence over the Grey list, which MUST take precedence 597 over the White list. If the requested multicast flow is not part of 598 any list, the AN SHOULD ignore the join request. 600 If the Port Management message contains a Bandwidth-Allocation TLV, 601 the AN adopts this as the current value of its total multicast 602 bandwidth limit for the Access Port. If the AN has already committed 603 multicast bandwidth exceeding the amount given in the Bandwidth- 604 Allocation TLV, the AN SHOULD NOT discontinue any multicast streams 605 in order to bring bandwidth down to within the new limit. However, 606 the AN MUST NOT admit new multicast streams that are subject to 607 admission control until it can do so within the limit specified by 608 the Bandwidth-Allocation TLV. 610 If the Port Management request cannot be processed due to error and 611 the Result field of the request is Nack (0x1) or AckAll (0x2), the AN 612 SHOULD add a Status-Info TLV to the Extension Value field in its 613 reply if this will provide useful information beyond what is provided 614 by the Code value returned in the response header. 616 4.3. Multicast Replication Control Message 618 This section defines a new message called the Multicast Replication 619 Control message. The Multicast Replication Control message is sent 620 by the NAS to the AN with one or more directives to add (join) or 621 delete (leave) a multicast flow on a target object identified in the 622 content of the message. 624 The Message Type for the Multicast Replication Control message is 625 0x90. 627 The ANCP Multicast Replication Control message payload contains the 628 following TLVs: 630 o Target TLV: The Target TLV is defined in [I-D.ietf-ancp-protocol]. 631 It MUST appear once and only once. It is encoded as specified in 632 [I-D.ietf-ancp-protocol] and identifies the AN port subject to the 633 request for admission or release. 635 o Command TLV: The Command TLV is defined in 636 [I-D.ietf-ancp-protocol]. It MUST be present. It MAY appear 637 multiple times. Each Command TLV contains a multicast flow 638 directive for the target. 640 The contents of the Command TLV for the Multicast Replication Control 641 Message are defined in Figure 4 and subsequent text. 643 0 1 2 3 644 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 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | Command Code |R O M Flags | Command Length | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | Multicast Flow Source Address | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-\ /-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | (Cont'd) ... / \ | Multicast Flow Group Address | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-\ /-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | (Cont'd) ... / \ | Sub-TLVs ... | 653 +-+-+-+-+-+-+-+-+-+-+-+-+\ /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | (Cont'd) ... / \ | Padding to 32-bit boundary | 655 +-+-+-+-+-+-+-+-+-+-+-+-+\ /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 Figure 4: Contents of the Command TLV in the Multicast Replication 658 Control Message 660 Command Code: 661 Command directive: 0x01 - Add; 0x02 - Delete; 0x03 - Delete 662 All. 664 Command Length: 665 Length in bytes of the Command including multicast flow 666 address, but excluding the Command Code header and flags. 668 Flags: 669 8 bit General purpose Flag field. Currently the following 670 flags are defined: 672 R - Resource Admitted Flag. Set to 1 in an add 673 command to indicate that the flow resources have 674 been reserved by admission control. Cleared to 0 675 otherwise. 677 O - Flow Accounting. When set in add command 678 indicates that byte accounting for the flow is to 679 commence. 681 M - When set, indicates that the multicast flow is 682 SSM; the Command MUST then specify both the 683 source and the group address. When not set, 684 indicates that the multicast flow is ASM; the 685 Command MUST then specify the group address only, 686 omitting the Source Address field. 688 Multicast Flow Source Address: 689 a field containing three sub-fields as illustrated in 690 Figure 5, giving the source address for an SSM flow. This 691 field MUST be present if the M flag is set, and MUST NOT be 692 present if the M flag is cleared. 694 Multicast Flow Group Address: 695 a field containing three sub-fields as illustrated in 696 Figure 5, giving the group address for the multicast flow. 697 This field MUST be present. 699 The address family of the group address MAY differ from the address 700 family of the source address, if present. 702 For future extensibility, each Command TLV MAY also have additional 703 sub-TLVs appended following the command and multicast flow 704 information (shown as "Sub-TLVs" in Figure 4). Unrecognized sub-TLVs 705 SHOULD be silently discarded. 707 If needed, padding is done at the end of the command data so that the 708 TLV is 32-bit aligned. 710 As shown in Figure 5, each address entry in the Command TLV consists 711 of the following three sub-fields with no intervening padding: 713 Address Family: 714 The address family of the address with values as defined in 715 [IANAAEA]. 717 Encoding Type: 718 The type of encoding used within a specific Address Family. The 719 value `0' is reserved for this field, and represents the native 720 encoding of the Address Family. This is consistent with the 721 address encoding specified in [RFC4601]. 723 Address: 724 The address as represented by the given Address Family and 725 Encoding Type. This is consistent with the address encoding 726 specified in [RFC4601]. 728 0 1 2 3 729 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 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Addr Family | Encoding Type | IP Address | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/-+-+-+-+-+-+-+-+ 733 | IP Address (Cont'd) ... \ 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/-+-+-+-+-+-+-+-+ 736 Figure 5: Structure of the Address Fields in the Command TLV 738 The figure below is an example of a Multicast Replication Control 739 message that would result in a swap from multicast SSM flows 740 192.0.2.1, 233.252.0.2, to 192.0.2.2, 233.252.0.3 on the Target 741 identified by the "Access Loop Circuit ID": 743 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 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Type (0x88-0C) | Length | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Vers | Sub |MessageType=90 | 0x02 | Code | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | Partition ID | Transaction Identifier = 0001 | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 |I| SubMessage Number | Length | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Type = Target 0x1000 | Target TLV Length | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | | 758 ~ Access Loop Circuit ID ~ 759 | | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Type = Command TLV | Command-TLV Length | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | Cmd Code=0x02 |0 0 1 | Command Length | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 |Mcast Source (Ctnd) 192.0.2.1 | AddrFamily 01 | EncType 0x0 | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | Mcast Flow : 233.252.0.2 | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 771 | Type = Command-TLV | Command-TLV Length | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | Cmd Code=0x01 |0 0 1 | Command Length | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.2 | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 |Mcast Source (Ctnd) 192.0.2.2 | AddrFamily 01 | EncType 0x0 | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Mcast Flow: 233.252.0.3 | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 4.3.1. Sender Behaviour 784 The NAS MAY issue a Multicast Replication Control message to the AN 785 to convey one or more directives to add (join) or delete (leave) one 786 or more multicast flows. 788 The NAS MAY send this message on its own initiative to support the 789 NAS initiated Multicast Control use case presented in 790 [I-D.ietf-ancp-framework] and summarized in Section 3.1. In that 791 case, the NAS MUST set the Result field to AckAll (0x2) or Nack (0x1) 792 according to its requirements. 794 The NAS MAY also send this message in response to a Multicast 795 Admission Control message (defined in Section 4.4) received from the 796 AN to support the conditional access and admission control use case 797 presented in [I-D.ietf-ancp-framework] and summarized in Section 3.2. 798 In that case, the NAS MUST set the Result field to NAck (0x1). 800 In either case, the sender MUST populate the Code field with the 801 value 0x000 and the ANCP Transaction Identifier field with a unique 802 value, as described in section 5.4.5 of [I-D.ietf-ancp-protocol]. 804 Each Multicast Replication Control Message MAY contain one or more 805 commands, each encapsulated in its own Command TLV. The sender MUST 806 use a separate Command TLV for each distinct multicast flow. 808 When the order of processing of two commands does not matter, the 809 commands MUST be transmitted in separate Multicast Replication 810 Control messages. 812 The NAS MAY choose to perform admission control before adding a 813 particular flow even if admission control has been enabled on the AN. 814 If it does so, it MUST set the R flag in the Command TLV concerned. 815 Conversely, if admission control has been enabled on the AN, the NAS 816 MAY choose to have the AN do admission control by clearing the R 817 flag. 819 Note that clearing the R flag causes the AN to allocate resources 820 for the flow out of its bandwidth budget as opposed to any 821 bandwidth budget managed for the same access line at the NAS. 823 4.3.2. Receiver Behaviour 825 When successive commands (in the same or different messages) relate 826 to the same Target and multicast flow, the state of each feature 827 controlled or affected by flags or by optional attributes received in 828 the Multicast Replication Control message, SHALL be as set by the 829 last command or message referring to that target and flow and 830 containing the controlling flag or optional attribute. As an 831 example, successive Multicast Replication Control messages containing 832 add commands for a given port and flow, but differing only in the 833 accounting flag setting SHALL be interpreted to mean that the state 834 of the accounting feature is as set in the final command received, 835 but all other features are as set in the initial message. 837 If more than one Command TLV is present in a Multicast Replication 838 Control message, the AN MUST act on the commands in the order in 839 which they are presented in the message. The AN SHALL assign a 840 sequence number to each command in a given Multicast Replication 841 Control message, starting from 0x01 for the first command. 843 If admission control for Multicast Replication Control messages has 844 not been enabled (through provisioning of the MRepCtl_CAC TLV, the AN 845 MUST ignore the R flag in Command TLVs. Otherwise, if a Command TLV 846 adds a flow, the R flag within the TLV is not set, and the AN is 847 performing admission control for Multicast Replication Control 848 messages, then the AN MUST perform admission control before 849 replicating the flow. If the admission control check fails, the AN 850 MUST treat the failure as an error as described below. The 851 appropriate Code value for the response is 18 (0x012) "Insufficient 852 resources". 854 If the AN processes the complete Multicast Replication Control 855 message successfully and the Result field of the Multicast 856 Replication Control message was set to AckAll (0x2), the AN MUST 857 respond with a Generic Response message where the Result field is set 858 to Success (0x3), the Code field is set to 0x000, and the Transaction 859 Identifier field is copied from the Multicast Replication Control 860 message. The body of the response MAY be empty or MAY be copied from 861 the Multicast Replication Control message. 863 The processing/execution of multiple commands contained in a single 864 Multicast Control message MUST be interrupted at the first error 865 encountered, and the remaining commands in the Multicast Replication 866 Control message discarded. 868 If the AN detects an error in a received Multicast Replication 869 Control message and the Result field in that message was set to Nack 870 (0x1) or AckAll (0x2), the AN MUST generate a Generic Response 871 message providing error information to the NAS. This specification 872 identifies the following new Code values beyond those specified in 873 [I-D.ietf-ancp-protocol], which MAY be used in a Generic Response 874 sent in reply to a Multicast Replication Control message: 876 0x100 Command error. This SHOULD be reported for the following 877 cases: 879 * invalid command code; 881 * undefined flag set. 883 0x101 Bad flow address. This SHOULD be reported for the following 884 cases: 886 * unsupported address family; 888 * unsupported address encoding; 890 * source address present when M flag cleared, or absent when M 891 flag set. 893 0x102 Multicast flow does not exist. This SHOULD be reported if the 894 NAS attempts to delete a flow that is not enabled. 896 A Generic Response message responding to the Multicast Replication 897 Control message and containing one of the above Code values MUST 898 include a Status-Info TLV which includes one or two sub-TLVs as 899 follows: 901 o a Command Number TLV as described in Section 5.2, giving the 902 sequence number of the failed command, MUST be included; 904 o the failed Command TLV itself SHOULD be included. 906 Note that the Error Message field of the Status-Info TLV MAY be 907 used to report more details than implied by the Code value in the 908 message header. For example, the Code value could be 0x101 and 909 the Error Message field could contain the text: "Source address 910 present when M flag cleared". 912 4.4. Multicast Admission Control Message 914 This section defines a new message called the Multicast Admission 915 Control message. The Multicast Admission Control message is sent by 916 the AN to the NAS to request admission of a multicast flow, or to 917 notify of the removal of a multicast flow, for a given target. 919 The Message Type for the Multicast Admission Control message is 0x92. 921 The ANCP Multicast Admission Control message payload contains two 922 TLVs: 924 o Target TLV: The Target TLV is defined in [I-D.ietf-ancp-protocol]. 925 It MUST appear once and only once in the Multicast Admission 926 Control message. It is encoded as specified in 927 [I-D.ietf-ancp-protocol] and identifies the AN port subject to the 928 request for admission or release. 930 o Command TLV: The Command TLV is defined in 931 [I-D.ietf-ancp-protocol]. It MUST be present. If it appears more 932 than once, only the first instance is considered meaningful in the 933 present version of this specification and the other instances are 934 ignored. 936 Informative note: 938 In the future, the specification of the Admission Control message 939 may be extended to allow transport of more than a single directive 940 (e.g. to carry both a leave from one group and a join to another 941 group for the same Target). It is expected that this would 942 support a similar notion of strict sequenced processing as 943 currently defined for handling multiple directives in the 944 Multicast Replication Control message whereby all directives 945 following the first directive that can not be executed are not 946 executed either. When the strict sequenced processing of the 947 directives is not required the directives are distributed across 948 separate messages. 950 4.4.1. Sender Behaviour 952 The AN sending the Multicast Admission Control message MUST set the 953 Result field to Ignore (0x0). 955 The AN MUST populate the ANCP Transaction Identifier field with a 956 unique value, as described in section 5.4.5 957 of[I-D.ietf-ancp-protocol] . 959 The AN MUST encode the Command TLV as specified in Section 4.3 with 960 the following additional rules: 962 o the R flag MUST be set to 0; 964 o the O flag MUST be set to 0; 966 o the Command Code field MUST be set to "0x01 - Add" when the 967 message conveys a Join , to "0x02 - Delete" when the message 968 conveys a Leave and to "0x03 - Delete All" when the message 969 conveys a Leave of all channels (on the target); 971 o The M Flag, Multicast Source Address and Multicast Flow Address of 972 the Command TLV identify the multicast flow subject to the request 973 for admission or release. When the Command Code is 0x03, the M 974 Flag, Multicast Source address, and Multicast Flow Address are 975 meaningless and MUST be set to all zeroes. 977 o a Request-Source-IP sub-TLV (as defined in Section 5.8) MAY be 978 included by the AN to convey the IP address of the sender of the 979 join/leave message (e.g. IGMP/MLD Join/Leave) that triggered the 980 AN to include the corresponding Command TLV in the Admission 981 Control message. If it appears more than once, only the first 982 instance is considered meaningful and the other instances are 983 ignored. 985 o a Request-Source-MAC sub-TLV (as defined in Section 5.9) MAY be 986 included by the AN to convey the MAC address of the sender of the 987 join/leave message (e.g. IGMP/MLD Join/Leave) that triggered the 988 AN to include the corresponding Command TLV in the Admission 989 Control message. If it appears more than once, only the first 990 instance is considered meaningful and the other instances are 991 ignored. 993 4.4.2. Receiver Behaviour 995 On receipt of an Multicast Admission Control message, the NAS: 997 o MUST ignore the Result field; 999 o if the directive in the Multicast Admission Control message is 1000 "0x02 - Delete" or "0x03 - Delete All" and is processed correctly 1001 by the NAS, the NAS MUST NOT generate any ANCP message in response 1002 to the Multicast Admission Control message; 1004 o if the directive in the Multicast Admission Control message is 1005 "0x01 - Add" and is accepted by the NAS, the NAS MUST generate a 1006 Multicast Replication Control in response to the Multicast 1007 Admission Control message. The Multicast Replication Control 1008 message: 1010 * MUST contain a Result set to Nack (0x1); 1012 * MUST contain a Transaction ID generated by the NAS (distinct 1013 non-zero, and linearly incremented by NAS for each request per 1014 adjacency); 1016 * MUST contain the directive as accepted by the NAS. The R flag 1017 in the returned Command TLV MUST have value 0 if the NAS 1018 intends the AN to perform admission control before installing 1019 the flow, 1 otherwise. Note that the AN will ignore the R flag 1020 unless the MRepCtl_CAC TLV has been provisioned on the AN. 1022 o if the directive in the Multicast Admission Control message is 1023 "0x01 - Add", is processed correctly but not accepted by the NAS 1024 (i.e. it does not pass the admission control or conditional access 1025 check), the NAS MAY generate a Multicast Replication Control 1026 message in response to the Multicast Admission Control message. 1027 This optional message can be used by the AN to maintain statistics 1028 about admission control reject and, in the future, when the 1029 protocol between the subscriber and the AN allows explicit 1030 notification of join reject (e.g. 1031 [I-D.morin-mboned-igmpmld-error-feedback]). When used in this 1032 situation, the Multicast Replication Control message: 1034 * MUST contain a Result set to 0x00; 1036 * MUST contain a Transaction ID generated by the NAS (distinct 1037 non-zero, and linearly incremented by NAS for each request per 1038 adjacency); 1040 * MUST contain the directive rejected by the NAS (i.e. Target 1041 TLV and Command TLV) but with a Command Code set to "0x04 - 1042 Admission Control Reject", "0x05 - Conditional Access Reject" 1043 or "0x06 - Admission Control and Conditional Access Reject". 1045 o if the Multicast Admission Control message cannot be processed 1046 correctly by the NAS (e.g. the message is malformed, the multicast 1047 flow does not exist etc.), the NAS MUST generate a Generic 1048 Response message (defined in [I-D.ietf-ancp-protocol]) with 1049 appropriate content indicating the reason for the failure. 1051 4.5. Bandwidth Reallocation Request Message 1053 The Bandwidth Reallocation Request message is used when the bandwidth 1054 delegation capability is included in the negotiated set. It MAY be 1055 sent either by the NAS or by the AN to request an adjustment in the 1056 amount of delegated bandwidth. It will be sent by the NAS typically 1057 to reduce the multicast bandwidth allocated to the AN in order for 1058 the NAS to satisfy a request to add one or more flows. Conversely, 1059 the AN will send a Bandwidth Reallocation Request to obtain 1060 additional bandwidth to satisfy a request to add a multicast channel. 1061 In each case, the requestor has a minimum requirement for additional 1062 bandwidth, and MAY ask for additional bandwidth beyond this amount 1063 (e.g., to handle anticipated future requests). 1065 The Bandwidth Reallocation Request message contains two TLVs: 1067 o the Target TLV (section 5.4.5.1.1 of [I-D.ietf-ancp-protocol]), 1068 specifying a single access line; 1070 o the Bandwidth-Request TLV (Section 5.6), specifying the required 1071 and preferred amounts of delegated bandwidth. 1073 The Message Type for the Bandwidth Reallocation Request message is 1074 0x94. 1076 4.5.1. Sender Behaviour 1078 The Result field in the header of the Bandwidth Reallocation Request 1079 message is not used and the sender MUST set it to Ignore (0x0). 1081 The bandwidth values in the Bandwidth-Request TLV are expressed in 1082 terms of total multicast bandwidth allocated to the AN. 1084 The choice of "total bandwidth" rather than "incremental 1085 bandwidth" was made so that it would be easier for the AN and NAS 1086 to keep their respective views of the current amount of delegated 1087 bandwidth synchronized. 1089 Because the values are totals rather than desired increments/ 1090 decrements, the relationship between the required amount and the 1091 preferred amount will differ depending on whether the Bandwidth 1092 Reallocation Request message is issued by the NAS or the AN. 1094 o If the NAS is making the request, the preferred amount MUST be 1095 less than or equal to the required amount. The required amount 1096 MUST be less than the currently amount of delegated bandwidth. 1098 o If the AN is making the request, the preferred amount MUST be 1099 greater than or equal to the required amount. The required amount 1100 MUST be greater than the currently amount of delegated bandwidth. 1102 4.5.2. Receiver Behaviour 1104 When the peer receives a valid Bandwidth Reallocation Request 1105 message, it SHOULD determine whether it can satisfy the request from 1106 its existing allocation of unused video bandwidth. If it decides 1107 that it can reallocate bandwidth to the peer, it MAY choose to return 1108 any amount between the required and the preferred amounts indicated 1109 in the Bandwidth Reallocation Request message. 1111 The peer MUST return a Bandwidth Transfer message Section 4.6 1112 indicating its decision. If the request is met, the Result field of 1113 the Bandwidth Transfer message MUST be set to Success (0x3), the Code 1114 field MUST be set to 0x000, and the Bandwidth-Allocation TLV 1115 (Section 5.3) MUST contain the new value of total multicast 1116 bandwidth. This new value MUST lie between the required and 1117 preferred values, inclusive, from the request message. If the 1118 request is not met, the Result field of the Bandwidth Transfer 1119 message MUST be set to Failure (0x4), the Code field MUST be set to 1120 0x000, and the Bandwidth Allocation TLV MUST contain the value of the 1121 currently allocated amount of delegated bandwidth as the responder 1122 views it. 1124 The following cases indicate that the sender holds a different view 1125 of the amount of bandwidth from the receiver: 1127 o the NAS receives a request where the required amount is less than 1128 its view of the current amount of delegated bandwidth; 1130 o the AN receives a request where the required amount is greater 1131 than its view of the current amount of delegated bandwidth. 1133 If one of these cases occurs, the receiver with one exception MUST 1134 send a Bandwidth Transfer message indicating Success. 1136 o If the NAS received the request, the allocated amount in the NAS's 1137 response MUST be at least equal to NAS's view of the current 1138 amount of delegated bandwidth. 1140 o If the AN received the request, the allocated amount in the AN's 1141 response MUST be no greater than the AN's view of the current 1142 amount of delegated bandwidth. 1144 The exception is when the NAS receives a request while it has a 1145 request of its own outstanding. Handling of that case is described 1146 below. 1148 While the cases just described are an error condition, the success 1149 response achieves a graceful recovery. 1151 To avoid deadlock due to race conditions, the following rules MUST be 1152 applied: 1154 a. If the NAS receives a Bandwidth Reallocation Request message 1155 while it has a Bandwidth Reallocation Request message of its own 1156 outstanding for the same access line, the NAS MUST provide an 1157 immediate failure response to the request from the AN, with a 1158 Code value set to 0x105 "Bandwidth request conflict". 1160 b. If the AN receives a Bandwidth Reallocation Request message while 1161 it has a Bandwidth Reallocation Request message of its own 1162 outstanding for the same access line, the AN MUST release any 1163 bandwidth it has already committed to an outstanding Join request 1164 while it is awaiting a response from the NAS. It MUST decide 1165 upon and send its response to the NAS taking the released 1166 bandwidth into account. 1168 If the receiver is unable to process the Bandwidth Reallocation 1169 Request message due to an error, then the receiver MUST return a 1170 Bandwidth Transfer message where: 1172 o the Result field is set to Failure (0x4), 1174 o the Code field is set appropriately to indicate the type of error 1175 that was detected, 1177 o the Bandwidth Allocation TLV contains the value of the current 1178 amount of delegated bandwidth as the responder views it, and 1180 o a Status-Info TLV MAY follow the Bandwidth Allocation TLV giving 1181 further information about the error. 1183 This specification provides three new Code values applicable 1184 specifically to the contents of the Bandwidth-Request TLV. These 1185 Code values by their nature MUST only be used when the error is being 1186 reported in a Bandwidth Transfer message rather than a Generic 1187 Response message. 1189 0x103 invalid preferred bandwidth amount. This indicates that the 1190 preferred and required amounts of bandwidth in the TLV do not have 1191 the numerical relationship described in the previous section. 1193 0x104 inconsistent views of delegated bandwidth amount. This will 1194 appear only in a Bandwidth Transfer message from the NAS to the AN 1195 in the case where the NAS has an outstanding Bandwidth 1196 Reallocation Request. The recommended procedure for recovery is 1197 described in Section 4.6.2. 1199 0x105 bandwidth request conflict. The NAS has rejected the AN's 1200 request for more bandwidth because the NAS has an outstanding 1201 bandwidth request. 1203 4.6. Bandwidth Transfer Message 1205 The Bandwidth Transfer message is used to transfer video bandwidth 1206 from the sender to the peer for a specific access line. This message 1207 MAY be sent either from the AN or from the NAS. As described in the 1208 previous section, it is the required response to a valid Bandwidth 1209 Reallocation Request message. 1211 The Bandwidth Transfer message MAY also be used to transfer bandwidth 1212 autonomously from one peer to another. One example of this usage is 1213 to release bandwidth borrowed earlier by means of the Bandwidth 1214 Reallocation Request message. When the message is used in this way, 1215 the Result field in the Bandwidth Transfer message MUST be set to 1216 Ignore (0x0). 1218 This allows the receiver to distinguish between an autonomous 1219 transfer and a response to a previous Bandwidth Reallocation 1220 Request, for purposes of validation. 1222 The Message Type for the Bandwidth Transfer message is 0x95. The 1223 Bandwidth Transfer message contains the following TLVs: 1225 o the Target TLV, designating the access line concerned; 1227 o an instance of the Bandwidth-Allocation TLV (Section 5.3). The 1228 bandwidth value in the Bandwidth-Allocation TLV is the new amount 1229 of delegated bandwidth allocated to the target. 1231 4.6.1. Sender Behaviour 1233 When sending a Bandwidth Transfer message where the Result value is 1234 Ignore (0x0) or Success (0x3), the following relationships MUST hold: 1236 o if the message is sent by the NAS, the bandwidth value in the 1237 Bandwidth-Allocation TLV MUST be greater than or equal to the 1238 sender's view of the current amount of delegated bandwidth for the 1239 access line concerned; 1241 o if the message is sent by the AN, the bandwidth value in the 1242 Bandwidth-Allocation TLV MUST be less than or equal to the 1243 sender's view of the current amount of delegated bandwidth for the 1244 access line concerned. 1246 Further sender behaviour is specified above, in Section 4.5.2. 1248 4.6.2. Receiver Behaviour 1250 4.6.2.1. Behaviour of the NAS 1252 If the amount of delegated bandwidth provided in the Bandwidth- 1253 Allocation TLV is not greater than the NAS's view of the current 1254 amount of delegated bandwidth, the NAS MUST update its view of the 1255 current amount of delegated bandwidth to the amount indicated in the 1256 Bandwidth Transfer message. This is required regardless of whether 1257 the Result field of that message indicates Success or Failure. 1259 If the amount of delegated bandwidth provided in the Bandwidth- 1260 Allocation TLV is greater than the NAS's view of the current amount 1261 of delegated bandwidth, the NAS MAY accept the given value as its new 1262 value of delegated bandwidth. Alternatively, the NAS MAY force the 1263 AN to modify its view of the amount of delegated bandwidth to that 1264 held by the NAS, by sending a Port Management message for the target 1265 access line concerned, containing a Bandwidth-Allocation TLV with a 1266 value equal to the amount of delegated bandwidth the NAS wishes to 1267 enforce. 1269 4.6.2.2. Behaviour of the AN 1271 If the amount of delegated bandwidth provided in the Bandwidth- 1272 Allocation TLV of the Bandwidth Transfer message differs from the 1273 AN's view of the current amount of delegated bandwidth, the AN MUST 1274 update its view of the current amount of delegated bandwidth to the 1275 amount indicated in the Bandwidth Transfer message. This is required 1276 with the exception of a Bandwidth Transfer message with a Result 1277 field equal to Failure (0x4) and a Code field equal to 0x104 1278 "Inconsistent views of delegated bandwidth amount" or 0x105 1279 "Bandwidth request conflict". If Code value 0x104 is received, the 1280 AN MUST issue a Delegated Bandwidth Query Request message to 1281 determine the NAS's current view of the amount of delegated 1282 bandwidth. The AN MUST update its own view based on the value 1283 returned in the Delegated Bandwidth Query Response. If Code value 1284 0x105 is received, the AN SHOULD carry out this procedure unless it 1285 can account for the discrepancy as a result of a transfer of 1286 bandwidth to the NAS that was carried out just before the incoming 1287 Bandwidth Transfer message was processed. 1289 The two Code values indicate a race condition where the AN may 1290 have just completed a transfer of bandwidth to the NAS. As a 1291 result, the value given in the Bandwidth Transfer message may be 1292 outdated, and the AN needs to query the NAS to find its latest 1293 view. The procedure assumes that ordering is preserved between 1294 the Bandwidth Transfer message sent by the AN in response to the 1295 NAS's request and the subsequent Delegated Bandwidth Query Request 1296 message. 1298 If as the result of the procedures just described the AN determines 1299 that it has over-committed multicast bandwidth, it MUST NOT terminate 1300 any currently-active programs, but MUST NOT honour any more "join" 1301 requests until it is possible to do so within the limit set by its 1302 current value of delegated bandwidth. 1304 4.7. Delegated Bandwidth Query Request Message 1306 The Message Type for the Delegated Bandwidth Query Request (and 1307 Response) messages is 0x96. 1309 The Delegated Bandwidth Query Request message MAY be sent either by 1310 the NAS or by the AN to retrieve the peer's view of the amount of 1311 delegated bandwidth. The request contains one TLV: 1313 o a Target TLV designating the access line for which the information 1314 is requested. 1316 4.7.1. Sender Behaviour 1318 The sender MUST set the Result field in the header of the Delegated 1319 Bandwidth Query Request message to AckAll (0x2). The Code value MUST 1320 be set to 0x000. The sender MUST populate the ANCP Transaction 1321 Identifier field with a unique value, as described in section 5.4.5 1322 of [I-D.ietf-ancp-protocol]. 1324 4.7.2. Receiver Behaviour 1326 If the AN or NAS receives a valid Delegated Bandwidth Query Request 1327 message, it MUST respond with a Delegated Bandwidth Query Response 1328 message. The Result field in the header of the response MUST be set 1329 to Success (0x3). The Code field MUST be set to 0x000. The 1330 Transaction-Id field MUST be copied from the request message. The 1331 body of the response MUST contain the Target TLV, copied from the 1332 request message. Finally, the body of the response MUST contain a 1333 Bandwidth-Allocation TLV, containing the current amount of delegated 1334 bandwidth from the point of view of the receiver of the request. 1336 If the contents of the Delegated Bandwidth Query Request message are 1337 in error, the receiver MUST return a Delegated Bandwidth Query 1338 Response message with the Result field in the header set to Failure 1339 (0x3). The Code field MUST be set to the value that indicates the 1340 nature of the error (e.g., 0x004 "Unrecognized target"). The 1341 Transaction-Id field MUST be copied from the request. The body of 1342 the response MUST contain the Target TLV copied from the request. 1343 This MAY be followed by a Status-Info TLV giving further infromation 1344 about the error. 1346 4.8. Delegated Bandwidth Query Response Message 1348 The Delegated Bandwidth Query Response message is sent in reply to a 1349 Delegated Bandwidth Query Request. The response to a valid request 1350 contains two TLVs: 1352 o the Target TLV, copied from the request; 1354 o a Bandwidth-Allocation TLV, giving the responder's view of the 1355 current amount of multicast bandwidth delegated to the AN. 1357 The Message Type for the Delegated Bandwidth Query Response message 1358 is 0x96. 1360 4.8.1. Sender Behaviour 1362 Sender behaviour for the Delegated Bandwidth Query Response message 1363 is specified in Section 4.7.2. 1365 4.8.2. Receiver Behaviour 1367 If the Delegated Bandwidth Query Response message indicates Success 1368 (0x3), the following actions apply. 1370 4.8.2.1. Behaviour at the NAS 1372 If the amount of delegated bandwidth provided in the Bandwidth- 1373 Allocation TLV is less than the NAS's view of the current amount of 1374 delegated bandwidth, the NAS MUST update its view of the current 1375 amount of delegated bandwidth to the amount indicated in the 1376 Delegated Bandwidth Query Response message. 1378 If the amount of delegated bandwidth provided in the Bandwidth- 1379 Allocation TLV is greater than the NAS's view of the current amount 1380 of delegated bandwidth, the NAS MAY accept the given value as its new 1381 value of delegated bandwidth. Alternatively, the NAS MAY force the 1382 AN to modify its view of the amount of delegated bandwidth to that 1383 held by the NAS, by sending a Port Management message for the target 1384 access line concerned, containing a Bandwidth-Allocation TLV with a 1385 value equal to the amount of delegated bandwidth the NAS wishes to 1386 enforce. 1388 4.8.2.2. Behaviour at the AN 1390 The AN SHOULD accept the value returned in the Bandwidth- Allocation 1391 TLV of the Delegated Bandwidth Query Response message as the correct 1392 value of the current amount of delegated bandwidth. If the AN has 1393 currently committed more than this amount to active programs, it MUST 1394 NOT cease replicating the flows concerned, but MUST NOT honour any 1395 more Join requests until possible to do so within the new limit. 1397 A race condition is possible, where the AN sends a query, the NAS 1398 requests more bandwidth, then receives and responds to the query, 1399 then receives the Bandwidth Transfer message responding to its 1400 request. It is up to the AN to take appropriate action in this 1401 case. The best action appears to be not to act on the result of 1402 the first query, but to repeat the query after sending the 1403 Bandwidth Transfer message. Similar considerations apply to a 1404 race between queries from both sides. 1406 4.9. Multicast Flow Query Request and Response Messages 1408 This section defines two new messages called the Multicast Flow Query 1409 Request and Multicast Flow Query Response. The Multicast Flow Query 1410 Request is sent by the NAS to request information about the multicast 1411 flows that are active on the AN. The Multicast Flow Query Response 1412 is sent in response by the AN to provide the requested information to 1413 the NAS. 1415 The Message Type for the Multicast Flow Query Request and Multicast 1416 Flow Query Response messages is 0x97. 1418 The contents of the Multicast Flow Query Request and Response depend 1419 on the nature of the query, as described below. 1421 4.9.1. Sender Behaviour 1423 The sender of a Multicast Flow Query Request message MUST set the 1424 Result field to AckAll (0x2). The Code field MUST be set to 0x000. 1425 The sender MUST populate the ANCP Transaction Identifier field with a 1426 unique value, as described in section 5.4.5 of [I-D.ietf-ancp- 1427 protocol]. 1429 The Multicast Flow Query Request MAY be used by the NAS to retrieve: 1431 o the AN's view of which multicast flows are currently active on a 1432 specified set of access ports; or 1434 o the AN's view of the access ports on which a specified set of 1435 multicast flows are currently active; or 1437 o the AN's view of all the multicast flows currently active on each 1438 and every port of the AN. 1440 To retrieve the AN's view of which multicast flows are currently 1441 active on one (or multiple) given port(s) of the AN, the Multicast 1442 Flow Query Request payload MUST contain the following TLVs: 1444 o Target TLV. It MUST appear at least once. Each occurence 1445 identifies one AN port for which information on active multicast 1446 flows is queried. It is encoded as specified in 1447 [I-D.ietf-ancp-protocol]. 1449 To retrieve the AN's view of which ports one (or multiple) given 1450 multicast flow(s) is (are) currently active on, the Multicast Flow 1451 Query Request payload MUST contain the following TLVs: 1453 o Multicast-Flow TLV. It MUST appear at least once. Each occurence 1454 identifies one multicast flow for which information is queried. 1455 It is encoded as specified in Section 5.10. 1457 To retrieve the AN's view of all the multicast flows currently active 1458 on each port of the AN, the Multicast Flow Query Request payload MUST 1459 NOT contain any instance of the Target TLV or the Multicast-Flow TLV. 1461 4.9.2. Receiver Behaviour 1463 The AN MUST respond to a Multicast Flow Query Request message that 1464 has a valid format and a valid content with a Multicast Flow Query 1465 Response message. The Result field in the response MUST be set to 1466 Success (0x3). The Code field MUST be set to 0x000. The 1467 Transaction-Id field MUST be copied from the request. 1469 If the Multicast Flow Query Request contained one (or more) Target 1470 TLVs, the AN MUST include, for each of these Target TLVs, the 1471 following set of TLVs: 1473 o Target TLV. This MUST be identical to the Target TLV in the 1474 received Multicast Flow Query Request message. 1476 o Multicast-Flow TLV(s). The Multicast-Flow TLV MUST appear once 1477 per multicast flow that is currently active on the AN port 1478 identified in the preceding Target TLV. 1480 The Target TLVs MUST appear in the response from the AN in the same 1481 order as in the query from the NAS. 1483 If the Multicast Flow Query Request contained one (or more) 1484 Multicast-Flow TLVs, the AN MUST include, for each of these 1485 Multicast-Flow TLVs, the following set of TLVs: 1487 o Multicast-Flow TLV.This MUST be identical to the Target TLV in the 1488 received Multicast Flow Query Request message. 1490 o Target TLV(s). The Target TLV MUST appear once per AN port on 1491 which the multicast flow identified in the preceding Multicast 1492 Flow TLV is active. 1494 The Multicast-Flow TLVs MUST appear in the response from the AN in 1495 the same order as in the query from the NAS. 1497 If the Multicast Flow Query Request contained no Target TLV and no 1498 Multicast Flow TLV, the AN MUST include, for each AN port, the 1499 following set of TLVs: 1501 o Target TLV. This MUST identify one AN port. 1503 o Multicast-Flow TLV(s). The Multicast-Flow TLV MUST appear once 1504 per Multicast Flow that is currently active on the AN port 1505 identified in the preceding Target TLV. 1507 If the contents of the Multicast Flow Query Request are in error, the 1508 AN MUST reply with a Multicast Flow Query Response message with the 1509 Result field set to Failure (0x4) and the Code field set to indicate 1510 the nature of the error. If the request contained multiple instances 1511 of the Target TLV or the Multicast-Flow TLV and one of these is in 1512 error, the response message MUST contain the results for the 1513 preceding instances of the TLV as if there had been no error. These 1514 successful results MUST be followed by the TLV in error, copied from 1515 the request. The AN MUST NOT do further processing of the request. 1516 The AN MAY add a Status-Info TLV to provide further information on 1517 the nature of the error. 1519 5. ANCP TLVs and Sub-TLVs 1521 This section defines new ANCP TLVs and sub-TLVs or extends existing 1522 ones. 1524 5.1. Multicast-Service-Profile TLV 1526 This document defines the new Multicast-Service-Profile TLV. 1528 The Multicast-Service-Profile TLV MAY be included in a Provisioning 1529 message as specified in Section 4.1. 1531 The Multicast-Service-Profile is illustrated in Figure 6. It 1532 consists of a TLV header, a Multicast-Service-Profile-Name sub-TLV, 1533 and one or more List-Action sub-TLVs. The sub-TLVs are packed 1534 consecutively with no intervening padding. 1536 1 2 3 1537 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 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 |TLV Type = Mcast Service Profile | TLV Length | 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 | Multicast-Service-Profile-Name Sub-TLV | 1542 | Sub-TLV type = 0x01 | 1543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1544 | List-Action Sub-TLV | 1545 | Sub-TLV type = 0x02 | 1546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1547 | ... | 1548 | | 1549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1550 | List-Action Sub-TLV | 1551 | Sub-TLV type = 0x02 | 1552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1554 Figure 6: Multicast-Servive-Profile TLV 1556 Multicast Service Profile TLV Type: 1558 TLV (0x13) : indicating that this is a Multicast Service 1559 Profile TLV 1561 The Multicast-Service-Profile-Name sub-TLV is shown in Figure 7. It 1562 consists of an eight-bit sub-TLV identifier with value 0x01, an 1563 eight-bit length field, and an identifier. The length field gives 1564 the length of the identifier in octets. The identifier consists of 1565 an opaque sequence of octets used to refer to the profile when 1566 activating it for a given target within a Port Management message 1567 (see Section 4.2). The identifier MUST be unique over all profiles 1568 provisioned to the same AN partition. 1570 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 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 | Type = 0x01 | Length | Identifier ... 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1575 Figure 7: Multicast-Service-Profile-Name sub-TLV 1577 The List-Action sub-TLV is shown in Figure 8. It consists of an 1578 eight-bit sub-TLV identifier with value 0x02, a four-bit action 1579 field, a four-bit list type field, a sixteen-bit length, and a 1580 sequence of multicast flow fields organized by address family. 1581 Either an IPv4 list or an IPv6 list or both MAY be present in the 1582 sub-TLV. 1584 1 2 3 1585 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 1586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1587 | Type = 0x02 | Oper | LType | Length | 1588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 | IP Version | List Length | 1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1591 | Multicast flow fields | 1592 ...... 1593 | | 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 | IP Version | List Length | 1596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1597 | Multicast flow fields | 1598 ...... 1599 | | 1600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 Figure 8: List-Action Sub-TLV 1604 The fields within the List-Action TLV are defined as follows: 1606 Type: always 0x02. 1608 Oper: operation to be performed. The possible values are Add (0x1), 1609 Delete (0x2), or Replace (0x3). The operation indicates whether 1610 the listed multicast flows are to be added to the list identified 1611 by the list type field within the profile identified by the 1612 Multicast-Service-Profile-Name sub-TLV, deleted from that list, or 1613 whether the listed flows should replace the current contents of 1614 the identified list. 1616 Ltype: the list type being modified by this list action. The 1617 possible values are White (0x1), Black (0x2), or Grey (0x3). 1619 Length: the length (in octets) of the contents of the List-Action 1620 sub-TLV following the Length field itself. 1622 IP Version: the IP version of the set of multicast flow fields that 1623 follow. Possible values are 0x0000 (IPv4) or 0x0001 (IPv6). As 1624 indicated above, either an IPv4 list or an IPv6 list or both MAY 1625 be present in the sub-TLV. 1627 List length: the length (in octets) of the list of multicast flow 1628 fields following the list length field. 1630 Multicast flow field: a field identifying one or more multicast 1631 flows. It consists of an 8-bit group address prefix length, an 1632 8-bit source address prefix length, a 0-16 octet group prefix, and 1633 a 0-16 octet source prefix, as shown in Figure 9. 1635 Each multicast flow field refers either to a Single Source Multicast 1636 (SSM) channel or to an Any Source Multicast (ASM) group. The scope 1637 of the designation may be broadened to multiple channels or groups 1638 through use of prefix length values smaller than the total address 1639 length for the given address family. Multicast flow fields MUST be 1640 placed consecutively within the sub-TLV without intervening padding 1641 except to round out individual addresses to the nearest octet 1642 boundary. 1644 A multicast flow field consists of two single-octet prefix lengths 1645 followed by zero to two prefix values as shown in Figure 9: 1647 +-+-+-+-+-+-+-+-+ 1648 | Group PrefLen | 1649 +-+-+-+-+-+-+-+-+ 1650 | Source PrefLen| 1651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1652 | Group Prefix (multicast) (0 to 16 octets) | 1653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 | Source Prefix (unicast, SSM only) (0 to 16 octets) | 1655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1657 Figure 9: Organization of a Single Multicast Flow Field 1659 The prefix length has its usual meaning. It is the number of most- 1660 significant bits specified within the corresponding prefix. The 1661 prefix length MAY vary from 0 to 32 in the IPv4 sub-list, and from 0 1662 to 128 in the IPv6 sub-list. 1664 A value of 0x00 for either the Group PrefLen (prefix length) or the 1665 Source PrefLen indicates that any value of the corresponding address 1666 will match (wild card). If the value 0x00 is provided for a 1667 particular prefix length, the corresponding prefix MUST be omitted 1668 from the field contents. In particular, a value of 0x00 for the 1669 Source PrefLen indicates an ASM multicast entry, and the Source 1670 Prefix will be absent. 1672 The length of a Source or Group Prefix field is equal to (PrefLen + 1673 7)/8 octets, truncated to the nearest integer. Unused bits at the 1674 end of the prefix MUST be set to zeroes. 1676 5.2. Command Number TLV 1678 The Command Number TLV conveys the sequence number of a specific 1679 command within a Multicast Replication Control or Multicast Admission 1680 Request message. Within this specification, the Command Number TLV 1681 itself is used as a sub-TLV within a Status-Info TLV, in a Generic 1682 Response reporting a failed command. 1684 The Command TLV has the format shown in Figure 10. The sequnce 1685 number field is the sequence number of a specific command within a 1686 request, where numbering starts from 1 for the first command. 1688 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 1689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1690 |TLV Type = Command Number | TLV Length = 2 | 1691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1692 | Sequence number | 1693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1695 Figure 10: Structure of the Command Number TLV 1697 5.3. Bandwidth-Allocation TLV 1699 The Bandwidth-Allocation TLV is used to indicate the total amount of 1700 video bandwidth delegated to the AN for multicast admission control 1701 for a given access line, in kilobits per second. The TLV has the 1702 format shown in Figure 11. The TLV Type for the Bandwidth-Allocation 1703 TLV is 0x15. 1705 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 1706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1707 |TLV Type = BW-Allocation | TLV Length = 4 | 1708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1709 | Delegated amount (kbits/s) | 1710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1712 Figure 11: The Bandwidth-Allocation TLV 1714 5.4. White-List-CAC TLV 1716 The White-List-CAC TLV is used to indicate that the NAS wishes the AN 1717 to do admission control for White-listed flows. Details on when the 1718 White-List-CAC TLV may be provisioned are specified in Section 6. 1720 The White-List-CAC TLV contains no data, thus its TLV Length field 1721 MUST have value 0. 1723 5.5. MRepCtl-CAC TLV 1725 The MRepCtl-CAC TLV is used to indicate that the NAS wishes the AN to 1726 do admission control for flows added by the Multicast Replication 1727 Control message. Details on when the MRepCtl-CAC TLV may be 1728 provisioned are specified in Section 6. 1730 The MRepCtl-CAC TLV contains no data, thus its TLV Length field MUST 1731 have value 0. 1733 5.6. Bandwidth-Request TLV 1735 The Bandwidth-Request TLV is used to request an adjustment of the 1736 total amount of video bandwidth allocated to the AN for multicast 1737 admission control for a given line. The "Required amount" field 1738 indicates the minimum adjustment required to meet the request. The 1739 "Preferred amount" field indicates the adjustment the requestor would 1740 prefer to have, if possible. Section 4.5 discusses the required 1741 relationships between the "Required amount", "Preferred amount", and 1742 current values of total bandwidth allocated to the AN. 1744 The Bandwidth-Request TLV has the format shown in Figure 12. The TLV 1745 Type for the Bandwidth-Request TLV is 0x16. 1747 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 1748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1749 |TLV Type = 0x16 | TLV Length = 8 | 1750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1751 | Required amount (kbits/s) | 1752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1753 | Preferred amount (kbits/s) | 1754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1756 Figure 12: The Bandwidth-Request TLV 1758 5.7. Multicast-Service-Profile-Name TLV 1760 The Multicast-Service-Profile-Name TLV carries the identifier of a 1761 multicast service profile provisioned on the AN. 1763 o Type (Multicast-Service-Profile-Name = 0x18): Reference to a 1764 multicast service profile on the AN, that defines a White, Black, 1765 and/or Grey List depending on the set of negotiated capabilities. 1767 o Length : (up to 255 octets) 1769 o Value : opaque sequence of octets identifying a specific profile. 1770 This MUST match one of the multicast service profile names 1771 provisioned on the AN in a Provisioning message or by other means. 1773 5.8. Request-Source-IP sub-TLV 1775 [I-D.ietf-ancp-protocol] defines the Command TLV that can be used in 1776 a Multicast Replication Control message and (as defined in this 1777 document) in the Admission Control message. The Command TLV MAY 1778 include sub-TLVs immediately following the Command Info field. 1780 This document defines the new Request-Source-IP sub-TLV. 1782 The Request-Source-IP sub-TLV MAY be included in a Command TLV inside 1783 an Admission Control message. 1785 The Request-Source-IP sub-TLV is illustrated below: 1787 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 1788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1789 |sub-TLV Type = Request-Source-IP | Request-S-IP sub-TLV Length | 1790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1791 | Addr Family | Encoding Type | Unicast Address | 1792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1794 Request-Source-IP sub-TLV Type: 1796 sub-TLV (0x92) indicating the contents to be a Request- 1797 Source-IP sub-TLV. 1799 Request-Source-IP sub-TLV Length: 1801 Combined length in bytes of the data inside sub-TLV. 1802 Excludes the sub-TLV Header. 1804 Address Family, Encoding type and Unicast Address: 1806 Contains the IP address of the sender of the join/leave 1807 message (e.g. IGMP/MLD Join/Leave) that triggered the AN 1808 to include the corresponding Command TLV in an Admission 1809 Control message. The IP address is encoded as per 1810 [IANAAEA]. 1812 5.9. Request-Source-MAC sub-TLV 1814 This document defines the new Request-Source-MAC sub-TLV. 1816 The Request-Source-MAC sub-TLV MAY be included in a Command TLV 1817 inside an Admission Control message. 1819 The Request-Source-MAC sub-TLV is illustrated below: 1821 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 1822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1823 |sub-TLV Type=Request-Source-MAC |Request-S-MAC sub-TLV Length | 1824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1825 | TBD | 1826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1828 Request-Source-MAC sub-TLV Type: 1830 sub-TLV (0x93) indicating the contents to be a Request- 1831 Source-MAC sub-TLV. 1833 Request-Source-MAC sub- TLV Length: 1835 Combined length in bytes of the data inside sub-TLV. 1836 Excludes the sub-TLV Header. 1838 TBD: 1840 Contains the IEEE MAC address of the sender of the join/ 1841 leave message (e.g. IGMP/MLD Join/Leave) that triggered 1842 the AN to include the corresponding Command TLV in an 1843 Admission Control message. The IP address is encoded as 1844 per TBD. 1846 5.10. Multicast-Flow TLV 1848 This document defines the new Multicast-Flow TLV. 1850 The Multicast-Flow TLV MAY be included in a Multicast Flow Query 1851 Request or Response message as specified in Section 4.9. 1853 The Multicast-Flow TLV is illustrated below: 1855 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 1856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1857 |TLV Type = Multicast-Flow | TLV Length | 1858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1859 | Addr Family | Encoding Type | Multicast Flow Source Address | 1860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1861 | Multicast Flow Source Address (Cont'd) ... | 1862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1863 | Addr Family | Encoding Type | Multicast Flow Group Address | 1864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1865 | Multicast Flow Group Address (Cont'd) ... | 1866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1867 | ... | Padding to 32-bit boundary | 1868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1870 Multicast-Flow TLV 1872 Multicast-Flow TLV Type: 1874 TLV (0x19) : indicating that this is a Multicast-Flow TLV 1876 Multicast-Flow TLV Length: 1878 Length in bytes of the Value field of the TLV. Excludes 1879 the TLV Header (Type and Length). 1881 Addr Family, Encoding Type, Multicast Flow Source Address, Multicast 1882 Flow Group Address and Padding are encoded as specified for the 1883 corresponding field of the Command TLV in Section 4.3. 1885 6. Multicast Capabilities 1887 Section 5.3 of [I-D.ietf-ancp-protocol] defines a capability 1888 negotiation mechanism as well as a number of capabilities. This 1889 section defines four new capabilities in support of different modes 1890 of multicast operation: 1892 o NAS-initiated replication (capability type 0x05); 1894 o conditional access with white and black lists (capability type 1895 0x06); 1897 o conditional access with grey lists (capability type 0x07); 1899 o bandwidth delegation (capability type 0x08). 1901 The "Capability Data" field within the Capability TLV for all of 1902 these capabilities is empty. 1904 The remainder of this section consists of three sub-sections. 1905 Section 6.1 specifies the protocol elements that must be implemented 1906 in order to support each capability. Section 6.2 specifies the 1907 procedures that apply to each capability on its own. Section 6.3 1908 specifies how the capabilities interact if more than one multicast 1909 capability is included in the set of capabilities negotiated between 1910 the AN and the NAS. 1912 Note that if a request contains content that is not supported 1913 (according to the tables in Section 6.1) by the negotiated set of 1914 multicast capabilities, the appropriate response is to return a 1915 Generic Response message indicating Failure (0x4) with an appropriate 1916 code value (e.g., 0x84 "TLV or value not supported by negotiated 1917 capability set"). The body of the message MUST contain a Status-Info 1918 TLV. See Sections 5.4.5.1 and 5.4.5.2 in [I-D.ietf-ancp-protocol] 1919 for more details. 1921 6.1. Required Protocol Support 1923 This section specifies the protocol elements that must be implemented 1924 to support each of the four multicast capabilities. Support of 1925 multiple multicast capabilities requires implementation of the union 1926 of the sets of protocol elements applying to each of the individual 1927 capabilities in the supported set. 1929 6.1.1. Protocol Requirements For NAS-initiated Replication 1931 Table 1 specifies the protocol elements within Section 4 and 1932 Section 5 that must be implemented to support the NAS-initiated 1933 replication multicast capability. 1935 +--------------+----------------------------------------------------+ 1936 | Reference | Protocol Element | 1937 +--------------+----------------------------------------------------+ 1938 | Section 4.1 | Provisioning message with MRepCtl_CAC TLV | 1939 | | | 1940 | Section 4.2 | Port Management message with Bandwidth-Allocation | 1941 | | TLV. | 1942 | | | 1943 | Section 4.3 | Multicast Replication Control message | 1944 | | | 1945 | Section 4.9 | Multicast Flow Query Request and Response messages | 1946 | | | 1947 | Section 5.2 | Command Number TLV | 1948 | | | 1949 | Section 5.5 | MRepCtl-CAC TLV | 1950 | | | 1951 | Section 5.10 | Multicast-Flow TLV | 1952 +--------------+----------------------------------------------------+ 1954 Table 1: Protocol Support Requirements For NAS-initiated Replication 1956 6.1.2. Protocol requirements For Conditional Access With White and 1957 Black Lists 1959 Table 2 specifies the protocol elements within Section 4 and 1960 Section 5 that must be implemented to support the conditional access 1961 with white and black lists multicast capability. 1963 +--------------+----------------------------------------------------+ 1964 | Reference | Protocol Element | 1965 +--------------+----------------------------------------------------+ 1966 | Section 4.1 | Provisioning message with | 1967 | | Multicast-Service-Profile TLV, White and Black | 1968 | | lists only, and White-List-CAC TLV | 1969 | | | 1970 | Section 4.2 | Port Management message with | 1971 | | Multicast-Service-Profile-Name and | 1972 | | Bandwidth-Allocation TLVs. | 1973 | | | 1974 | Section 4.9 | Multicast Flow Query Request and Response messages | 1975 | | | 1976 | Section 5.1 | Multicast-Service-Profile TLV, White and Black | 1977 | | lists only | 1978 | | | 1979 | Section 5.3 | Bandwidth-Allocation TLV | 1980 | | | 1981 | Section 5.4 | White-List-CAC TLV | 1982 | | | 1983 | Section 5.7 | Multicast-Service-Profile-Name TLV | 1984 | | | 1985 | Section 5.10 | Multicast-Flow TLV | 1986 +--------------+----------------------------------------------------+ 1988 Table 2: Protocol Support Requirements For Conditional Access with 1989 White and Black Lists 1991 6.1.3. Protocol requirements For Conditional Access With Grey Lists 1993 Table 3 specifies the protocol elements within Section 4 and 1994 Section 5 that must be implemented to support the conditional access 1995 with grey lists multicast capability. 1997 +--------------+----------------------------------------------------+ 1998 | Reference | Protocol Element | 1999 +--------------+----------------------------------------------------+ 2000 | Section 4.1 | Provisioning message with | 2001 | | Multicast-Service-Profile TLV, Grey lists only, | 2002 | | and MRepCtl_CAC TLV | 2003 | | | 2004 | Section 4.2 | Port Management message with | 2005 | | Multicast-Service-Profile-Name and | 2006 | | Bandwidth-Allocation TLVs. | 2007 | | | 2008 | Section 4.3 | Multicast Replication Control message | 2009 | | | 2010 | Section 4.4 | Multicast Admission Control Message | 2011 | | | 2012 | Section 4.9 | Multicast Flow Query Request and Response messages | 2013 | | | 2014 | Section 5.1 | Multicast-Service-Profile TLV, Grey lists only | 2015 | | | 2016 | Section 5.2 | Command Number TLV | 2017 | | | 2018 | Section 5.3 | Bandwidth-Allocation TLV | 2019 | | | 2020 | Section 5.5 | MRepCtl-CAC TLV | 2021 | | | 2022 | Section 5.7 | Multicast-Service-Profile-Name TLV | 2023 | | | 2024 | Section 5.8 | Request-Source-IP sub-TLV | 2025 | | | 2026 | Section 5.9 | Request-Source-MAC sub-TLV | 2027 | | | 2028 | Section 5.10 | Multicast-Flow TLV | 2029 +--------------+----------------------------------------------------+ 2031 Table 3: Protocol Support Requirements For Conditional Access with 2032 Grey Lists 2034 6.1.4. Protocol requirements For Delegated Bandwidth 2036 Table 4 specifies the protocol elements within Section 4 and 2037 Section 5 that must be implemented to support the delegated bandwidth 2038 multicast capability. 2040 +--------------+----------------------------------------------------+ 2041 | Reference | Protocol Element | 2042 +--------------+----------------------------------------------------+ 2043 | Section 4.2 | Port Management message with Bandwidth-Allocation | 2044 | | TLV. | 2045 | | | 2046 | Section 4.5 | Bandwidth Reallocation Request Message | 2047 | | | 2048 | Section 4.6 | Bandwidth Transfer Message | 2049 | | | 2050 | Section 4.7 | Delegated Bandwidth Query Request Message | 2051 | | | 2052 | Section 4.8 | Delegated Bandwidth Query Response Message | 2053 | | | 2054 | Section 4.9 | Multicast Flow Query Request and Response messages | 2055 | | | 2056 | Section 5.3 | Bandwidth-Allocation TLV | 2057 | | | 2058 | Section 5.6 | Bandwidth-Request TLV | 2059 | | | 2060 | Section 5.10 | Multicast-Flow TLV | 2061 +--------------+----------------------------------------------------+ 2063 Table 4: Protocol Support Requirements For Delegated Bandwidth 2065 6.2. Capability-Specific Procedures for Providing Multicast Service 2067 This section describes multicast service procedures for each 2068 capability as if it were the only multicast capability within the 2069 negotiated set. Procedures involving combinations of multicast 2070 capabilities are described in Section 6.3. 2072 The use of the Multicast Flow Query Request and Response messages to 2073 determine the association between multicast flows and ports is common 2074 to all multicast capabilities. No additional text is required here, 2075 beyond that already given in Section 4.9 to describe the use of those 2076 messages. 2078 6.2.1. Procedures For NAS-initiated Replication 2080 NAS-initiated replication MAY be negotiated to support a mode of 2081 operation where IGMP/MLD requests are terminated on the NAS. 2082 Alternatively, it MAY be negotiated to allow the NAS to respond to 2083 requests sent by other means (e.g., through application signalling) 2084 that require the replication of multicast channels to a given access 2085 line. 2087 The NAS MAY enable admission control at the AN for Nas-initiated 2088 replication. To do this, it MUST include the MRepCtl-CAC TLV in a 2089 Provisioning message sent to the AN. It MUST also include a 2090 Bandwidth-Allocation TLV in a Port Management message for each access 2091 line. 2093 The procedures associated with NAS-initiated replication are 2094 straightforward. To initiate replication, the NAS MUST send a 2095 Multicast Replication Control message to the AN, containing one or 2096 more commands adding flows, as described in section ReplicSend. If 2097 it does admission control itself, it MUST set the R flag in the Add 2098 commands. If it has enabled admission control in the AN and wishes 2099 the AN to perform admission control for the flows, it MUST clear the 2100 R flag in the Command TLV requesting the flow addition. To terminate 2101 replication the NAS MUST send a a Multicast Replication Control 2102 message where the commands delete instead of adding them flows. 2104 6.2.2. Procedures For Conditional Access With Black and White Lists 2106 6.2.2.1. Provisioning 2108 The NAS provisions named multicast service profiles containing White 2109 and Black lists on the AN using the Provisioning message containing 2110 one or more Multicast-Service-Profile TLVs. The NAS MAY update the 2111 contents of these profiles from time to time as required, by sending 2112 additional Provisioning messages with Multicast-Service-Profile TLVs 2113 containing incremental modifications to the existing White and Black 2114 lists or replacements for them. 2116 The NAS assigns a specific multicast service profile to an individual 2117 access line using the Port Management message containing a Multicast- 2118 Service-Profile-Name TLV. 2120 The NAS MAY choose to enable admission control at the AN for White- 2121 listed flows. To do this, it MUST send a Provisioning message as 2122 described in section provisioning, which includes the White-List-CAC 2123 TLV. It MUST also provide a multicast bandwidth allocation for each 2124 access line by including a Bandwidth-Allocation TLV in a Port 2125 Management message. 2127 6.2.2.2. Multicast Service Procedures 2129 The conditional access with White and Black lists capability assumes 2130 that IGMP/MLD requests are terminated on the AN. When the AN 2131 receives a "join" request, it MUST check to see whether the requested 2132 flow is White-listed or Black-listed as described below. Requests 2133 for Black-listed flows MUST be discarded. If the NAS has enabled 2134 admission control on the given access line as described in the 2135 previous section, but the flow would cause the amount of committed 2136 multicast bandwidth to exceed the provisioned limit, the request MUST 2137 be discarded. Flows passing these checks are replicated to the 2138 access line. 2140 To determine if a requested flow is White-listed, the AN searches for 2141 a best match to the flow in the applicable multicast service profile. 2142 Matching is done on the prefixes specified in the profile, ignoring 2143 the address bits of lower order than those in the prefix. 2145 If the requested multicast flow matches multiple lists associated 2146 with the access line, then the most specific match will be considered 2147 by the AN. If the most specific match occurs in multiple lists, the 2148 Black list entry takes precedence over the White list. In this 2149 context, the most specific match is defined as: 2151 o first, most specific match (longest prefix length) on the 2152 multicast flow address (i.e., on G of ) 2154 o then, most specific match (longest prefix length) on the multicast 2155 source address (i.e. on S of ) 2157 If the requested multicast flow is not part of any list, the join 2158 message SHOULD be discarded by the AN. This default behavior can 2159 easily be changed by means of a "catch-all" statement in the White 2160 list. For instance, adding () in the White List would make 2161 the default behavior to accept join messages for a multicast flow 2162 that has no other match on any list. 2164 When the AN receives a "leave" request, it terminates replication of 2165 the multicast flow. 2167 6.2.3. Procedures For Conditional Access With Grey Lists 2169 6.2.3.1. Provisioning 2171 The NAS provisions named multicast service profiles containing Grey 2172 lists on the AN using the Provisioning message containing one or more 2173 Multicast-Service-Profile TLVs. The NAS MAY update the contents of 2174 these profiles from time to time as required, by sending additional 2175 Provisioning messages with Multicast-Service-Profile TLVs containing 2176 incremental modifications to the existing Grey lists or replacements 2177 for them. 2179 The NAS assigns a specific multicast service profile to an individual 2180 access line using the Port Management message containing a Multicast- 2181 Service-Profile-Name TLV. 2183 The NAS can enable admission control at the AN for Grey-listed flows. 2185 To do this, it MUST include the MRepCtl-CAC TLV in a Provisioning 2186 message sent to the AN. It MUST also provide a Bandwidth-Allocation 2187 TLV in a Port Management message for each access line. 2189 6.2.3.2. Multicast Service Procedures 2191 The conditional access with Grey lists capability assumes that IGMP/ 2192 MLD requests are terminated on the AN. When the AN receives a "join" 2193 request, it MUST determine whether there is a match to the requested 2194 flow in the Grey list of the multicast service profile provisioned 2195 against the given access line. If there is no match, the request is 2196 discarded. Otherwise, the AN MUST send a Multicast Admission Control 2197 message to the NAS with content identifying the access line and the 2198 multicast flow to be added. As indicated in Section 4.4, the AN MAY 2199 add information identifying the requestor by IP address and/or MAC 2200 address. 2202 If the NAS decides to enable the flow, it MUST send a Multicast 2203 Replication Control request to the AN to replicate the flow to the 2204 access line with the Result field set to Nack (0x1), as described in 2205 section ReplicSend. If admission control has been enabled at the AN 2206 for flows added by Multicast Replication Control messages, the NAS 2207 MAY invoke admission control for a specific flow at the AN by 2208 clearing the R flag in the Command TLV that adds the flow. 2210 When the AN receives the Multicast Replication Control request, it 2211 performs admission control if admission control has been enabled and 2212 invoked by the clearing of the R flag. If admitting the flow would 2213 cause the committed multicast bandwidth at the access line to exceed 2214 the provisioned limit, the AN reports an error to the NAS as 2215 described in section ReplicRecv. Otherwise it replicates the 2216 multicast flow as requested. 2218 If the NAS decides not to permit the flow, it MAY send a Multicast 2219 Replication Control message in response to the Multicast Admission 2220 Control message to allow the AN to update its internal records. The 2221 content of this message is described in Section 4.4.2. 2223 When the AN receives a "leave" request, it MUST terminate replication 2224 of the flow to the access line. It MUST then send a Multicast 2225 Admission Control message to the NAS indicating the deletion. The 2226 NAS updates its internal records but MUST NOT respond to the message. 2228 6.2.4. Procedures For Delegated Bandwidth 2229 6.2.4.1. Provisioning 2231 The NAS SHOULD provision an initial amount of delegated multicast 2232 bandwidth for each access line using the Port Management message 2233 containing the Bandwidth-Allocation TLV. (If it fails to do so and a 2234 value has not been provisioned on the AN by other means, the AN will 2235 be forced to request a bandwidth allocation as soon as it receives a 2236 "join" request.) 2238 6.2.4.2. Multicast Service Procedures 2240 The delegated bandwidth capability assumes that IGMP/MLD requests are 2241 terminated on the AN. When the AN receives a "join" request, it 2242 checks whether it has sufficient remaining uncommitted multicast 2243 bandwidth on the access line to accommodate the new multicast flow. 2244 If not, it MAY send a request to the NAS for an increased allocation 2245 of delegated bandwidth, using the Bandwidth Reallocation Request 2246 message. The NAS MUST return a Bandwidth Transfer message indicating 2247 whether it has granted the request, and if so, what is the new amount 2248 of delegated bandwidth. 2250 If the AN has sufficient uncommitted multicast capacity to admit the 2251 request, either originally or as the result of a successful request 2252 to the NAS, it replicates the requested flow to the access line. 2253 Otherwise it discards the request. 2255 When the AN receives a "leave" request for an active flow, it ceases 2256 replication. 2258 The NAS or AN MAY at some point detect that their respective views of 2259 the amount of delegated bandwidth are inconsistent. If so, they can 2260 recover using procedures described in Section 4.5 and Section 4.6. 2261 As a further aid to synchronization, either the NAS or the AN MAY 2262 from time to time check the peer's view of the amount of delegated 2263 bandwidth using the Delegated Bandwidth Query message. 2265 The NAS or AN MAY at any time release bandwidth to the peer using an 2266 autonomous Bandwidth Transfer message. The contents of this message 2267 are described in Section 4.6. 2269 6.3. Combinations of Multicast Capabilities 2271 6.3.1. Combination of NAS-Initiated Replication with Other Capabilities 2273 NAS-initiated replication can coexist with the other capabilities, 2274 but some means must exist to prevent double replication of flows. 2275 The simplest way to do this is to terminate all IGMP/MLD requests on 2276 the AN, so that NAS-initiated replication is stimulated by signalling 2277 through other channels. Other arrangements are possible, but need 2278 not be discussed here. 2280 Assuming the necessary separation of responsibilities, the only point 2281 of interaction between NAS-initiated replication and the other 2282 multicast capabilities is in the area of admission control. 2283 Specifically, inclusion of the MRepCtl-CAC TLV in a Provisiong 2284 message enables admission control for flows added by Multicast 2285 Replication Control messages, regardless of whether they are part of 2286 NAS-initiated replication or Grey list multicast service processing. 2287 The NAS can control whether the AN does admission control for 2288 individual flows by its setting or clearing of the R flag in the 2289 Command TLV. It is up to the NAS to choose how video bandwidth will 2290 be allocated between itself and the AN, and to choose which 2291 allocation must support specific requests. 2293 6.3.2. Conditional Access With White, Black, and Grey Lists 2295 If conditional access with White and Black lists is combined with 2296 conditional access with Grey lists, provisioning of the multicast 2297 service profiles is as described in Section 6.2.2.1 except that 2298 multicast service profiles will also include Grey lists. Admission 2299 control is enabled independently for White lists by including the 2300 White-list-CAC TLV in the Provisioning message and for Grey lists by 2301 including the MRepCtl-CAC TLV in the Provisioning message. The 2302 Bandwidth-Allocation TLV provisions an amount that applies to both 2303 White- and Grey- listed flows if admission control is enabled for 2304 both. 2306 With regard to multicast service procedures, one point of difference 2307 from the individual capabilities must be noted. This is an 2308 interaction during the profile matching procedure. The AN MUST seek 2309 the best match amongst multiple lists as described in 2310 Section 6.2.2.2. However, if there are multiple matches of equal 2311 precision, the order of priority is Black list first, Grey list 2312 second, and White list last. 2314 Once profile matching has been completed, processing of a "join" 2315 request is as described in Section 6.2.2.2 for White or Black listed 2316 flows or Section 6.2.3.2 for Grey listed flows. Requests that do not 2317 match any list SHOULD be discarded. 2319 When the AN receives a "leave" request, it MUST terminate replication 2320 of the flow to the access line. If the flow was Grey-listed, the AN 2321 MUST then send a Multicast Admission Control message to the NAS 2322 indicating the deletion. Thus the AN needs to retain the fact that 2323 the flow was Grey-listed for the life of the flow. 2325 6.3.3. Conditional Access Combined With Delegated Bandwidth 2327 If either or both conditional access capabilities are combined with 2328 the delegated bandwidth capability, the AN always does admission 2329 control. Delegated bandwith simply provides a means for flexible 2330 sharing of video bandwidth between the AN and the NAS or Policy 2331 Server. The provisioning, admission, and bandwidth management 2332 procedures of Section 6.2.4 apply in addition to the procedures in 2333 Section 6.2.2, Section 6.2.3, or Section 6.3.2 as applicable. 2335 7. Security Considerations 2337 The security considerations of ANCP are discussed in 2338 [I-D.ietf-ancp-protocol] and in [I-D.ietf-ancp-security-threats]. 2340 8. IANA Considerations 2342 This document defines the following additional values within the 2343 GSMPv3 Message Type Name Space registry: 2345 +--------------------------------+--------+---------------+ 2346 | Message | Number | Source | 2347 +--------------------------------+--------+---------------+ 2348 | Multicast Replication Control | 90 | This document | 2349 | | | | 2350 | Multicast Status | 91 | This document | 2351 | | | | 2352 | Multicast Admission Control | 92 | This document | 2353 | | | | 2354 | Bandwidth Reallocation Request | 94 | This document | 2355 | | | | 2356 | Bandwidth Transfer | 95 | This document | 2357 | | | | 2358 | Delegated Bandwidth Query | 96 | This document | 2359 | | | | 2360 | Multicast Flow Query | 97 | This document | 2361 +--------------------------------+--------+---------------+ 2363 This document defines the following values for the ANCP Status-Info 2364 Result Code Registry : 2366 +----------------------------------------------+--------+-----------+ 2367 | Status | Number | Reference | 2368 +----------------------------------------------+--------+-----------+ 2369 | Command not supported | 0x02 | This | 2370 | | | document | 2371 | | | | 2372 | Flag set but not supported | 0x03 | This | 2373 | | | document | 2374 | | | | 2375 | Unsupported Address Family | 0x05 | This | 2376 | | | document | 2377 | | | | 2378 | Malformed flow address | 0x06 | This | 2379 | | | document | 2380 | | | | 2381 | Configuration error (such as Port not | 0x0a | This | 2382 | enabled for multicast) | | document | 2383 | | | | 2384 | Multicast flow does not exist | 0x0b | This | 2385 | | | document | 2386 | | | | 2387 | Unsupported address encoding | 0x0c | This | 2388 | | | document | 2389 | | | | 2390 | Additional info needed to execute command | 0x0d | This | 2391 | (payload MAY contain an indication of the | | document | 2392 | expected info) | | | 2393 | | | | 2394 | Multicast flow count exceeded | 0x0e | This | 2395 | | | document | 2396 | | | | 2397 | M Flag set, but no IP Source address | 0x0f | This | 2398 | provided | | document | 2399 | | | | 2400 | Invalid preferred bandwidth amount | 0x11 | This | 2401 | | | document | 2402 | | | | 2403 | bandwidth delegation not activated | 0x12 | This | 2404 | | | document | 2405 | | | | 2406 | Delegated bandwidth reset required | 0x13 | This | 2407 | | | document | 2408 +----------------------------------------------+--------+-----------+ 2410 This document defines the following additional values within the ANCP 2411 TLV Type Registry: 2413 +--------------------------------+-----------+---------------+ 2414 | TLV Name | Type Code | Reference | 2415 +--------------------------------+-----------+---------------+ 2416 | Multicast-Service-Profile | 0x13 | This document | 2417 | | | | 2418 | Bandwidth-Delegation-Control | 0x14 | This document | 2419 | | | | 2420 | Bandwidth-Allocation | 0x15 | This document | 2421 | | | | 2422 | Bandwidth-Request | 0x16 | This document | 2423 | | | | 2424 | Bandwidth-Status | 0x17 | This document | 2425 | | | | 2426 | Multicast-Service-Profile-Name | 0x18 | This document | 2427 | | | | 2428 | Multicast-Flow | 0x19 | This document | 2429 +--------------------------------+-----------+---------------+ 2431 This document defines the following values for the ANCP Command Code 2432 registry: 2434 +-------------------------------------+----------------+------------+ 2435 | Command Code Directive Name | Command Code | Reference | 2436 | | Value | | 2437 +-------------------------------------+----------------+------------+ 2438 | Add | 0x01 | This | 2439 | | | document | 2440 | | | | 2441 | Delete | 0x02 | This | 2442 | | | document | 2443 | | | | 2444 | Delete All | 0x03 | This | 2445 | | | document | 2446 | | | | 2447 | Admission Control Reject | 0x04 | This | 2448 | | | document | 2449 | | | | 2450 | Conditional Access Reject | 0x05 | This | 2451 | | | document | 2452 | | | | 2453 | Admission Control and Conditional | 0x06 | This | 2454 | Access Reject | | document | 2455 +-------------------------------------+----------------+------------+ 2457 This document defines the following additional values to the ANCP 2458 sub-TLV Type registry: 2460 +--------------------+-----------+---------------+ 2461 | sub-TLV Name | Type Code | Reference | 2462 +--------------------+-----------+---------------+ 2463 | Request-Source-IP | 0x92 | This document | 2464 | | | | 2465 | Request-Source-MAC | 0x93 | This document | 2466 +--------------------+-----------+---------------+ 2468 9. Acknowledgements 2470 The authors would like to acknowledge Wojciech Dec for providing 2471 useful input to this document, Robert Rennison for his help in 2472 shaping the definition of the Multicast-Service-Profile TLV, Shridhar 2473 Rao for his comments and suggestions and Aniruddha A for his proposal 2474 that formed the base of the Multicast Flow Reporting solution. 2475 Philippe Champagne, Sanjay Wadhwa and Stefaan De Cnodder provided 2476 substantial contributions on the solution for the NAS initiated 2477 multicast control use case. 2479 10. References 2481 10.1. Normative References 2483 [I-D.ietf-ancp-framework] 2484 Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. 2485 Wadhwa, "Framework and Requirements for an Access Node 2486 Control Mechanism in Broadband Multi-Service Networks", 2487 draft-ietf-ancp-framework-12 (work in progress), 2488 October 2009. 2490 [I-D.ietf-ancp-protocol] 2491 Wadhwa, S., Moisand, J., Subramanian, S., Haag, T., Voigt, 2492 N., and R. Maglione, "Protocol for Access Node Control 2493 Mechanism in Broadband Networks", 2494 draft-ietf-ancp-protocol-07 (work in progress), 2495 October 2009. 2497 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2498 Requirement Levels", BCP 14, RFC 2119, March 1997. 2500 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 2501 Listener Discovery (MLD) for IPv6", RFC 2710, 2502 October 1999. 2504 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 2505 Thyagarajan, "Internet Group Management Protocol, Version 2506 3", RFC 3376, October 2002. 2508 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 2509 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 2511 10.2. Informative References 2513 [I-D.ietf-ancp-security-threats] 2514 Moustafa, H., Tschofenig, H., and S. Cnodder, "Security 2515 Threats and Security Requirements for the Access Node 2516 Control Protocol (ANCP)", 2517 draft-ietf-ancp-security-threats-08 (work in progress), 2518 July 2009. 2520 [I-D.morin-mboned-igmpmld-error-feedback] 2521 Morin, T. and B. Haberman, "IGMP/MLD Error Feedback", 2522 draft-morin-mboned-igmpmld-error-feedback-02 (work in 2523 progress), November 2008. 2525 [IANAAEA] "http://www.iana.org/assignments/address-family-numbers", 2526 2005. 2528 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 2529 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 2530 Protocol Specification (Revised)", RFC 4601, August 2006. 2532 Appendix A. Example of Messages and Message Flows 2534 This section provides example message flows. 2536 A.1. Multicast Conditional Access and CAC without AN bandwidth 2537 delegation 2539 This section describes ANCP operations when multicast flows are 2540 subject to multicast Conditional Access and Admission Control without 2541 bandwidth delegation. 2543 A.1.1. List/Profile Provisioning 2545 The AN provisioning is performed by NAS using a Provisioning message 2546 that contains White/Black/Grey lists and their corresponding 2547 "Multicast Service Profile Name". To indicate to the AN that it need 2548 not perform any CAC operation on those flows, the Provisioning 2549 message also conveys an indication that bandwidth delegation is to be 2550 deactivated. The corresponding message flow is illustrated in 2551 Figure 13. 2553 +----------+ +---------+ +-----+ +-----+ 2554 |Subscriber| | Home | | AN | | NAS | 2555 +----------+ | Gateway | +-----+ +-----+ 2556 | +---------+ | | 2557 | | | | 2558 | | |(M1) Provisioning | 2559 | | | (Mcast S Prof name, | 2560 | | | White List, | 2561 | | | Grey List, | 2562 | | | Black List, | 2563 | | | Bw Del Deactivated) | 2564 | | |<--------------------| 2566 Figure 13: Provisioning AN with White/Grey/Black Lists for 2567 Conditional Access 2569 The Provisioning message M1 contains: 2571 o an ANCP Header with: 2573 * Message-Type = 93 - Provisioning 2575 * Result= 0x00 2577 * Transaction-ID = Transaction-ID maintained by NAS 2579 o a Multicast-Service-Profile TLV containing: 2581 * a Multicast-Service-Profile-Name sub-TLV 2583 * an Empty White-List in our example (and hence no White-List 2584 sub-TLV) 2586 * a Grey-List sub-TLV containing a catch-all entry for IPv4 (in 2587 our example) 2589 * an Empty Black-List in our example (and hence no Black-List 2590 sub-TLV) 2592 The Provisioning message M1 is illustrated below: 2594 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 2595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2596 | Type (0x88-0C) | Length | 2597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2598 | Vers | Sub |MessageType=93 | 0x00 | Code | 2599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2600 | Partition ID | Transaction Identifier = 0008 | 2601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2602 |I| SubMessage Number | Length | 2603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2604 | Mcast-Service-Prof TLV Type | Mcast-Service-Prof TLV Length | 2605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2606 | sub-TLV Type = 0x0001 | sub-TLV Length | 2607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2608 | | 2609 ~ Multicast service profile name ~ 2610 | | 2611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2612 | sub-TLV Type = 0x0003 | sub-TLV Length = 0x06 | 2613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2614 | IP ver = 0x00 | List length = 0x02 | 2615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2616 | Grp PLen=0x00 | Src PLen=0x00 | 2617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2619 Figure 14 2621 A.1.2. Profile Mapping 2623 As soon as the AN port comes up, the AN sends an ANCP PORT_UP message 2624 to the NAS specifying the Access Loop Circuit ID. The NAS replies 2625 with an ANCP PORT_MNGT message that, together with the other 2626 parameters, includes the Multicast Service Profile Name to be 2627 associated to that Port. The corresponding message flow is 2628 illustrated in Figure 15. 2630 +----------+ +---------+ +-----+ +-----+ 2631 |Subscriber| | Home | | AN | | NAS | 2632 +----------+ | Gateway | +-----+ +-----+ 2633 | +---------+ | | 2634 | | | | 2635 | | | | 2636 | | DSL Synch. | | 2637 | |--------------------->| | 2638 | | |(M1)PORT_UP(Port ID) | 2639 | | |-------------------->| 2640 | | | (*) 2641 | | |(M2) PORT_MNGT | 2642 | | | (Port ID, | 2643 | | |Mcast S Profile Name)| 2644 | | |<--------------------| 2646 (*) The NAS may optionally seek direction from an external 2647 Autorization/Policy Server 2649 Figure 15: Associating Profile ID to AN Port 2651 A.1.3. Successful Join/Leave Operations 2653 The message flows in Figure 16 illustrates the ANCP message flow in 2654 case of a simple join and leave for a multicast flow that matches the 2655 grey list and when the "bandwidth delegation" mechanism is not 2656 activated in the AN. In that case the AN queries the NAS that 2657 performs Conditional Access and Admission Control. 2659 +----------+ +-------+ +-----+ ANCP +-----+ 2660 |Subscriber| | Home | | AN |<---------->| NAS | 2661 +----------+ |Gateway| +-----+ +-----+ 2662 | +-------+ | | 2663 | | | | 2664 | Join(Grey-Fl) | Admission | 2665 |-----------+---------->| Control (M1) | 2666 | | |------------------>| 2667 | | | | 2668 | | | Multicast | 2669 | | | Replication (*) 2670 | | | Control (M2) | 2671 | Mcast Grey Flow |<------------------| 2672 |<======================+ | 2673 | | | | 2674 ~ ~ ~ ~ 2675 | | | | 2676 | Leave(Grey-Fl) | Admission | 2677 |-----------+---------->| Control (M3) | 2678 | | |------------------>| 2679 | | | | 2681 Grey-Fl : Multicast Flow matching an entry in Grey List 2682 (bandwidth delegation not activated on AN) 2684 (*) The NAS may optionally seek direction from an external 2685 Autorization/Policy Server 2687 Figure 16: Successful Join/Leave Operations 2689 The Multicast Admission Control message M1 contains: 2691 o an ANCP Header with: 2693 * Message-Type = 92 - Multicast Admission Control 2695 * Result= 0x00 2697 * Transaction-ID = Transaction-ID maintained by AN 2699 o a Target TLV identifying the AN Port 2701 o a Command TLV containing: 2703 * a Command Code = Add 2704 * R = 0 2706 * O = 0 2708 * the multicast flow for which the IGMP Join was received by AN= 2709 (192.0.2.1, 233.252.2.2) 2711 * a Request-Source-IP sub-TLV containing the IGMP join source IP 2712 (192.0.2.100). 2714 The Multicast Admission Control message M1 is illustrated below: 2716 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 2717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2718 | Type (0x88-0C) | Length | 2719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2720 | Vers | Sub |MessageType=92 | 0x00 | Code | 2721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2722 | Partition ID | Transaction Identifier = 0001 | 2723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2724 |I| SubMessage Number | Length | 2725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2726 | Type = 0x1000 (Target) | Target TLV Length | 2727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2728 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 2729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2730 | | 2731 ~ Access Loop Circuit ID ~ 2732 | | 2733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2734 | Type = 0xTBD (Command) TLV | Command-TLV Length | 2735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2736 | Cmd Code=0x01 |0 0 1 | Command Length | 2737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2738 | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | 2739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2740 | AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.2 | 2741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 2742 |Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length | 2743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2744 | AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 | 2745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 2747 The Multicast Replication Control message M2 contains: 2749 o an ANCP Header with: 2751 * Message-Type = 90 - Multicast Replication Control 2753 * Result= 0x00 2755 * Transaction-ID = Transaction-ID maintained by NAS 2757 o a Target TLV identifying the AN Port 2759 o a Command TLV containing: 2761 * a Command Code = Add 2763 * R= 1 (since in our example the flow resources have been 2764 admitted by NAS) 2766 * O = 0 (since in our example flow accounting is not required) 2768 * the multicast flow for which the IGMP Join was received by AN= 2769 (192.0.2.1, 233.252.2.2) 2771 * a Request-Source-IP sub-TLV containing the IGMP join source IP 2772 (192.0.2.100). 2774 The Multicast Admission Control message M2 is illustrated below: 2776 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 2777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2778 | Type (0x88-0C) | Length | 2779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2780 | Vers | Sub |MessageType=90 | 0x00 | Code | 2781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2782 | Partition ID | Transaction Identifier = 0009 | 2783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2784 |I| SubMessage Number | Length | 2785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2786 | Type = 0x1000 (Target) | Target TLV Length | 2787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2788 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 2789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2790 | | 2791 ~ Access Loop Circuit ID ~ 2792 | | 2793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2794 | Type = 0xTBD (Command) TLV | Command-TLV Length | 2795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2796 | Cmd Code=0x01 |1 0 1 | Command Length | 2797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2798 | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | 2799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2800 | AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.2 | 2801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 2802 |Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length | 2803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2804 | AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 | 2805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 2807 The Multicast Admission Control message M3 contains: 2809 o an ANCP Header with: 2811 * Message-Type = 92 - Multicast Admission Control 2813 * Result= 0x00 2815 * Transaction-ID = Transaction-ID maintained by AN 2817 o a Target TLV identifying the AN Port 2819 o a Command TLV containing: 2821 * a Command Code = Delete 2823 * R = 0 2825 * O = 0 2827 * the multicast flow for which the IGMP leave was received by AN= 2828 (192.0.2.1, 233.252.2.2) 2830 * a Request-Source-IP sub-TLV containing the IGMP join source IP 2831 (192.0.2.100). 2833 The Multicast Admission Control message M3 is illustrated below: 2835 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 2836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2837 | Type (0x88-0C) | Length | 2838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2839 | Vers | Sub |MessageType=92 | 0x00 | Code | 2840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2841 | Partition ID | Transaction Identifier = 0002 | 2842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2843 |I| SubMessage Number | Length | 2844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2845 | Type = 0x1000 (Target) | Target TLV Length | 2846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2847 | Access-Loop-Circuit-ID 0x0002 | Circuit-ID Length | 2848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2849 | | 2850 ~ Access Loop Circuit ID ~ 2851 | | 2852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2853 | Type = 0xTBD (Command) TLV | Command-TLV Length | 2854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2855 | Cmd Code=0x02 |0 0 1 | Command Length | 2856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2857 | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | 2858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2859 | AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.2 | 2860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 2861 |Type = 0xTBD (Request-S.) TLV | Request-S.-TLV Length | 2862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2863 |Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length | 2864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2865 | AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 | 2866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 2868 A.1.4. Admission Control Reject without NAS Response 2870 The message flow in Figure 17 illustrates the ANCP message flow in 2871 case of a join that is rejected by the NAS because of admission 2872 control and without explicit response from the NAS. In that case, 2873 the multicast flow is never replicated simply by virtue of the NAS 2874 not requesting replication. 2876 +----------+ +-------+ +-----+ ANCP +-----+ 2877 |Subscriber| | Home | | AN |<---------->| NAS | 2878 +----------+ |Gateway| +-----+ +-----+ 2879 | +-------+ | | 2880 | | | | 2881 | Join(Grey-Fl) | Admission | 2882 |-----------+---------->| Control (M1) | 2883 | | |------------------>| 2884 | | | | 2885 | | | (*) 2886 | | | | 2887 | Mcast Grey Flow | | 2888 | not replicated x | 2889 | | | | 2891 Grey-Fl : Multicast Flow matching an entry in Grey List 2892 (bandwidth delegation not activated on AN) 2894 (*) The NAS may optionally seek direction from an external 2895 Autorization/Policy Server 2897 Figure 17: Admission Control Reject without NAS Response 2899 The Multicast Admission Control message M1 contains: 2901 o an ANCP Header with: 2903 * Message-Type = 92 - Multicast Admission Control 2905 * Result= 0x00 2907 * Transaction-ID = Transaction-ID maintained by AN 2909 o a Target TLV identifying the AN Port 2911 o a Command TLV containing: 2913 * a Command Code = Add 2915 * R = 0 2917 * O = 0 2919 * the multicast flow for which the IGMP join was received by AN= 2920 (192.0.2.1, 233.252.2.3). 2922 * a Request-Source-IP sub-TLV containing the IGMP join source IP 2923 (192.0.2.100). 2925 The Multicast Admission Control message M1 is illustrated below: 2927 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 2928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2929 | Type (0x88-0C) | Length | 2930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2931 | Vers | Sub |MessageType=92 | 0x00 | Code | 2932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2933 | Partition ID | Transaction Identifier = 0003 | 2934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2935 |I| SubMessage Number | Length | 2936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2937 | Type = 0x1000 (Target) | Target TLV Length | 2938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2939 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 2940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2941 | | 2942 ~ Access Loop Circuit ID ~ 2943 | | 2944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2945 | Type = 0xTBD (Command) TLV | Command-TLV Length | 2946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2947 | Cmd Code=0x01 |0 0 1 | Command Length | 2948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2949 | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | 2950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2951 | AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.3 | 2952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 2953 |Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length | 2954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2955 | AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 | 2956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 2958 A.1.5. Admission Control Reject with NAS Response 2960 The message flow in Figure 18 illustrates the ANCP message flow in 2961 case of a join that is rejected by the NAS because of admission 2962 control and with explicit response from the NAS. In that case, the 2963 multicast flow is not replicated by virtue of the NAS explicitely 2964 signaling to the AN that the multicast flow is not to be replicated. 2966 +----------+ +-------+ +-----+ ANCP +-----+ 2967 |Subscriber| | Home | | AN |<---------->| NAS | 2968 +----------+ |Gateway| +-----+ +-----+ 2969 | +-------+ | | 2970 | | | | 2971 | Join(Grey-Fl) | Admission | 2972 |-----------+---------->| Control (M1) | 2973 | | |------------------>| 2974 | | | | 2975 | | | Multicast (*) 2976 | | | Replication | 2977 | | | Control (M2) | 2978 | Mcast Grey Flow |<------------------| 2979 | not replicated x | 2980 | | | | 2982 Grey-Fl : Multicast Flow matching an entry in Grey List 2983 (bandwidth delegation not activated on AN) 2985 (*) The NAS may optionally seek direction from an external 2986 Autorization/Policy Server 2988 Figure 18: Admission Control Reject with NAS Response 2990 The Multicast Admission Control message M1 contains: 2992 o an ANCP Header with: 2994 * Message-Type = 92 - Multicast Admission Control 2996 * Result= 0x00 2998 * Transaction-ID = Transaction-ID maintained by AN 3000 o a Target TLV identifying the AN Port 3002 o a Command TLV containing: 3004 * a Command Code = Add 3006 * R = 0 3008 * O = 0 3010 * the multicast flow for which the IGMP join was received by AN= 3011 (192.0.2.1, 233.252.2.4). 3013 * a Request-Source-IP sub-TLV containing the IGMP join source IP 3014 (192.0.2.100). 3016 The Multicast Admission Control message M1 is illustrated below: 3018 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 3019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3020 | Type (0x88-0C) | Length | 3021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3022 | Vers | Sub |MessageType=92 | 0x00 | Code | 3023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3024 | Partition ID | Transaction Identifier = 0004 | 3025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3026 |I| SubMessage Number | Length | 3027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3028 | Type = 0x1000 (Target) | Target TLV Length | 3029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3030 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 3031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3032 | | 3033 ~ Access Loop Circuit ID ~ 3034 | | 3035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3036 | Type = 0xTBD (Command) TLV | Command-TLV Length | 3037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3038 | Cmd Code=0x01 |0 0 1 | Command Length | 3039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3040 | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | 3041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3042 | AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.4 | 3043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 3044 |Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length | 3045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3046 | AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 | 3047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 3049 The Multicast Replication Control message M2 contains: 3051 o an ANCP Header with: 3053 * Message-Type = 90 - Multicast Replication Control 3055 * Result= 0x00 3057 * Transaction-ID = Transaction-ID maintained by NAS 3059 o a Target TLV identifying the AN Port 3061 o a Command TLV containing: 3063 * a Command Code = Admission Control Reject (since in our example 3064 the flow is rejected by NAS because of bandwidth admission 3065 control and not because of conditional access) 3067 * R= 0 (since in our example the flow resources have not been 3068 admitted by NAS) 3070 * O = 0 (since in our example flow accounting is not required) 3072 * the multicast flow (192.0.2.1, 233.252.2.4) 3074 * a Request-Source-IP sub-TLV containing the IGMP join source IP 3075 (192.0.2.100). 3077 The Multicast Admission Control message M2 is illustrated below: 3079 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 3080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3081 | Type (0x88-0C) | Length | 3082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3083 | Vers | Sub |MessageType=90 | 0x00 | Code | 3084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3085 | Partition ID | Transaction Identifier = 0010 | 3086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3087 |I| SubMessage Number | Length | 3088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3089 | Type = 0x1000 (Target) | Target TLV Length | 3090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3091 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 3092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3093 | | 3094 ~ Access Loop Circuit ID ~ 3095 | | 3096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3097 | Type = 0xTBD (Command) TLV | Command-TLV Length | 3098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3099 | Cmd Code=0xTBD|0 0 1 | Command Length | 3100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3101 | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | 3102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3103 | AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.4 | 3104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 3105 |Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length | 3106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3107 | AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 | 3108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 3110 A.2. Example Flows For bandwidth delegation 3112 As noted in TBD, the operation of bandwidth delegation is 3113 supplemental to the operation of request processing in the absence of 3114 bandwidth delegation. Thus the same flows shown in the previous 3115 section continue to hold, except that the AN does multicast call 3116 admission before doing grey and white list processing. The example 3117 flows of this section are therefore limited to the incremental 3118 operations of bandwidth delegation. They include initial 3119 provisioning, a successful request from the AN for an increase in 3120 total multicast bandwidth, an autonomous transfer of the borrowed 3121 bandwidth back to the NAS, and the initiation of the bandwidth reset 3122 procedure [text to be modified] by the NAS when it finds that the 3123 amount of total multicast bandwidth passed by the AN is larger than 3124 its current view of that amount. 3126 A.2.1. Activation and Provisioning of total multicast Bandwidth 3128 Activation of bandwidth delegation occurs at the level of the AN as a 3129 whole and is done by including a Bandwidth-Delegation-Control TLV in 3130 the Provisioning message with the E-flag set to 1. The message flow 3131 is as shown in Figure 13. In place of Figure 14 we have the 3132 following content within the Provisioning message: 3134 1 2 3 3135 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 3136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3137 | Type (0x88-0C) | Length | 3138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3139 | Vers | Sub |MessageType=93 | 0x00 | Code | 3140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3141 | Partition ID | Transaction Identifier = 0008 | 3142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3143 |I| SubMessage Number | Length | 3144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3145 | Mcast-Service-Prof TLV Type | Mcast-Service-Prof TLV Length | 3146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3147 | sub-TLV Type = 0x0001 | sub-TLV Length | 3148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3149 | | 3150 ~ Multicast service profile name ~ 3151 | | 3152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3153 | sub-TLV Type = 0x0003 | sub-TLV Length = 0x06 | 3154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3155 | IP ver = 0x00 | List length = 0x02 | 3156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3157 | Grp PLen=0x00 | Src PLen=0x00 | Padding = 0x00 | 3158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3159 | TLV Type = Band-Del-Control | TLV Length = 0x04 | 3160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3161 |E| Reserved = 0x00 | Reserved = 0x00 | 3162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3164 Figure 19 3166 Once bandwidth delegation has been activated, the NAS must provision 3167 the amount of total multicast bandwidth for each access line (unless 3168 it is pre-configured on the AN). This requires a Port Management 3169 message with a Bandwidth-Allocation TLV. The same Port Management 3170 message may be used to provision other information, such as the 3171 multicast service profile name applicable to the access line. The 3172 information flow is therefore similar to that in Figure 15. In the 3173 following figure, an initial allocation of 8000 kbits/s is provided. 3175 0 1 2 3 3176 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 3177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3178 | Vers | Sub | Msg Type = 32 |Rslt =1| Code = 0 | 3179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3180 | Partition ID | Transaction Identifier | 3181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3182 |I| SubMessage Number | Length | 3183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3184 | Port = 0 | 3185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3186 | Port Session Number | 3187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3188 | Event Sequence Number | 3189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3190 |R|x|x|x|x|x|x|x| Duration | Func = 8 | X-Func = 0 | 3191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3192 | Event Flags | Flow Control Flags | 3193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3194 |x|x|x|x|x|x|x|x| Msg Type = 32 | Tech Type = 5 | Block Len = 0 | 3195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3196 | # of TLVs = 2 | Ext Block length | 3197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3198 | TLV Type = 0x01 | Access-Loop-Cct-ID length | 3199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3200 | | 3201 ~ Access-Loop-Circuit-ID ~ 3202 | | 3203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3204 | TLV Type = Bandwidth-Alloc | TLV length = 4 | 3205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3206 | Delegated amount = 8000 | 3207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3209 Figure 20: Port Management Message Allocating total multicast 3210 Bandwidth 3212 A.2.2. Successful Request For More Multicast Bandwidth 3214 Suppose that the AN allocates all 8000 kbits/s of its total multicast 3215 amount and receives a Join request requiring another 2000 kbits/s. 3216 The AN issues a Bandwidth Reallocation Request message where the 3217 required amount field is set to acquire this amount of additional 3218 bandwidth. Since the request is framed in terms of total total 3219 multicast bandwidth, required amount is 10000 kbits/s. Suppose that 3220 the AN is configured with a policy that causes it to request enough 3221 for one additional channel as a preferred amount. Hence the 3222 preferred amount is set to 12000 kbits/s. The Bandwidth Reallocation 3223 Request message has the following format: 3225 0 1 2 3 3226 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 3227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3228 | Vers | Sub | MsgTyp = 94 |Rslt=0 | Code = 0 | 3229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3230 | Partition ID | Transaction Identifier | 3231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3232 |I| SubMessage Number | Length | 3233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3234 | TLV Type = Target | Target-TLV Length | 3235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3236 | Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length | 3237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3238 | | 3239 ~ Access Loop Circuit ID ~ 3240 | | 3241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3242 |TLV Type = Bandwidth-Request | TLV Length = 8 | 3243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3244 | Required amount = 10000 | 3245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3246 | Preferred amount = 12000 | 3247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3249 Figure 21: Example Bandwidth Reallocation Request Message 3251 In response to this request, the NAS is willing to grant the full 3252 preferred amount. (It could have granted any value between 10000 and 3253 12000, or it could have rejected the request.) The Bandwidth 3254 Transfer message sent as a response indicates that the new total 3255 multicast bandwidth amount is 12000 kbits/s, as shown in the next 3256 figure. 3258 0 1 2 3 3259 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 3260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3261 | Vers | Sub | MsgTyp = 95 |Rslt=3 | Code = 0 | 3262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3263 | Partition ID | Transaction Identifier | 3264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3265 |I| SubMessage Number | Length | 3266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3267 | TLV Type = Target | Target-TLV Length | 3268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3269 | Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length | 3270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3271 | | 3272 ~ Access Loop Circuit ID ~ 3273 | | 3274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3275 |TLV Type = Bandwidth-Alloc | TLV Length = 4 | 3276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3277 | Delegated amount = 12000 | 3278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3280 Figure 22: Example Bandwidth Transfer Message (Success Response) 3282 A.2.3. Failed Autonomous Transfer With Reset 3284 Suppose the AN decides after an interval that it should return 2000 3285 kbits/s of the 4000 kbits/s that it acquired from the NAS in the 3286 previous transaction. It therefore issues a Bandwidth Transfer 3287 message of its own. This message differs from the message in 3288 Figure 22 in two ways. First, because this is an autonomous transfer 3289 rather than a response, the Result field in the header is set to 3290 Ignore (0x0). Secondly, the Delegated amount is reduced to 10000 3291 kbits/s. 3293 Now suppose that somehow the NAS forgot that it passed an additional 3294 4000 kbits/s to the AN. Thus its current view of the amount of total 3295 multicast bandwidth is 8000 kbits/s. The 10000 kbits/s appearing in 3296 the Bandwidth Transfer message is higher than this, so there is 3297 clearly a disgareement between the NAS and the AN. The NAS chooses 3298 to initiate the reset procedure, perhaps because it is close to 3299 committing all of its available video bandwidth for unicast service. 3300 As the initial step in this procedure, it issues a Multicast Status 3301 message indicating that a reset of the total multicast amount is 3302 required. This is shown in the following figure. 3304 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 3305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3306 | Type (0x88-0C) | Length | 3307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3308 | Vers | Sub |MessageType=91 | 0x4 | Code = 0 | 3309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3310 | Partition ID | Transaction Identifier | 3311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3312 |I| SubMessage Number | Length | 3313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3314 | Status-info-TLV=TBD | Status-TLV-Length | 3315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3316 |Rslt Code = xx | Cmd No = 1 | Error Message Length | 3317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3318 | Error Message (padded to 4) if Length > 0 | 3319 +---------------------------------------------------------------+ 3320 | TLV Type = Target | Target-TLV Length | 3321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3322 | Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length | 3323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3324 | | 3325 ~ Access Loop Circuit ID ~ 3326 | | 3327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3328 |TLV Type = Bandwidth-Alloc | TLV Length = 4 | 3329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3330 | Delegated amount = 8000 | 3331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3333 The Result Code field within the Status-Info TLV contains the value: 3334 total multicast bandwidth reset required (0xTBD). 3336 Figure 23: Example Initiation of Multicast Bandwidth Reset 3338 The NAS stops processing video service requests for the given access 3339 line when it sends this message. Similarly, the AN stops processing 3340 multicast video service requests when it receives the message. [To 3341 think about: can service requests that release bandwidth be safely 3342 processed? Probably.] The next step is up to the NAS: it sends a 3343 bandwidth delegation Query Request message to the AN. The Result 3344 field in the header is set to Ignore (0x0) as usual for multicast- 3345 related messages. The Target TLV is a copy of the one received in 3346 the original Bandwidth Transfer message. The message is shown in the 3347 following figure: 3349 0 1 2 3 3350 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 3351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3352 | Vers | Sub | MsgTyp = 96 |Rslt=0 | Code = 0 | 3353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3354 | Partition ID | Transaction Identifier | 3355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3356 |I| SubMessage Number | Length | 3357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3358 | TLV Type = Target | Target-TLV Length | 3359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3360 | Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length | 3361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3362 | | 3363 ~ Access Loop Circuit ID ~ 3364 | | 3365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3367 Figure 24: Example Delegated Bandwidth Query Request Message 3369 The AN returns a Delegated Bandwidth Query Response message showing 3370 that it believes that the amount of total multicast bandwidth is 3371 10000 kbits/s and it has committed 8000 kbits/s of it. The Result 3372 field in the header shows Success (0x3) to distinguish the response. 3373 [... in case we decide to make the query bidirectional ...] 3374 0 1 2 3 3375 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 3376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3377 | Vers | Sub | MsgTyp = 96 |Rslt=3 | Code = 0 | 3378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3379 | Partition ID | Transaction Identifier | 3380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3381 |I| SubMessage Number | Length | 3382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3383 | TLV Type = Target | Target-TLV Length | 3384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3385 | Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length | 3386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3387 | | 3388 ~ Access Loop Circuit ID ~ 3389 | | 3390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3391 |TLV Type = Bandwidth-Request | TLV Length = 8 | 3392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3393 | Delegated amount = 10000 | 3394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3395 | Committed amount = 8000 | 3396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3398 Figure 25: Example Delegated Bandwidth Query Response Message 3400 The NAS decides to reset the total multicast bandwidth amount to 8000 3401 kbits/s. It issues a Port Management message looking exactly like 3402 the one in Figure 20. Once it sends this message, it resumes 3403 processing service requests for the access line concerned. 3404 Similarly, the AN resumes request processing after it receives the 3405 Port Management message and resets its view of the current total 3406 multicast bandwidth. In the short run, this means that it will have 3407 to ask for more bandwidth if it receives another Join request. [It 3408 seems reasonable that the AN would not do so for a period of time 3409 after a reset or a response to a Bandwidth Reallocation Request that 3410 grants less than the preferred amount. Should we establish a timer?] 3412 A.3. Example Flows For Multicast Flow Reporting 3414 A.3.1. Per Port Multicast Flow Reporting 3416 Figure 26 illustrate a message flow in the case where the NAS queries 3417 the AN about which multicast flow is active on port 10, on port 20 3418 and on port 11 of the AN. 3420 +----------+ +-------+ +-----+ ANCP +-----+ 3421 |Subscriber| | Home | | AN |<---------->| NAS | 3422 +----------+ |Gateway| +-----+ +-----+ 3423 | +-------+ | | 3424 | | | Multicast Flow | 3425 | | | Query Request | 3426 | | | (M1) | 3427 | | |<------------------| 3428 | | | | 3429 | | | Multicast Flow | 3430 | | | Query Response | 3431 | | | (M2) | 3432 | | |------------------>| 3433 | | | | 3434 | | | | 3436 Figure 26: Per Port Multicast Flow Reporting 3438 The Multicast Flow Query Request message (M1) is illustrated in 3439 Figure 27. 3441 0 1 2 3 3442 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 3443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3444 | Vers | Sub | Msg Type = 97 |Rslt=00| Code = 0 | 3445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3446 | Partition ID | Transaction Identifier | 3447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3448 |I| SubMessage Number | Length | 3449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3450 | Type = 0x1000 (Target) | Target TLV Length | 3451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3452 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 3453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3454 | | 3455 ~ Access Loop Circuit ID (port10) ~ 3456 | | 3457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3458 | Type = 0x1000 (Target) | Target TLV Length | 3459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3460 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 3461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3462 | | 3463 ~ Access Loop Circuit ID (port20) ~ 3464 | | 3465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3466 | Type = 0x1000 (Target) | Target TLV Length | 3467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3468 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 3469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3470 | | 3471 ~ Access Loop Circuit ID (port11) ~ 3472 | | 3473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3475 Figure 27: Multicast Flow Query Request message for per-port Mulicast 3476 Flow Reporting 3478 The Multicast Flow Query Response message (M2) is illustrated in 3479 Figure 28. It indicates that there is one active multicast flow 3480 [(192.0.2.1, 233.252.2.4)] on port 10, no active multicast flow on 3481 port 20 and two active multicast flows [(192.0.2.1, 233.252.2.4) and 3482 (192.0.2.2, 233.252.2.10)] on port 11. 3484 0 1 2 3 3485 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 3486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3487 | Vers | Sub | Msg Type = 97 |Rslt=00| Code = 0 | 3488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3489 | Partition ID | Transaction Identifier | 3490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3491 |I| SubMessage Number | Length | 3492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3493 | Type = 0x1000 (Target) | Target TLV Length | 3494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3495 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 3496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3497 | | 3498 ~ Access Loop Circuit ID (port10) ~ 3499 | | 3500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3501 |Type=0x19 (Multicast-Flow) TLV | Multicast Flow-TLV Length | 3502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3503 | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | 3504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3505 | AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.4 | 3506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 3507 | Type = 0x1000 (Target) | Target TLV Length | 3508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3509 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 3510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3511 | | 3512 ~ Access Loop Circuit ID (port20) ~ 3513 | | 3514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3515 | Type = 0x1000 (Target) | Target TLV Length | 3516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3517 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 3518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3519 | | 3520 ~ Access Loop Circuit ID (port11) ~ 3521 | | 3522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3523 |Type=0x19 (Multicast-Flow) TLV | Multicast Flow-TLV Length | 3524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3525 | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | 3526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3527 | AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.4 | 3528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 3529 |Type=0x19 (Multicast-Flow) TLV | Multicast Flow-TLV Length | 3530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3531 | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.2 | 3532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3533 | AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.10 | 3534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 3535 Figure 28: Multicast Flow Query Response message for per-port 3536 Mulicast Flow Reporting 3538 Authors' Addresses 3540 Francois Le Faucheur 3541 Cisco Systems 3542 Greenside, 400 Avenue de Roumanille 3543 Sophia Antipolis 06410 3544 France 3546 Phone: +33 4 97 23 26 19 3547 Email: flefauch@cisco.com 3549 Roberta Maglione 3550 Telecom Italia 3551 Via Reiss Romoli 274 3552 Torino 10148 3553 Italy 3555 Phone: 3556 Email: roberta.maglione@telecomitalia.it 3558 Tom Taylor 3559 Huawei Technologies 3560 1852 Lorraine Ave 3561 Ottawa, Ontario K1H 6Z8 3562 Canada 3564 Phone: +1 613 680 2675 3565 Email: tom111.taylor@bell.net