idnits 2.17.1 draft-ietf-ancp-mc-extensions-00.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 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 2155 has weird spacing: '...licated x ...' == Line 2246 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 (July 3, 2009) is 5405 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-10 ** 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-05 == Outdated reference: A later version (-08) exists of draft-ietf-ancp-security-threats-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: January 4, 2010 Telecom Italia 6 T. Taylor 7 Huawei 8 July 3, 2009 10 Additional Multicast Control Extensions for ANCP 11 draft-ietf-ancp-mc-extensions-00.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 January 4, 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. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3. Multicast Use Cases . . . . . . . . . . . . . . . . . . . . . 7 68 3.1. NAS Initiated Multicast Replication Control Use Case . . . 7 69 3.1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 7 70 3.1.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 8 71 3.2. Conditional Access and Admission Control Use Case . . . . 8 72 3.2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 8 73 3.2.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 9 74 3.3. Multicast Flow Reporting Use Case . . . . . . . . . . . . 9 75 3.3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 9 76 3.3.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 10 77 4. ANCP Messages . . . . . . . . . . . . . . . . . . . . . . . . 11 78 4.1. Provisioning Message . . . . . . . . . . . . . . . . . . . 11 79 4.2. Port Management Message . . . . . . . . . . . . . . . . . 11 80 4.3. Multicast Replication Control Message . . . . . . . . . . 12 81 4.4. Multicast Status Message . . . . . . . . . . . . . . . . . 17 82 4.5. Multicast Admission Control Message . . . . . . . . . . . 20 83 4.6. Bandwidth Reallocation Request Message . . . . . . . . . . 23 84 4.7. Bandwidth Transfer Message . . . . . . . . . . . . . . . . 25 85 4.8. Delegated Bandwidth Query Request and Response Messages . 26 86 4.9. Multicast Flow Query Request and Response Messages . . . . 28 87 4.10. Delegated Bandwidth Reset Procedure . . . . . . . . . . . 30 88 5. ANCP TLVs and Sub-TLVs . . . . . . . . . . . . . . . . . . . . 32 89 5.1. Multicast-Service-Profile TLV . . . . . . . . . . . . . . 32 90 5.1.1. Profile Processing At the Access Node . . . . . . . . 34 91 5.2. Bandwidth-Delegation-Control TLV . . . . . . . . . . . . . 36 92 5.3. Bandwidth-Allocation TLV . . . . . . . . . . . . . . . . . 37 93 5.4. Bandwidth-Request TLV . . . . . . . . . . . . . . . . . . 38 94 5.5. Bandwidth-Status TLV . . . . . . . . . . . . . . . . . . . 38 95 5.6. Multicast-Service-Profile-Name TLV . . . . . . . . . . . . 39 96 5.7. Request-Source-IP sub-TLV . . . . . . . . . . . . . . . . 39 97 5.8. Request-Source-MAC sub-TLV . . . . . . . . . . . . . . . . 40 98 5.9. Multicast-Flow TLV . . . . . . . . . . . . . . . . . . . . 41 99 6. New Capabilities . . . . . . . . . . . . . . . . . . . . . . . 43 100 7. Example of Messages and Message Flows . . . . . . . . . . . . 45 101 7.1. Multicast Conditional Access and CAC without AN 102 Bandwidth Delegation . . . . . . . . . . . . . . . . . . . 45 103 7.1.1. List/Profile Provisioning . . . . . . . . . . . . . . 45 104 7.1.2. Profile Mapping . . . . . . . . . . . . . . . . . . . 47 105 7.1.3. Successful Join/Leave Operations . . . . . . . . . . . 47 106 7.1.4. Admission Control Reject without NAS Response . . . . 53 107 7.1.5. Admission Control Reject with NAS Response . . . . . . 55 108 7.2. Example Flows For Bandwidth Delegation . . . . . . . . . . 59 109 7.2.1. Activation and Provisioning of Delegated Bandwidth . . 60 110 7.2.2. Successful Request For More Delegated Bandwidth . . . 61 111 7.2.3. Failed Autonomous Transfer With Reset . . . . . . . . 63 112 7.3. Example Flows For Multicast Flow Reporting . . . . . . . . 66 113 7.3.1. Per Port Multicast Flow Reporting . . . . . . . . . . 66 114 8. Security Considerations . . . . . . . . . . . . . . . . . . . 71 115 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 116 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 76 117 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 77 118 11.1. Normative References . . . . . . . . . . . . . . . . . . . 77 119 11.2. Informative References . . . . . . . . . . . . . . . . . . 77 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 79 122 1. Introduction 124 [I-D.ietf-ancp-framework] defines a framework and requirements for an 125 Access Node control mechanism between a Network Access Server (NAS) 126 and an Access Node (e.g. a Digital Subscriber Line Access Multiplexer 127 (DSLAM)) in a multi-service reference architecture in order to 128 perform QoS-related, service-related and subscriber-related 129 operations. [I-D.ietf-ancp-protocol] specifies a protocol for Access 130 Node Control in broadband networks in line with this framework. 132 The Access Node Control Protocol (ANCP) specified in 133 [I-D.ietf-ancp-protocol] supports a number of use cases defined in 134 [I-D.ietf-ancp-framework] such as the Access Topology Discovery use 135 case, the Access Loop Configuration use case and the Remote 136 Connectivity Test use case. However, it does not support the 137 multicast use cases defined in [I-D.ietf-ancp-framework]. The 138 present document specifies the extensions to the Access Node Control 139 Protocol required for support of these multicast use cases. 141 2. Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 The expression "delegated bandwidth" is used as a shorter way of 148 saying: "the total amount of video bandwidth delegated to the AN for 149 multicast admission control". 151 3. Multicast Use Cases 153 Quoting from [I-D.ietf-ancp-framework]: 155 "... the Access Node, aggregation node(s) and the NAS must all be 156 involved in the multicast replication process. This avoids that 157 several copies of the same stream are sent within the access/ 158 aggregation network. In case of an Ethernet-based access/aggregation 159 network, this may, for example, be achieved by means of IGMP snooping 160 or IGMP proxy in the Access Node and aggregation node(s). By 161 introducing IGMP processing in the access/aggregation nodes, the 162 multicast replication process is now divided between the NAS, the 163 aggregation node(s) and Access Nodes. In order to ensure backward 164 compatibility with the ATM-based model, the NAS, aggregation node and 165 Access Node need to behave as a single logical device. This logical 166 device must have exactly the same functionality as the NAS in the ATM 167 access/aggregation network. The Access Node Control Mechanism can be 168 used to make sure that this logical/functional equivalence is 169 achieved by exchanging the necessary information between the Access 170 Node and the NAS. " 172 [I-D.ietf-ancp-framework] describes the use cases for ANCP associated 173 with such multicast operations, and identifies the associated ANCP 174 requirements. The present section describes a subset of these use 175 cases as background to facilitate reading of this document, but the 176 reader is refered to [I-D.ietf-ancp-framework] for a more exhaustive 177 description of the ANCP multicast use cases. Detailed example 178 message flows can also be found in Section 7. 180 3.1. NAS Initiated Multicast Replication Control Use Case 182 3.1.1. Goals 184 One option for multicast handling is for the subscriber to 185 communicate the "join/leave" information to the NAS. This can be 186 done for instance by terminating all subscriber IGMP ([RFC3376]) or 187 MLD ([RFC2710], [RFC3810]) signaling on the NAS. Another example 188 could be a subscriber using some form of application level signaling, 189 which is redirected to the NAS. In any case, this option is 190 transparent to the access and aggregation network. In this scenario, 191 the NAS uses ANCP to create and remove replication state in the AN 192 for efficient multicast replication. Thus, the NAS only sends a 193 single copy of the multicast stream towards the AN, which in turn 194 performs replication to multiple subscribers as instructed by the NAS 195 via ANCP. The NAS first performs conditional access and multicast 196 admission control when processing multicast join requests, and only 197 creates replication state in the AN if admission succeeds. 199 3.1.2. Message Flow 201 With the NAS-initiated use case, a Multicast Replication Control 202 Message is sent by the NAS to the AN with a directive to either join 203 or leave one (or more) multicast flow(s). The AN uses a Multicast 204 Status Message to convey the outcome of the directive. Figure 1 205 illustrates such an ANCP message exchange as well as the associated 206 AN behavior. 208 +----------+ +-------+ +-----+ ANCP +-----+ 209 |Subscriber| | Home | | AN |<-------------------->| NAS | 210 +----------+ |Gateway| +-----+ +-----+ 211 | +-------+ | | 212 | | | Multicast-Replication-Crl | 213 | | | (Target,add, Flow 1) | 214 | | |<--------------------------| 215 | Mcast Flow 1 | | 216 |<==========================+ | 217 | | | Multicast-Status | 218 | | |-------------------------->| 219 | | | | 220 | | | | 221 ~ ~ ~ ~ 222 | | | | 223 | | | Multicast-Replication-Crl | 224 | | | (Target,delete, Flow 1) | 225 | | |<--------------------------| 226 | | | | 227 | | Multicast-Status | 229 | | |-------------------------->| 231 Figure 1: NAS Initiated Multicast Replication Control 233 3.2. Conditional Access and Admission Control Use Case 235 3.2.1. Goals 237 One option for multicast handling is for the access/aggregation nodes 238 to participate in IGMP/MLD processing (e.g. via IGMP/MLD snooping). 239 In this scenario, on detecting a join/leave request from an enduser 240 for a multicast flow, the AN uses ANCP to request conditional access 241 and admission control decision from the NAS. In turn, after 242 conditional access and admission control checks, the NAS uses ANCP to 243 instruct the AN to change the replication states accordingly. 245 3.2.2. Message Flow 247 For support of the conditional access and admission control use case, 248 on detection of an IGMP/MLD Join, the AN sends an Admission Control 249 message to the NAS to request conditional access and admission 250 control check. In case of positive outcome, the NAS sends a 251 Multicast Replication Control Message to the AN with a directive to 252 replicate the multicast flow to the corresponding user. Similarly on 253 detection of an IGMP/MLD leave, an Admission Control message is sent 254 by the AN to the NAS to keep the NAS aware of user departure for the 255 flow. This message flow is illustrated in Figure 2. 257 +----------+ +-------+ +-----+ ANCP +-----+ 258 |Subscriber| | Home | | AN |<------------------->| NAS | 259 +----------+ |Gateway| +-----+ +-----+ 260 | +-------+ | | 261 | | | | 262 | Join(Flow 1) | Admission-Control | 263 |------------+---------->| (Target,add, Flow 1) | 264 | | |-------------------------->| 265 | | | (*) 266 | | | Multicast-Replication-Crl | 267 | | | (Target,add, Flow 1) | 268 | | |<--------------------------| 269 | Mcast Flow 1 | | 270 |<=======================+ | 271 | | | | 272 ~ ~ ~ ~ 273 | | | | 274 | Leave(Flow 1) | Admission-Control | 275 |------------+---------->| (Target,delete, Flow 1) | 276 | | |-------------------------->| 277 | | | 279 | | | | 281 (*) The NAS may optionally seek direction from an external 282 Authorization/Policy Server 284 Figure 2: Multicast Conditional Access and Admission Control 286 3.3. Multicast Flow Reporting Use Case 288 3.3.1. Goals 290 The Multicast flow reporting use case allows the NAS to 291 asynchronously query the AN to obtain an instantaneous status report 292 related to multicast flows currently replicated by the AN. 294 3.3.2. Message Flow 296 The NAS sends a Multicast Flow Query Request message to the AN in 297 order to query the AN about information such as which multicast flows 298 are currently active on a given AN port or which ports are currently 299 replicating a given multicast flow. The AN conveys the requested 300 information to the NAS in a Multicast Flow Query Response message. 301 This message flow is illustrated in Figure 3. 303 +----------+ +-------+ +-----+ ANCP +-----+ 304 |Subscriber| | Home | | AN |<---------->| NAS | 305 +----------+ |Gateway| +-----+ +-----+ 306 | +-------+ | | 307 | | | Multicast Flow | 308 | | | Query Request | 309 | | |<------------------| 310 | | | | 311 | | | Multicast Flow | 312 | | | Query Response | 313 | | |------------------>| 314 | | | | 315 | | | | 317 Figure 3: Multicast Flow Reporting 319 4. ANCP Messages 321 This section defines new ANCP messages and new usage of existing ANCP 322 messages as well as procedures associated with the use of these 323 messages. 325 4.1. Provisioning Message 327 [I-D.ietf-ancp-protocol] defines the Provisioning message that is 328 sent by the NAS to the AN to provision information in the AN. 330 The present document specifies that the Provisioning message MAY be 331 used by the NAS to provision multicast-related information (e.g. 332 Multicast Service Profiles, Bandwidth Delegation activation/ 333 deactivation). 335 The ANCP Provisioning message payload MAY contain the following TLVs: 337 o Multicast-Service-Profile TLV: the Multicast-Service-Profile TLV 338 is defined in the present document in Section 5.1. It MAY appear 339 zero, one or multiple times. Each instance of the Multicast- 340 Service-Profile TLV contains a (possibly empty) White List, a 341 (possibly empty) Grey List, a (possibly empty) Black List and the 342 Multicast Service Profile name associated with this set of three 343 lists. 345 o Bandwidth-Delegation-Control TLV: The Bandwidth-Delegation-Control 346 TLV is defined in the present document in Section 5.2. It MAY 347 appear zero times or once. When present it instructs the AN on 348 whether Bandwidth Delegation is to be activated or deactivated. 350 [Editor's Note: A generic mechanism should be defined in ancp-proto 351 to deal with incorrect/invalid Provisioning message. This should 352 include an error code for the AN to indicate that it does not know a 353 given TLV and does not support the corresponding capability, and an 354 error code for the AN to indicate that a given TLV and its 355 corresponding capabilities have been "negotiated out" during the 356 Capability negotiation phase. The present document can indicate that 357 (i) the 1st error code can be used when Provisioning message contain 358 a multicast related TLV but the AN does not support it and (ii) the 359 2nd error code can be used when Bandwidth-delegation-Control TLV 360 indicates "active" but Bandwidth Delegation is not part of the 361 negotiated multicast capabilities]. 363 4.2. Port Management Message 365 As defined in [I-D.ietf-ancp-protocol], the NAS may send line 366 configuration information to the AN ("ANCP based Line Configuration" 367 use case) using GSMP Port Management messages modified to contain an 368 extension block. [I-D.ietf-ancp-protocol] defines a number of TLVs 369 that can be included in the Extension Value field inside a Port 370 Management message (e.g. "Access-Loop-Circuit-ID", "Service- 371 Profile-Name"). 373 This document specifies that the Port Management message MAY also be 374 used by the NAS to associate a "Multicast-Service-Profile" (aka. a 375 triple of White, Grey and Black lists) to a AN port. To do so, the 376 NAS includes a "Multicast-Service-Profile-Name" TLV (specified in 377 Section 5.6) in the Port Management message. 379 In addition, when bandwidth delegation is activated for this AN, the 380 Port Management message MAY be used to provision the initial amount 381 of bandwidth delegated to the AN for multicast admission control 382 (hereafter referred to as the "delegated bandwidth"). To do so, the 383 NAS MAY include in the Port Management message a "Bandwidth- 384 Allocation" TLV (defined in Section 5.3) . 386 [Editor's Note: the Port Management message requires the 387 specification of an Access-Loop-Circuit-Id TLV indicating the target 388 of the assignment. Thinking about the possibility of PON, will we be 389 updating the definition of Access-Loop-Circuit-Id TLV to include 390 default naming formats for PON? Of the authors, TT prefers this 391 route, leaving Target to designate multiple targets for the same 392 command.] 394 4.3. Multicast Replication Control Message 396 This section defines a new message called the Multicast Replication 397 Control message. The Multicast Replication Control message is sent 398 by the NAS to the AN with one or more directives to add (join) or 399 delete (leave) a multicast flow on a target object identified in the 400 content of the message. When a response is needed an AN MUST use the 401 Multicast Status message (defined in Section 4.4) to convey the 402 outcome of the directive. 404 The Message Type for the Multicast Replication Control message is 405 0x90. The sender of a Multicast Replication Control message MUST set 406 the Result field to "0x00" meaning "Ignore". The sender MUST 407 populate the ANCP Transaction Identifier field with a unique value, 408 as described in section 5.4.5 of [I-D.ietf-ancp-protocol]. 410 The NAS MAY issue a Multicast Replication Control message to the AN 411 to convey one or more directives to add (join) or delete (leave) a 412 multicast flow. The NAS sends this message on its own initiative to 413 support the NAS initiated Multicast Control use case presented in 414 [I-D.ietf-ancp-framework] and summarized in Section 3.1. The NAS 415 sends this message in response to a Multicast Admission Control 416 message (defined in Section 4.5) received from the AN to support the 417 conditional access and admission control use case presented in 418 [I-D.ietf-ancp-framework] and summarized in Section 3.2. 420 The ANCP Multicast Replication Control message payload contains the 421 following TLVs: 423 o Target TLV: The Target TLV is defined in [I-D.ietf-ancp-protocol]. 424 It MUST appear once and only once. It is encoded as specified in 425 [I-D.ietf-ancp-protocol] and identifies the AN port subject to the 426 request for admission or release. 428 o Command TLV: The Command TLV is defined in 429 [I-D.ietf-ancp-protocol]. It MUST be present. It MAY appear 430 multiple times. Each Command TLV contains a multicast flow 431 directive for the target. 433 The contents of the Command TLV for the Multicast Replication Control 434 Message are defined in Figure 4 and subsequent text. 436 0 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Command Code |R O M Flags | Command Length | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Addr Family | Encoding Type | Multicast Flow Source Address | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Multicast Flow Source Address (Cont'd) ... | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Addr Family | Encoding Type | Multicast Flow Group Address | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Multicast Flow Group Address (Cont'd) ... | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | ... | Padding to 32-bit boundary | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 Figure 4: Command TLV in Multicast Replication Control Message 454 Command Code: 455 Command directive: 0x01 - Add; 0x02 - Delete; 0x03 - Delete 456 All. 458 Command Length: 459 Length in bytes of the Command including multicast flow 460 address, but excluding the Command Code header and flags. 462 Flags: 463 8 bit General purpose Flag field. Currently the following 464 flags are defined: 466 R - Resource Admitted Flag. Set to 1 in an add 467 command to indicate that the flow resources have 468 been reserved by admission control, 0 otherwise. 469 Not used in delete command. 471 O - Flow Accounting. When set in add command 472 indicates that byte accounting for the flow is to 473 commence. 475 M - When set, indicates that the multicast flow is 476 SSM; the Command MUST then specify both the 477 source and the group address. When not set, 478 indicates that the multicast flow is ASM; the 479 Command MUST then specify the group address only, 480 omitting the Source Address field. 482 Address Family: 483 The address family of the address with values as defined in 484 [IANAAEA]. 486 Encoding Type: 487 The type of encoding used within a specific Address Family. 488 The value `0' is reserved for this field, and represents 489 the native encoding of the Address Family. This is 490 consistent with the address encoding specified in 491 [RFC4601]. 493 Address: 494 The address as represented by the given Address Family and 495 Encoding Type. This is consistent with the address 496 encoding specified in [RFC4601]. 498 If needed, padding is done after both addresses so that the TLV is 499 32-bit aligned. 501 If the AN receives a Multicast Replication Control Message containing 502 an unrecognized Target TLV, the AN MUST return a Multicast Status 503 Message (Section 4.4) indicating the "Unrecognised port Type - 0x04" 504 error. 506 Each Multicast Replication Control Message MAY contain one or more 507 commands, each encapsulated in its own Command TLV. The sender MUST 508 use a separate Command TLV for each distinct multicast flow. 510 When successive commands (in the same or different messages) relate 511 to the same Target and multicats flow, the state of each feature 512 controlled or affected by flags or by optional attributes received in 513 the Multicast Replication Control message, SHALL be as set by the 514 last command or message referring to that target and flow and 515 containing the controlling flag or optional attribute. As an 516 example, successive Multicast Replication Control messages containing 517 add commands for a given port and flow, but differing only in the 518 accounting flag setting SHALL be interpreted to mean that the state 519 of the accounting feature is as set in the final command received, 520 but all other feastures are as set in the initial message. 522 If more than one Command TLV is present in a Multicast Replication 523 Control message, the AN MUST act on the commands in the order in 524 which they are presented in the message. The AN SHALL assign a 525 sequence number to each command in a given Multicast Replication 526 Control message, starting from 0x01 for the first command. The AN 527 MUST use the assigned sequence number in any response message when 528 necessary to distinguish the Command TLV instance to which a given 529 status code applies. 531 The processing/execution of multiple commands contained in a single 532 Multicast Control message MUST be interrupted at the first error 533 encountered, and the remaining commands in the Multicast Replication 534 Control message discarded. In such a case a Multicast Status message 535 MUST be sent indicating the command number that resulted in the error 536 along with the error code. 538 When the order of processing of two commands does not matter, the 539 commands MUST be transmitted in separate Multicast Replication 540 Control messages. 542 Each command directive is equipped with an 8-bit Flags field that 543 allows specification of Multicast ASM or SSM modes of operation, and 544 an indication of other features or conditions attached to this 545 command (e.g. To enable accounting for the flow, etc). Unassigned 546 flags are reserved for future use, and could in the future be subject 547 of the capability negotiation. When receiving a Multicast 548 Replication Control Message containing an unrecognized Flag set (to 549 1), a recipient MUST interpret it as an error, and generate an 550 Multicast Status message indicating the error. 552 The multicast flow subject to the command is specified by means of 553 one or two well known Address Family designators ([IANAAEA]), the 554 IPv4-Address-Family (0x01) and the IPv6-Address-Family (0x02). When 555 the M flag is set the two Address-Family tuples MUST be present in 556 the strict order specifying the multicast flow source and group 557 respectively. When the M flag is cleared only one Address-Family is 558 allowed, specifying the multicast flow. 560 For future extensibility, each Command TLV MAY also have additional 561 [sub- or same level ????] TLVs appended following the command and 562 multicast flow information (referred to as "TLVs" in the message 563 format above). Unrecognized TLVs SHOULD be silently discarded. The 564 figure below is an example of a Multicast Replication Control message 565 that would result in a swap from multicast SSM flows 192.0.2.1, 566 233.252.0.2, to 192.0.2.2, 233.252.0.3 on the Target identified by 567 the "Access Loop Circuit ID": 569 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 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Type (0x88-0C) | Length | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Vers | Sub |MessageType=90 | 0x02 | Code | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Partition ID | Transaction Identifier = 0001 | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 |I| SubMessage Number | Length | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Type = Target 0x1000 | Target TLV Length | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | | 584 ~ Access Loop Circuit ID ~ 585 | | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | Type = Command TLV | Command-TLV Length | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Cmd Code=0x02 |0 0 1 | Command Length | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 |Mcast Source (Ctnd) 192.0.2.1 | AddrFamily 01 | EncType 0x0 | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Mcast Flow : 233.252.0.2 | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 597 | Type = Command-TLV | Command-TLV Length | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Cmd Code=0x01 |0 0 1 | Command Length | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.2 | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 |Mcast Source (Ctnd) 192.0.2.2 | AddrFamily 01 | EncType 0x0 | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Mcast Flow: 233.252.0.3 | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 4.4. Multicast Status Message 610 This section defines a new message called the Multicast Status 611 message. The general purpose of the Multicast Status message is to 612 provide information on the success or failure to process a message 613 previously received from the sender's peer. Depending on the 614 particular use case, the Multicast Status message MAY be sent by 615 either the NAS or the AN. In some cases the Multicast Status message 616 is REQUIRED, even when processing of the original message is 617 successful. In other cases the Multicast Status message is used only 618 to report failures. For further details see the descriptions of 619 other multicast-related messages presented in this section. 621 The Message Type for the Multicast Status message is 0x91. 623 A Multicast Status message MUST use the same ANCP Transaction ID as 624 that in the message that it is responding to. The Success or Failure 625 status is reported in the Result field of the ANCP header as 626 described in section 5 of [I-D.ietf-ancp-protocol]. 628 A Multicast Status Message indicating Success SHOULD simply consist 629 only of the base ANCP header with no body, however the message MAY 630 contain one or more TLVs that are meant to communicate any relevant 631 information to an application. The payload of a Multicast Status 632 Message indicating Failure MUST contain a Status-Info TLV (0x12) (as 633 defined in [I-D.ietf-ancp-protocol]) as its first TLV. This SHOULD 634 be followed by the Target TLV (as defined in 635 [I-D.ietf-ancp-protocol]) and Port-info [???]. Other TLVs MAY be 636 present. A Multicast Status message indicating Failure MUST be sent 637 whenever a multicast control message cannot be fulfilled or results 638 in an execution error. The Cmnd Nmbr parameter in the Status-Info 639 TLV contained by the Multicast Status Message is used to indicate the 640 sequence number of the command in the Multicast Replication Control 641 Message that resulted in an error. In the case where the problem is 642 with the Multicast Replication Control Message as a whole, or in the 643 case where the problem is with a message that is not a Multicast 644 Replication Control message, the Cmnd Nmbr parameter SHOULD be set to 645 0x00. 647 The following values are defined for the Result Code field in the 648 Status-Info TLV contained in a Multicast Status Message: 650 0x00 - Success 652 0x01 - Malformed message 654 0x02 - Command not supported 656 0x03 - Flag set but not supported 658 0x04 - Unrecognized Target 659 0x05 - Unsupported Address Family 661 0x06 - Malformed flow address 663 0x07 - No resources 665 0x08 - Unknown Target 667 0x09 - Target down 669 0x0a - Configuration error (such as Port not enabled for 670 multicast) 672 0x0b - Multicast flow does not exist 674 0x0c - Unsupported address encoding 676 0x0d - Additional info needed to execute command (payload MAY 677 contain an indication of the expected info) 679 0x0e - Multicast flow count exceeded 681 0x0f - M Flag set, but no IP Source address provided 683 0x10 - Transaction-id out of sequence 685 0x11 - Invalid preferred bandwidth amount 687 0x12 - Bandwidth delegation not activated 689 0x13 - Delegated bandwidth reset required 691 An example of a failure message for an invalid address, including the 692 Target TLV for a 4 byte "Access Loop Circuit ID", followed by TLV 693 padding, is as follows: 695 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 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Type (0x88-0C) | Length | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Vers | Sub |MessageType=91 | 0x4 | Code | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | Partition ID | Transaction Identifier = 0001 | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 |I| SubMessage Number | Length | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Status-info-TLV=0x12 | Status-TLV-Length | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Result Code | Cmd Number | Error Message Length | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Error Message (padded to 4) if Length > 0 | 710 +---------------------------------------------------------------+ 711 | Target TLV=0x10 | Target-Length | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | Access Loop ID type | Access-Loop ID Length | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | circuit ID | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 4.5. Multicast Admission Control Message 720 This section defines a new message called the Multicast Admission 721 Control message. The Multicast Admission Control message is sent by 722 the AN to the NAS to request admission of a multicast flow, or to 723 notify of the removal of a multicast flow, over a given target. The 724 NAS will use a Multicast Replication Control message (as discussed in 725 Section 4.3) in order to convey back to the AN the outcome of the 726 admission request. 728 The Message Type for the Multicast Admission Control message is 0x92. 730 The AN sending the Multicast Admission Control message MUST set the 731 Result field to "0x00" meaning "Ignore". 733 The AN MUST populate the ANCP Transaction Identifier field with a 734 unique value, as described in section 5.4.5 735 of[I-D.ietf-ancp-protocol] . 737 The ANCP Multicast Admission Control message payload contains two 738 TLVs: 740 o Target TLV: The Target TLV is defined in [I-D.ietf-ancp-protocol]. 741 It MUST appear once and only once in the Multicast Admission 742 Control message. It is encoded as specified in 744 [I-D.ietf-ancp-protocol] and identifies the AN port subject to the 745 request for admission or release. 747 o Command TLV: The Command TLV is defined in 748 [I-D.ietf-ancp-protocol]. It MUST be present. If it appears more 749 than once, only the first instance is considered meaningful in the 750 present version of the document and the other instances are 751 ignored . The Command TLV is encoded as specified in Section 4.3 752 with the following additional rules: 754 * the R flag is set to 0 756 * the O flag is set to 0 758 * the Command field is set to "0x01 - Add" when the message 759 conveys a Join , to "0x02 - Delete" when the message conveys a 760 Leave and to "0x03 - Delete All" when the message conveys a 761 Leave of all channels (on the target). 763 * The M Flag, Multicast Source Address and Multicast Flow Address 764 of the Command TLV identify the multicast flow subject to the 765 request for admission or release. 767 * a Request-Source-IP sub-TLV (as defined in Section 5.7) MAY be 768 included by the AN to convey the IP address of the sender of 769 the join/leave message (e.g. IGMP/MLD Join/Leave) that 770 triggered the AN to include the corresponding Command TLV in 771 the Admission Control message. If it appears more than once, 772 only the first instance is considered meaningful and the other 773 instances are ignored. 775 * a Request-Source-MAC sub-TLV (as defined in Section 5.8) MAY be 776 included by the AN to convey the MAC address of the sender of 777 the join/leave message (e.g. IGMP/MLD Join/Leave) that 778 triggered the AN to include the corresponding Command TLV in 779 the Admission Control message. If it appears more than once, 780 only the first instance is considered meaningful and the other 781 instances are ignored. 783 In the future, the specification of the Admission Control message may 784 be extended to allow transport of more than a single directive (e.g. 785 to carry both a leave from one group and a join to another group for 786 the same Target). It is expected that this would support a similar 787 notion of strict sequenced processing as currently defined for 788 handling multiple directives in the Multicast Replication Control 789 message whereby all directives following the first directive that can 790 not be executed are not executed either. When the strict sequenced 791 processing of the directives is not required the directives are 792 distributed across separate messages. 794 On receipt of an Multicast Admission Control message, the NAS: 796 o MUST ignore the Result field 798 o if the directive in the Multicast Admission Control message is 799 "0x02 - Delete" or "0x03 - Delete All" and is processed correctly 800 by the NAS, the NAS MUST NOT generate any ANCP message in response 801 to the Multicast Admission Control message 803 o if the directive in the Multicast Admission Control message is 804 "0x01 - Add" and is accepted by the NAS, the NAS MUST generate a 805 Multicast Replication Control in response to the Multicast 806 Admission Control message. The Multicast Replication Control 807 message: 809 * MUST contain a Result set to 0x00 811 * MUST contain a Transaction ID generated by the NAS (distinct 812 non-zero, and linearly incremented by NAS for each request per 813 adjacency). 815 * MUST contain the directive as accepted by the NAS 817 o if the directive in the Multicast Admission Control message is 818 "0x01 - Add", is processed correctly but not accepted by the NAS 819 (i.e. it does not pass the admission control or conditional access 820 check), the NAS MAY generate a Multicast Replication Control 821 message in response to the Multicast Admission Control message. 822 This optional message can be used by the AN to maintain statistics 823 about admission control reject and, in the future, when the 824 protocol between the subscriber and the AN allows explicit 825 notification of join reject (e.g. 826 [I-D.morin-mboned-igmpmld-error-feedback]). When used in this 827 situation, the Multicast Replication Control message: 829 * MUST contain a Result set to 0x00 831 * MUST contain a Transaction ID generated by the NAS (distinct 832 non-zero, and linearly incremented by NAS for each request per 833 adjacency). 835 * MUST contain the directive rejected by the NAS (i.e. Target 836 TLV and Command TLV) but with a Command Code set to "0x04 - 837 Admission Control Reject", "0x05 - Conditional Access Reject" 838 or "0x06 - Admission Control and Conditional Access Reject". 840 o if the Multicast Admission Control message cannot be processed 841 correctly by the NAS (e.g. the message is malformed, the multicast 842 flow does not exist etc.), the NAS MUST generate a Multicast 843 Status message (defined in Section 4.4) in response to the 844 Multicast Admission Control message. The Multicast Status 845 message: 847 * MUST contain a Result set to "Failure" in the ANCP header 849 * MUST contain a Transaction ID that echoes the value of the 850 Transaction ID received in the Multicast Admission Control 851 message. 853 * MUST contain a Status TLV including a Result Code indicating 854 the reason why the Admission Control message could not be 855 processed and encoded as specified in Section 4.4. 857 4.6. Bandwidth Reallocation Request Message 859 The Bandwidth Reallocation Request message is used when the Bandwidth 860 Delegation capability has been activated. It MAY be sent either by 861 the NAS or by the AN to request an adjustment in the amount of 862 delegated bandwidth. It will be sent by the NAS typically to reduce 863 the multicast bandwidth allocated to the AN in order for the NAS to 864 satisfy a request to add a unicast video channel. Conversely, the AN 865 will send a Bandwidth Reallocation Request to obtain additional 866 bandwidth to satisfy a request to add a multicast channel. In each 867 case, the requestor has a minimum requirement for additional 868 bandwidth, and MAY ask for additional bandwidth beyond this amount 869 (say to handle anticipated future requests). 871 The Message Type for the Bandwidth Reallocation Request message is 872 0x94. The Result field in the header of the Bandwidth Reallocation 873 Request message is not used and MUST be set to Ignore (0x00). The 874 Bandwidth Reallocation Request message MUST contain two TLVs: 876 o the Target TLV (section 5.4.5.1.1 of [I-D.ietf-ancp-protocol]), 877 specifying a single access line; [TT - I would prefer the Access- 878 Loop-Circuit-Id TLV, believing it should evolve to include non-DSL 879 identifiers, but the majority overruled me]; 881 o the Bandwidth-Request TLV (Section 5.4), specifying the required 882 and preferred amounts of delegated bandwidth. 884 The bandwidth values in the Bandwidth-Request TLV are expressed in 885 terms of total bandwidth delegated to the AN. 887 The choice of "total bandwidth" rather than "incremental 888 bandwidth" was made so that it would be easier for the AN and NAS 889 to keep their respective views of the current amount of delegated 890 bandwidth synchronized. 892 Because the values are totals rather than desired increments/ 893 decrements, the relationship between the required amount and the 894 preferred amount will differ depending on whether the Bandwidth 895 Reallocation Request message is issued by the NAS or the AN. 897 o If the NAS is making the request, the preferred amount MUST be 898 less than or equal to the required amount. The required amount 899 MUST be less than the current delegated bandwidth value. 901 o If the AN is making the request, the preferred amount MUST be 902 greater than or equal to the required amount. The required amount 903 MUST be greater than the current delegated bandwidth value. 905 If these conditions are violated and the problem is the relationship 906 between the required amount and the receiver's view of the current 907 delegated bandwidth, the delegated bandwidth reset procedure 908 described in Section 4.10 MUST be performed. If the problem is the 909 relationship between the preferred and required amounts, the peer 910 receiving the Bandwidth Reallocation Request message MUST return a 911 Multicast Status message where the Result field in the header 912 indicates Failure (0x4) and the Status-Info TLV contains the 913 following values: 915 Result Code = invalid preferred bandwidth amount (0x11); 917 Command Number = 0x1; 919 Error Message Length = 0x0 (or optionally the length of an error 920 message, padded to a four-octet boundary); 922 Error Message (optional text); 924 the Target TLV, copied from the Bandwidth Reallocation Request 925 message; 927 the Bandwidth-Request TLV, also copied from the request message. 929 When the peer receives a valid Bandwidth Reallocation Request 930 message, it SHOULD determine whether it can satisfy the request from 931 its existing allocation of unused video bandwidth. If it decides 932 that it can reallocate bandwidth to the peer, it MAY choose to return 933 any amount between the required and the preferred amounts indicated 934 in the Bandwidth Reallocation Request message. The peer MUST return 935 a Bandwidth Transfer message Section 4.7 indicating its decision. If 936 the request is met, the Result field of the Bandwidth Transfer 937 message MUST be set to Success (0x3), and the Bandwidth-Allocation 938 TLV (Section 5.3) MUST contain the new value of delegated bandwidth. 939 This new value MUST lie between the required and preferred values, 940 inclusive, from the request message. If the request is not met, the 941 Result field of the Bandwidth Transfer message MUST be set to Failure 942 (0x4) and the Bandwidth Allocation TLV MUST contain the value of the 943 current amount of delegated bandwidth as the responder views it. 945 To avoid deadlock due to race conditions, the following rules MUST be 946 applied: 948 a. If the NAS receives a Bandwidth Reallocation Request message 949 while it has a Bandwidth Reallocation Request message of its own 950 outstanding for the same access line, the NAS MUST provide an 951 immediate failure response to the request from the AN. 953 b. If the AN receives a Bandwidth Reallocation Request message while 954 it has a Bandwidth Reallocation Request message of its own 955 outstanding for the same access line, the AN MUST release any 956 bandwidth it has already committed to an outstanding Join request 957 while it is awaiting a response from the NAS. It MUST decide 958 upon and send its response to the NAS taking the released 959 bandwidth into account. 961 [Editor's Note: This is an arbitrary rule which gives priority to 962 unicast over multicast. Is that the right direction?] 964 4.7. Bandwidth Transfer Message 966 The Bandwidth Transfer message is used to transfer video bandwidth 967 from the sender to the peer for a specific access line. This message 968 MAY be sent either from the AN or from the NAS. As described in the 969 previous section, it is the required response to a valid Bandwidth 970 Reallocation Request message. 972 The Bandwidth Transfer message MAY also be used to transfer bandwidth 973 autonomously from one peer to another. One example of this usage is 974 to release bandwidth borrowed earlier by means of the Bandwidth 975 Reallocation Request message. When the message is used in this way, 976 the Result field in the Bandwidth Transfer message MUST be set to 977 Ignore (0x0). 979 This allows the receiver to distinguish between an autonomous 980 transfer and a response to a previous Bandwidth Reallocation 981 Request, for purposes of validation. 983 The Message Type for the Bandwidth Transfer message is 0x95. The 984 Bandwidth Transfer message MUST contain the following TLVs: 986 o the Target TLV, designating the access line concerned; 988 o an instance of the Bandwidth-Allocation TLV (Section 5.3). 990 The bandwidth value in the Bandwidth-Allocation TLV is the new amount 991 of delegated bandwidth. The following relationships MUST hold: 993 o if the message is sent by the NAS, the bandwidth value in the 994 Bandwidth-Allocation TLV MUST be greater than or equal to the 995 current amount of delegated bandwidth for the access line 996 concerned; 998 o if the message is sent by the AN, the bandwidth value in the 999 Bandwidth-Allocation TLV MUST be less than or equal to the current 1000 amount of delegated bandwidth for the access line concerned. 1002 In either case, equality to the current delegated bandwidth is 1003 permitted only for a failure response to a previous Bandwidth 1004 Reallocation Request. 1006 If the Bandwidth Transfer message satifies these conditions, the 1007 receiver MUST update its view of the amount of delegated bandwidth to 1008 the value given in the Bandwidth-Allocation TLV. If, on the other 1009 hand, the bandwidth value in the Bandwidth-Value TLV is invalid, the 1010 receiver MAY either accept the new value or MAY choose to initiate 1011 the delegated bandwidth reset procedure described in Section 4.10. 1013 4.8. Delegated Bandwidth Query Request and Response Messages 1015 The Message Type for the Delegated Bandwidth Query Request and 1016 Response messages is 0x96. 1018 The Delegated Bandwidth Query Request message MAY be sent by the NAS 1019 to retrieve the AN's view of the total amount of delegated bandwidth 1020 and the amount that is already committed. The request contains one 1021 TLV: 1023 o a Target TLV designating the access line(s) for which the 1024 information is requested. 1026 Consistently with other multicast-related messages, the Result field 1027 in the header of the Delegated Bandwidth Query Request message MUST 1028 be set to Ignore (0x0). 1030 If the AN receives an invalid Delegated Bandwidth Query Request 1031 message, it MUST return a Multicast Status message with the Result 1032 field in the header set to Failure (0x4). The following cases may 1033 occur: 1035 o if the Target is invalid, the Status-Info TLV contains the 1036 following values: 1038 Result Code = unrecognized target (0x04); 1040 Command Number = the order of the invalid Target TLV within the 1041 request, numbering from 1 for the first one listed; 1043 Error Message Length = 0x0 (or optionally the length of an 1044 error message, padded to a four-octet boundary); 1046 Error Message (optional text); 1048 the invalid Target TLV, copied from the Delegated Bandwidth 1049 Query Request message. 1051 o if bandwidth delegation is not activated on the AN, the Status- 1052 Info TLV contains the following values: 1054 Result Code = bandwidth delegation not activated (0x12); 1056 Command Number = 0x1; 1058 Error Message Length = 0x0 (or optionally the length of an 1059 error message, padded to a four-octet boundary); 1061 Error Message (optional text). 1063 The AN MUST respond to a valid request with a Delegated Bandwidth 1064 Query Response. The Result field in the header of this message MUST 1065 be set to Success (0x3). This message contains the following TLVs: 1067 o the Target TLV, copied from the request; 1069 o one instance of the Bandwidth-Status TLV (Section 5.5) for each 1070 access line designated in the Target TLV. The instances MUST have 1071 the same order in the response as the corresponding access lines 1072 in the Target TLV. 1074 [Editor's Note: the base protocol draft is incomplete regarding the 1075 specification of multiple access lines in the Target TLV.] 1077 4.9. Multicast Flow Query Request and Response Messages 1079 This section defines two new messages called the Multicast Flow Query 1080 Request and Multicast Flow Query Response. The Multicast Flow Query 1081 Request is sent by the NAS to request information about the multicast 1082 flows that are active on the AN. The Multicast Flow Query Response 1083 is sent in response by the AN to provide the requested information to 1084 the NAS. 1086 The Message Type for the Multicast Flow Query Request and Multicast 1087 Flow Query Response messages is 0x97. The sender of a Multicast Flow 1088 Query Request and Multicast Flow Query Response message MUST set the 1089 Result field to "0x00" meaning "Ignore". 1091 The Multicast Flow Query Request message MAY be sent by the NAS to 1092 retrieve the AN's view of which multicast flows are currently active 1093 on one (or multiple) given port(s) of the AN. In that case, the 1094 Multicast Flow Query Request payload MUST contain the following TLVs: 1096 o Target TLV. It MUST appear at least once. Each occurence 1097 identifies one AN port for which information on active multicast 1098 flows is queried. It is encoded as specified in 1099 [I-D.ietf-ancp-protocol]. 1101 The Multicast Flow Query Request message MAY be sent by the NAS to 1102 retrieve the AN's view of which ports one (or multiple) given 1103 multicast flow(s) is (are) currently active on. In that case, the 1104 Multicast Flow Query Request payload MUST contain the following TLVs: 1106 o Multicast-Flow TLV. It MUST appear at least once. Each occurence 1107 identifies one multicast flow for which information is queried. 1108 It is encoded as specified in Section 5.9. 1110 The Multicast Flow Query Request message MAY be sent by the NAS to 1111 retrieve the AN's view of all the multicast flows currently active on 1112 each and every port of the AN. In that case, the Multicast Flow 1113 Query Request payload MUST NOT contain the Target TLV nor the 1114 Multicast-Flow TLV. 1116 If the AN receives an invalid Multicast Flow Query Request message, 1117 it MUST return a Multicast Status message with the Result field in 1118 the header set to Failure (0x4). The following cases may occur: 1120 o if the Target is invalid, the Status-Info TLV contains the 1121 following values: 1123 Result Code = unrecognized target (0x04); 1124 Command Number = the order of the invalid Target TLV within the 1125 request, numbering from 1 for the first one listed; 1127 Error Message Length = 0x0 (or optionally the length of an 1128 error message, padded to a four-octet boundary); 1130 Error Message (optional text); 1132 the invalid Target TLV, copied from the Multicast Flow Query 1133 Request message. 1135 o [Editor's note: if needed, add other error codes ???- eg if query 1136 contained both Target TLV and Multicast Flow TLV] 1138 The AN MUST respond to a valid Multicast Flow Query Request message 1139 with a Multicast Flow Query Response message. 1141 If the Multicast Flow Query Request contained one (or more) Target 1142 TLV, the AN MUST include, for each of these Target TLVs, the 1143 following set of TLVs: 1145 o Target TLV. This MUST be identical to the Target TLV in the 1146 received Multicast Flow Query Request message. 1148 o Multicast Flow TLV(s). The Multicast Flow TLV MUST appear once 1149 per Multicast Flow that is currently active on the AN port 1150 identified in the preceding Target TLV. 1152 The Target TLVs MUST appear in the response from the AN in the same 1153 order as in the query from the NAS. 1155 If the Multicast Flow Query Request contained one (or more) Multicast 1156 Flow TLV, the AN MUST include, for each of these Multicast Flow TLVs, 1157 the following set of TLVs: 1159 o Multicast Flow TLV.This MUST be identical to the Target TLV in the 1160 received Multicast Flow Query Request message. 1162 o Target TLV(s). The Target TLV MUST appear once per AN port on 1163 which the multicast flow identified in the preceding Multicast 1164 Flow TLV is active. 1166 The Multicast Flow TLVs MUST appear in the response from the AN in 1167 the same order as in the query from the NAS. 1169 If the Multicast Flow Query Request contained no Target TLV and no 1170 Multicast Flow TLV, the AN MUST include, for each and every AN port, 1171 the following set of TLVs: 1173 o Target TLV. This MUST identify one AN port. 1175 o Multicast Flow TLV(s). The Multicast Flow TLV MUST appear once 1176 per Multicast Flow that is currently active on the AN port 1177 identified in the preceding Target TLV. 1179 4.10. Delegated Bandwidth Reset Procedure 1181 As described above, the receiver of a Bandwidth Reallocation Request 1182 or Bandwidth Transfer message may determine that a bandwidth value in 1183 that message bears an incorrect relationship to its view of the 1184 current amount of delegated bandwidth. The probable cause of this 1185 condition is a discrepancy between its view and its peer's view of 1186 this amount. Upon detecting this condition, the receiver MAY choose 1187 to initiate the reset procedure described in this section. If so, it 1188 MUST send a Multicast Status message to its peer with the Result 1189 field in the header set to Failure (0x4) and a Status-Info TLV 1190 containing the following values: 1192 Result Code = delegated bandwidth reset required (0x13); 1194 Command Number = 0x1; 1196 Error Message Length = 0x0 (or optionally the length of an error 1197 message, padded to a four-octet boundary); 1199 Error Message (optional text); 1201 the Target TLV, copied from the received message 1203 an instance of the Bandwidth-Allocation TLV containing the 1204 receiver's view of the current amount of delegated bandwidth. 1206 Upon sending or receiving a Multicast Status message containing this 1207 Result Code, the NAS MUST take the following actions: 1209 1. halt processing of admission requests for the access line 1210 indicated by the Target TLV until the reset procedure is 1211 complete; 1213 2. issue a Delegated Bandwidth Query request message to the AN to 1214 determine the amount of bandwidth it has currently committed to 1215 multicast usage, and its view of the amount of delegated 1216 bandwidth; 1218 3. based on the reply and possibly in consultation with the Policy 1219 Server, apply policy to determine what the amount of delegated 1220 bandwidth should be; 1222 4. issue a Port Management message where the Access-Loop-Circuit-Id 1223 TLV is derived from the Target TLV in the Multicast Status 1224 message. The Port Management message MUST contain a Bandwidth- 1225 Allocation TLV giving the decided amount of delegated bandwidth. 1227 5. update its own view of the current amount of delegated bandwidth 1228 to the decided amount. 1230 At this point the reset procedure is complete and the NAS can resume 1231 processing of admission requests for the affected access line. 1233 Upon sending or receiving a Multicast Status message containing this 1234 Result Code, the AN MUST take the following actions: 1236 1. halt processing of admission requests for the access line 1237 indicated by the Target TLV until the reset procedure is 1238 complete; 1240 2. wait for and respond to a Delegated Bandwidth Query request 1241 message, indicating the amount of bandwidth it has currently 1242 committed to multicast usage and its view of the amount of 1243 delegated bandwidth; 1245 3. wait for a Port Management message giving the decided amount of 1246 delegated bandwidth for the access line concerned; 1248 4. update its view of the current amount of delegated bandwidth to 1249 the amount received in the Port Management message. 1251 At this point the reset procedure is complete and the AN can resume 1252 processing of admission requests for the affected access line. 1254 5. ANCP TLVs and Sub-TLVs 1256 This section defines new ANCP TLVs and sub-TLVs or extends existing 1257 ones. 1259 5.1. Multicast-Service-Profile TLV 1261 This document defines the new Multicast-Service-Profile TLV. 1263 The Multicast-Service-Profile TLV MAY be included in a Provisioning 1264 message as specified in Section 4.1. 1266 The Multicast-Service-Profile is illustrated in Figure 5: 1268 1 2 3 1269 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 1270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1271 |TLV Type = Mcast Service Profile | TLV Length | 1272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 | Multicast-Service-Profile-Name Sub-TLV | 1274 | Sub-TLV type = 0x0001 | 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1276 | White-List Sub-TLV | 1277 | Sub-TLV type = 0x0002 | 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 | Grey-List Sub-TLV | 1280 | Sub-TLV type = 0x0003 | 1281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1282 | Black-List Sub-TLV | 1283 | Sub-TLV type = 0x0004 | 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1286 Figure 5: Multicast-Servive-Profile TLV 1288 Multicast Service Profile TLV Type: 1290 TLV (0x13) : indicating that this is a Multicast Service 1291 Profile TLV 1293 Each of the four sub-TLVs begins with a 32-bit header consisting of a 1294 16-bit sub-TLV type code followed by a 16-bit length field giving the 1295 amount of data following this sub-TLV header in octets. The type 1296 code values for the respective sub-TLVs are indicated in the figure. 1297 The content of the sub-TLV follows immediately after the sub-TLV 1298 header. The sub-TLVs are placed into the list consecutively without 1299 intervening padding. The Multicast Service Profile Name sub-TLV MUST 1300 be present, and MUST be unique over all profiles provisioned to the 1301 same AN partition. At least one other sub-TLV MUST be present, but 1302 any of White List, Grey List, or Black List sub-TLV MAY be omitted if 1303 not applicable to this profile. 1305 The Multicast-Service-Profile-Name sub-TLV is an opaque sequence of 1306 octets used to refer to the profile when activating it for a given 1307 target within a Port Management message (see Section 4.2). 1309 The content of the White-List, Grey-List, and Black-List sub-TLVs 1310 following their respective headers is in each case a sequence of 1311 multicast flow fields organized by address family. IPv4 addresses 1312 are listed first, followed by IPv6 addresses. Either set of 1313 addresses MAY be omitted if not applicable, but at least one set of 1314 addresses MUST be present. Figure 6 shows the detailed layout of a 1315 white, grey, or black list, where the detailed layout of an 1316 individual multicast flow field is described below. The list length 1317 in Figure 6 is the number of octets of multicast flow field data for 1318 that address family following the list header. 1320 1 2 3 1321 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 1322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1323 | Sub-TLV tag = 0x0002,3,4 | Sub-TLV Length | 1324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1325 | IP Ver=0x0000 (IPv4) | List Length | 1326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 | Multicast flow fields | 1328 ...... 1329 | | 1330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 | IP Ver=0x0001 (IPv6) | List Length | 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 | Multicast flow fields | 1334 ...... 1335 | | 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1338 Figure 6: Organization of a White, Grey, or Black List 1340 Each multicast flow field refers either to a Single Source Multicast 1341 (SSM) channel or to an Any Source Multicast (ASM) group. The scope 1342 of the designation may be broadened to multiple channels or groups 1343 through use of prefix length values smaller than the total address 1344 length for the given address family. Multicast flow fields MUST be 1345 placed consecutively within the sub-TLV without intervening padding 1346 except to round out individual addresses to the nearest octet 1347 boundary. 1349 A multicast flow field consists of two single-octet prefix lengths 1350 followed by zero to two prefix values as shown in Figure 7: 1352 +-+-+-+-+-+-+-+-+ 1353 | Group PrefLen | 1354 +-+-+-+-+-+-+-+-+ 1355 | Source PrefLen| 1356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1357 | Group Prefix (multicast) (0 to 16 octets) | 1358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1359 | Source Prefix (unicast, SSM only) (0 to 16 octets) | 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1362 Figure 7: Organization of a Single Multicast Flow Field 1364 The prefix length has its usual meaning. It is the number of most- 1365 significant bits specified within the corresponding prefix. The 1366 prefix length MAY vary from 0 to 32 in the IPv4 sub-list, and from 0 1367 to 128 in the IPv6 sub-list. A match to the multicast flow 1368 specification is performed based on the prefix values only, ignoring 1369 lower-order bits in the respective addresses. 1371 A value of 0x00 for either the Group PrefLen (prefix length) or the 1372 Source PrefLen indicates that any value of the corresponding address 1373 will match (wild card). If the value 0x00 is provided for a 1374 particular prefix length, the corresponding prefix MUST be omitted 1375 from the field contents. In particular, a value of 0x00 for the 1376 Source PrefLen indicates an ASM multicast entry, and the Source 1377 Prefix will be absent. 1379 The length of a Source or Group Prefix field is equal to (PrefLen + 1380 7)/8 octets, truncated to the nearest integer. Unused bits at the 1381 end of the prefix MUST be set to zeroes. 1383 5.1.1. Profile Processing At the Access Node 1385 When the AN receives an IGMP/MLD Join request, it first checks 1386 whether the program limit for that subscriber has been exceeded. If 1387 so, it discards the request. Otherwise its next step is to determine 1388 whether the source and group of the request match a multicast flow 1389 specification in the white list, the grey list, or the black list 1390 according to the profile assigned to the access line. 1392 If the requested multicast flow matches multiple lists associated 1393 with the access line, then the most specific match will be considered 1394 by the AN. If the most specific match occurs in multiple lists, the 1395 Black list entry takes precedence over the Grey list, which takes 1396 precedence over the White list. In this context, the most specific 1397 match is defined as: 1399 o first, most specific match on the multicast flow address (i.e. on 1400 G of ) 1402 o then, most specific match on the multicast source address (i.e. on 1403 S of ) 1405 If the requested multicast flow is not part of any list, the join 1406 message SHOULD be discarded by the AN. This default behavior can 1407 easily be changed by means of a "catch-all" statement in either the 1408 White list or the Grey list. For instance, adding () in the 1409 White List would make the default behavior to accept join messages 1410 for a multicast flow that has no other match on any list. 1412 If the requested multicast flow matches a flow in the black list, the 1413 AN discards the Join request. 1415 Otherwise, if bandwidth delegation is active for the access line, the 1416 AN determines whether it has enough unused capacity out of the total 1417 video bandwidth that has been delegated to it for multicast admission 1418 control. If so, it does white or grey list processing as described 1419 below. If there is not enough unused bandwidth, it MAY issue a 1420 Bandwidth Reallocation Request message. The required bandwidth 1421 amount in the Bandwidth-Request TLV MUST be large enough that if the 1422 request is granted, there will be sufficient unused capacity to 1423 accommodate the Join request. The AN MAY set the preferred amount in 1424 the Bandwidth-Request TLV to the same value as the required amount, 1425 or to some higher amount determined by configured policy. If the 1426 request fails or if the AN does not choose to issue a Bandwidth 1427 Reallocation Request (e.g., because another such request failed 1428 recently), it does no further processing of the Join request. 1430 If the bandwidth check succeeds or if bandwidth delegation is not 1431 active, then: 1433 o if the requested multicast flow matches a flow in the white list, 1434 the AN MUST autonomously start replicating multicast traffic 1435 according to the request; 1437 o if the requested flow matches a flow in the grey list, the AN MUST 1438 send a Multicast Admission Control message (Section 4.5) to the 1439 NAS with the value of Command set to Add (0x01) and await the 1440 Multicast Replication Control message (Section 4.3) which responds 1441 to it. Note that, when bandwidth delegation is active, the AN 1442 MUST NOT send the Multicast Admission Control message until it has 1443 fully established that the bandwidth checks succeeds (either 1444 because the AN has enough unused capacity in the delegated 1445 bandwidth or because the AN requested and obtained the necessary 1446 increased delegated bandwidth in a Bandwidth REallocation Response 1447 from the NAS). When the Multicast ReplicationControl message 1448 arrives, the AN MUST act according to its content. The AN MAY set 1449 a timer after which it will take no further action on the Join 1450 request and will ignore the Multicast Replication Control 1451 response, if any. 1453 [Editor's Note: for grey list requests, there is a currently 1454 unfulfilled need to indicate to the NAS (or require the NAS to know) 1455 whether admission control has been done at the AN. If so, the NAS 1456 can skip the admission control step and just apply policy.] 1458 When the AN receives a Leave request for an admitted flow, it halts 1459 replication of the indicated channel to the access line concerned. 1460 In the case of a grey list flow, it also notifies the NAS using the 1461 Multicast Admission Control message with the Command TLV set to 1462 Delete (0x03). 1464 5.2. Bandwidth-Delegation-Control TLV 1466 This document defines the new Bandwidth-Delegation-Control TLV. 1468 The Bandwidth-Delegation-Control TLV MAY be included in a 1469 Provisioning message as specified in Section 4.1. 1471 The Bandwidth-Delegation-Control is illustrated below: 1473 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 1474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1475 |TLV Type = Band-Del-Control | TLV Length = 4 | 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 |E| Reserved | 1478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1480 The Bandwidth-Delegation-Control TLV 1482 Bandwidth-Delegation-Control TLV Type: 1484 TLV (0x14) : indicating that this is a Bandwidth- 1485 Delegation-Control TLV 1487 Bandwidth-Delegation-Control TLV Length: 1489 Combined length in bytes of the data inside sub-TLV. 1490 Excludes the sub-TLV Header. 1492 E Flag:: 1494 When set to 0, indicates that Bandwidth Delegation is to be 1495 disabled on the AN. When set to 1, indicates that 1496 Bandwidth Delegation is to be enabled on the AN. When 1497 Bandwidth Delegation is enabled, the AN MUST subject 1498 multicast channels matching the White List or the Grey List 1499 to admission control according to the Bandwidth Delegation 1500 procedures defined in [I-D.ietf-ancp-framework]. 1502 If Bandwidth Delegation is enabled, the NAS SHOULD provision an 1503 initial value for the amount of bandwidth delegated to the AN for 1504 multicast admission control for each line, in a Port Management (Line 1505 Configuration) message. An initial delegated amount MAY be 1506 configured directly on the AN. A delegated bandwidth value received 1507 in a Port Management message overrides any configured value. If no 1508 value is configured and no value is provisioned by the NAS, the 1509 default initial amount of delegated bandwidth is zero. 1511 This implies that in the absence of provisioning or configuration, 1512 the AN will issue a Bandwidth Reallocation Request message to the 1513 NAS asking for multicast bandwidth, the first time it receives an 1514 IGMP/MLD Join for the given line. 1516 5.3. Bandwidth-Allocation TLV 1518 The Bandwidth-Allocation TLV is used to indicate the total amount of 1519 video bandwidth delegated to the AN for multicast admission control 1520 for a given line, in kilobits per second. The TLV has the format 1521 shown in Figure 8. 1523 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 1524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 |TLV Type = Band-Alloc | TLV Length = 4 | 1526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1527 | Delegated amount (kbits/s) | 1528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1530 Figure 8: The Bandwidth-Allocation TLV 1532 Bandwidth-Allocationl TLV Type: 1534 TLV (0x15) : indicating that this is a Bandwidth-Allocation 1535 TLV 1537 5.4. Bandwidth-Request TLV 1539 The Bandwidth-Request TLV is used to request an adjustment of the 1540 total amount of video bandwidth delegated to the AN for multicast 1541 admission control for a given line. The "Required amount" field 1542 indicates the minimum adjustment required to meet the request. The 1543 "Preferred amount" field indicates the adjustment the requestor would 1544 prefer to have, if possible. Section 4.6 discusses the required 1545 relationships between the "Required amount", "Preferred amount", and 1546 current values of total bandwidth delegated to the AN. 1548 The Bandwidth-Request TLV has the format shown in Figure 9. 1550 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 1551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1552 |TLV Type = Band-Req | TLV Length = 8 | 1553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1554 | Required amount (kbits/s) | 1555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1556 | Preferred amount (kbits/s) | 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 Figure 9: The Bandwidth-Request TLV 1561 Bandwidth-Request TLV Type: 1563 TLV (0x16) : indicating that this is a Bandwidth-Request 1564 TLV 1566 5.5. Bandwidth-Status TLV 1568 The Bandwidth-Status TLV is used in the Delegated Bandwidth Query 1569 Response to report the AN's view of the current amount of delegated 1570 bandwidth and the amount of bandwidth within that quantity that is 1571 already committed to active programs. The Bandwidth-Status TLV has 1572 the format shown in Figure 10. 1574 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 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 |TLV Type = Band-Status | TLV Length = 8 | 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1578 | Delegated amount (kbits/s) | 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 | Committed amount (kbits/s) | 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1583 Figure 10: The Bandwidth-Status TLV 1585 Bandwidth-Status TLV Type: 1587 TLV (0x17) : indicating that this is a Bandwidth-Status TLV 1589 The committed amount SHOULD be less than or equal to the delegated 1590 amount. One case where this may not be so is if the procedure 1591 described in Section 4.10 has been performed and the NAS returned a 1592 delegated amount lower than the current committed amount. Another 1593 case might be if bandwidth delegation was activated after multicast 1594 bandwidth had been allocated by other means. Obviously such cases 1595 are exceptional and transient in nature. 1597 5.6. Multicast-Service-Profile-Name TLV 1599 [I-D.ietf-ancp-protocol] defines an Extension TLV that can be used in 1600 ANCP messages. It also defines a number of TLVs that can be included 1601 in the Extension TLV when present (with a Tech Type set to "DSL") in 1602 a Port Management message (e.g. "Access-Loop-Circuit-ID", "Service- 1603 Profile-Name"). 1605 This document defines an additional TLV that can appear in an 1606 Extension TLV of Tech Type "DSL" in a Port Management message: 1608 o Type (Multicast-Service-Profile-Name = 0x18): Reference to a 1609 multicast service profile on the AN, that defines a triple. 1612 Length : (up to 64 bytes) 1614 Value : ASCII string containing the multicast profile name. 1616 5.7. Request-Source-IP sub-TLV 1618 [I-D.ietf-ancp-protocol] defines the Command TLV that can be used in 1619 a Multicast Replication Control message and (as defined in this 1620 document) in the Admission Control message. The Command TLV MAY 1621 include sub-TLVs immediately following the Command Info field. 1623 This document defines the new Request-Source-IP sub-TLV. 1625 The Request-Source-IP sub-TLV MAY be included in a Command TLV inside 1626 an Admission Control message. 1628 The Request-Source-IP sub-TLV is illustrated below: 1630 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 1631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1632 |sub-TLV Type = Request-Source-IP | Request-S-IP sub-TLV Length | 1633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1634 | Addr Family | Encoding Type | Unicast Address | 1635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1637 Request-Source-IP sub-TLV Type: 1639 sub-TLV (0x92) indicating the contents to be a Request- 1640 Source-IP sub-TLV. 1642 Request-Source-IP sub-TLV Length: 1644 Combined length in bytes of the data inside sub-TLV. 1645 Excludes the sub-TLV Header. 1647 Address Family, Encoding type and Unicast Address: 1649 Contains the IP address of the sender of the join/leave 1650 message (e.g. IGMP/MLD Join/Leave) that triggered the AN 1651 to include the corresponding Command TLV in an Admission 1652 Control message. The IP address is encoded as per 1653 [IANAAEA]. 1655 5.8. Request-Source-MAC sub-TLV 1657 This document defines the new Request-Source-MAC sub-TLV. 1659 The Request-Source-MAC sub-TLV MAY be included in a Command TLV 1660 inside an Admission Control message. 1662 The Request-Source-MAC sub-TLV is illustrated below: 1664 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 1665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1666 |sub-TLV Type=Request-Source-MAC |Request-S-MAC sub-TLV Length | 1667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1668 | TBD | 1669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1671 Request-Source-MAC sub-TLV Type: 1673 sub-TLV (0x93) indicating the contents to be a Request- 1674 Source-MAC sub-TLV. 1676 Request-Source-MAC sub- TLV Length: 1678 Combined length in bytes of the data inside sub-TLV. 1679 Excludes the sub-TLV Header. 1681 TBD: 1683 Contains the IEEE MAC address of the sender of the join/ 1684 leave message (e.g. IGMP/MLD Join/Leave) that triggered 1685 the AN to include the corresponding Command TLV in an 1686 Admission Control message. The IP address is encoded as 1687 per TBD. 1689 5.9. Multicast-Flow TLV 1691 This document defines the new Multicast-Flow TLV. 1693 The Multicast-Flow TLV MAY be included in a Multicast Flow Query 1694 Request or Response message as specified in Section 4.9. 1696 The Multicast-Flow TLV is illustrated below: 1698 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 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 |TLV Type = Multicast-Flow | TLV Length | 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1702 | Addr Family | Encoding Type | Multicast Flow Source Address | 1703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1704 | Multicast Flow Source Address (Ctnd) ... | 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1706 | Addr Family | Encoding Type | Multicast Flow Group Address | 1707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1708 | Multicast Flow Group Address (Ctnd) ... | 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1710 | ... | Padding to 32-bit boundary | 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 The Multicast-Flow TLV 1715 Multicast-Flow TLV Type: 1717 TLV (0x19) : indicating that this is a Multicast-Flow TLV 1719 Multicast-Flow TLV Length: 1721 Length in bytes of the Value field of the TLV. Excludes 1722 the TLV Header (Type and Length). 1724 Addr Family, Encoding Type, Multicast Flow Source Address, Multicast 1725 Flow Group Address and Padding are encoded as specified for the 1726 corresponding field of the Command TLV in Section 4.3. 1728 6. New Capabilities 1730 [I-D.ietf-ancp-protocol] defines a capability negotiation mechanism 1731 as well as a number of capabilities. 1733 This document defines the following generic Multicast Capability Type 1734 allowing negotiation of the level of subcapability within the 1735 Multicast capability: 1737 o Capability Type : Multicast = 0x03 1739 Length (in bytes) : 1 1741 Capability Data (1 byte): The following values are defined: 1743 + 0x00: Reserved 1745 + 0x01: "Transactional Multicast" 1747 + 0x02: "Transactional Multicast" and "Multicast Admission 1748 Control without Bandwidth Delegation" 1750 + 0x03: "Transactional Multicast", "Multicast Admission 1751 Control without Bandwidth Delegation" and "Multicast 1752 Admission Control with Bandwidth Delegation" 1754 + other values: Reserved 1756 Both the NAS and the AN MUST advertise the Multicast capability in 1757 their originated adjacency messages when they support it. Initially, 1758 they indicate the full set of multicast subcapabilities that they 1759 respectively support by setting the Capability Value to the value 1760 corresponding to their respective supported set of subcapabilities. 1761 Then, if a received adjacency message indicates that the originating 1762 device supports a smaller set of multicast subcapabilities that the 1763 device receiving the message, the receiving device will turn off the 1764 multicast subcapabilities that are not supported by the other device 1765 and will send an updated adjacency message with an updated Capability 1766 Value that now matches the one of the other device. This process 1767 will eventually result in both sides agreeing on the common set of 1768 supported multicast subcapabilities. 1770 For example, if the NAS supports "Transactional Multicast" and 1771 "Multicast Admission Control without Bandwidth Delegation" while the 1772 AN only supports "Transactional Multicast", the NAS and AN will 1773 initially advertise the Multicast capability with a respective 1774 Capability Data of 0x02 and 0x01. On receipt of the adjacency 1775 message from the AN, the NAS will turn off its "Multicast Admission 1776 Control without Bandwidth Delegation" subcapability and will send a 1777 new adjacency message with a Multicast capability containing a 1778 Capability Data of 0x01. From there on, the NAS and AN agree to make 1779 use of (only) the "Transactional Multicast" subcapability. 1781 A NAS or AN supporting the "Transactional Multicast" subcapability 1782 MUST support the Multicast Replication message and the Multicast 1783 Status message. 1785 A NAS or AN supporting the "Transactional Multicast" and "Multicast 1786 Admission Control without Bandwidth Delegation" subcapabilities MUST 1787 support the Multicast Admission Control message, the Multicast 1788 Replication message and the Multicast Status message. 1790 A NAS or AN supporting the "Transactional Multicast", "Multicast 1791 Admission Control without Bandwidth Delegation" and "Multicast 1792 Admission Control with Bandwidth Delegation" capability MUST support 1793 the Multicast Admission Control message, the Multicast Replication 1794 message, the Multicast Status message, the Bandwidth Reallocation 1795 Request and Response messages, the Autonomous Bandwidth Transfer 1796 message and the Delegated Bandwidth Query Request and Response 1797 messages. 1799 7. Example of Messages and Message Flows 1801 This section provides example message flows. 1803 7.1. Multicast Conditional Access and CAC without AN Bandwidth 1804 Delegation 1806 This section describes ANCP operations when multicast flows are 1807 subject to multicast Conditional Access and Admission Control without 1808 Bandwidth Delegation. 1810 7.1.1. List/Profile Provisioning 1812 The AN provisioning is performed by NAS using a Provisioning message 1813 that contains White/Black/Grey lists and their corresponding 1814 "Multicast Service Profile Name". To indicate to the AN that it need 1815 not perform any CAC operation on those flows, the Provisioning 1816 message also conveys an indication that Bandwidth Delegation is to be 1817 deactivated. The corresponding message flow is illustrated in 1818 Figure 11. 1820 +----------+ +---------+ +-----+ +-----+ 1821 |Subscriber| | Home | | AN | | NAS | 1822 +----------+ | Gateway | +-----+ +-----+ 1823 | +---------+ | | 1824 | | | | 1825 | | |(M1) Provisioning | 1826 | | | (Mcast S Prof name, | 1827 | | | White List, | 1828 | | | Grey List, | 1829 | | | Black List, | 1830 | | | Bw Del Deactivated) | 1831 | | |<--------------------| 1833 Figure 11: Provisioning AN with White/Grey/Black Lists for 1834 Conditional Access 1836 The Provisioning message M1 contains: 1838 o an ANCP Header with: 1840 * Message-Type = 93 - Provisioning 1842 * Result= 0x00 1844 * Transaction-ID = Transaction-ID maintained by NAS 1846 o a Multicast-Service-Profile TLV containing: 1848 * a Multicast-Service-Profile-Name sub-TLV 1850 * an Empty White-List in our example (and hence no White-List 1851 sub-TLV) 1853 * a Grey-List sub-TLV containing a catch-all entry for IPv4 (in 1854 our example) 1856 * an Empty Black-List in our example (and hence no Black-List 1857 sub-TLV) 1859 The Provisioning message M1 is illustrated below: 1861 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 1862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1863 | Type (0x88-0C) | Length | 1864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1865 | Vers | Sub |MessageType=93 | 0x00 | Code | 1866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1867 | Partition ID | Transaction Identifier = 0008 | 1868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1869 |I| SubMessage Number | Length | 1870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1871 | Mcast-Service-Prof TLV Type | Mcast-Service-Prof TLV Length | 1872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1873 | sub-TLV Type = 0x0001 | sub-TLV Length | 1874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1875 | | 1876 ~ Multicast service profile name ~ 1877 | | 1878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1879 | sub-TLV Type = 0x0003 | sub-TLV Length = 0x06 | 1880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1881 | IP ver = 0x00 | List length = 0x02 | 1882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1883 | Grp PLen=0x00 | Src PLen=0x00 | 1884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1886 Figure 12 1888 7.1.2. Profile Mapping 1890 As soon as the AN port comes up, the AN sends an ANCP PORT_UP message 1891 to the NAS specifying the Access Loop Circuit ID. The NAS replies 1892 with an ANCP PORT_MNGT message that, together with the other 1893 parameters, includes the Multicast Service Profile Name to be 1894 associated to that Port. The corresponding message flow is 1895 illustrated in Figure 13. 1897 +----------+ +---------+ +-----+ +-----+ 1898 |Subscriber| | Home | | AN | | NAS | 1899 +----------+ | Gateway | +-----+ +-----+ 1900 | +---------+ | | 1901 | | | | 1902 | | | | 1903 | | DSL Synch. | | 1904 | |--------------------->| | 1905 | | |(M1)PORT_UP(Port ID) | 1906 | | |-------------------->| 1907 | | | (*) 1908 | | |(M2) PORT_MNGT | 1909 | | | (Port ID, | 1910 | | |Mcast S Profile Name)| 1911 | | |<--------------------| 1913 (*) The NAS may optionally seek direction from an external 1914 Autorization/Policy Server 1916 Figure 13: Associating Profile ID to AN Port 1918 7.1.3. Successful Join/Leave Operations 1920 The message flows in Figure 14 illustrates the ANCP message flow in 1921 case of a simple join and leave for a multicast flow that matches the 1922 grey list and when the "Bandwidth Delegation" mechanism is not 1923 activated in the AN. In that case the AN queries the NAS that 1924 performs Conditional Access and Admission Control. 1926 +----------+ +-------+ +-----+ ANCP +-----+ 1927 |Subscriber| | Home | | AN |<---------->| NAS | 1928 +----------+ |Gateway| +-----+ +-----+ 1929 | +-------+ | | 1930 | | | | 1931 | Join(Grey-Fl) | Admission | 1932 |-----------+---------->| Control (M1) | 1933 | | |------------------>| 1934 | | | | 1935 | | | Multicast | 1936 | | | Replication (*) 1937 | | | Control (M2) | 1938 | Mcast Grey Flow |<------------------| 1939 |<======================+ | 1940 | | | | 1941 ~ ~ ~ ~ 1942 | | | | 1943 | Leave(Grey-Fl) | Admission | 1944 |-----------+---------->| Control (M3) | 1945 | | |------------------>| 1946 | | | | 1948 Grey-Fl : Multicast Flow matching an entry in Grey List 1949 (Bandwidth Delegation not activated on AN) 1951 (*) The NAS may optionally seek direction from an external 1952 Autorization/Policy Server 1954 Figure 14: Successful Join/Leave Operations 1956 The Multicast Admission Control message M1 contains: 1958 o an ANCP Header with: 1960 * Message-Type = 92 - Multicast Admission Control 1962 * Result= 0x00 1964 * Transaction-ID = Transaction-ID maintained by AN 1966 o a Target TLV identifying the AN Port 1968 o a Command TLV containing: 1970 * a Command Code = Add 1971 * R = 0 1973 * O = 0 1975 * the multicast flow for which the IGMP Join was received by AN= 1976 (192.0.2.1, 233.252.2.2) 1978 * a Request-Source-IP sub-TLV containing the IGMP join source IP 1979 (192.0.2.100). 1981 The Multicast Admission Control message M1 is illustrated below: 1983 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 1984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1985 | Type (0x88-0C) | Length | 1986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1987 | Vers | Sub |MessageType=92 | 0x00 | Code | 1988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1989 | Partition ID | Transaction Identifier = 0001 | 1990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1991 |I| SubMessage Number | Length | 1992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1993 | Type = 0x1000 (Target) | Target TLV Length | 1994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1995 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 1996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1997 | | 1998 ~ Access Loop Circuit ID ~ 1999 | | 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2001 | Type = 0xTBD (Command) TLV | Command-TLV Length | 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2003 | Cmd Code=0x01 |0 0 1 | Command Length | 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2005 | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2007 | AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.2 | 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 2009 |Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length | 2010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2011 | AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 | 2012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 2014 The Multicast Replication Control message M2 contains: 2016 o an ANCP Header with: 2018 * Message-Type = 90 - Multicast Replication Control 2020 * Result= 0x00 2022 * Transaction-ID = Transaction-ID maintained by NAS 2024 o a Target TLV identifying the AN Port 2026 o a Command TLV containing: 2028 * a Command Code = Add 2030 * R= 1 (since in our example the flow resources have been 2031 admitted by NAS) 2033 * O = 0 (since in our example flow accounting is not required) 2035 * the multicast flow for which the IGMP Join was received by AN= 2036 (192.0.2.1, 233.252.2.2) 2038 * a Request-Source-IP sub-TLV containing the IGMP join source IP 2039 (192.0.2.100). 2041 The Multicast Admission Control message M2 is illustrated below: 2043 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 2044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2045 | Type (0x88-0C) | Length | 2046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2047 | Vers | Sub |MessageType=90 | 0x00 | Code | 2048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2049 | Partition ID | Transaction Identifier = 0009 | 2050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2051 |I| SubMessage Number | Length | 2052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2053 | Type = 0x1000 (Target) | Target TLV Length | 2054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2055 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 2056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2057 | | 2058 ~ Access Loop Circuit ID ~ 2059 | | 2060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2061 | Type = 0xTBD (Command) TLV | Command-TLV Length | 2062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2063 | Cmd Code=0x01 |1 0 1 | Command Length | 2064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2065 | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | 2066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2067 | AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.2 | 2068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 2069 |Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length | 2070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2071 | AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 | 2072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 2074 The Multicast Admission Control message M3 contains: 2076 o an ANCP Header with: 2078 * Message-Type = 92 - Multicast Admission Control 2080 * Result= 0x00 2082 * Transaction-ID = Transaction-ID maintained by AN 2084 o a Target TLV identifying the AN Port 2086 o a Command TLV containing: 2088 * a Command Code = Delete 2090 * R = 0 2092 * O = 0 2094 * the multicast flow for which the IGMP leave was received by AN= 2095 (192.0.2.1, 233.252.2.2) 2097 * a Request-Source-IP sub-TLV containing the IGMP join source IP 2098 (192.0.2.100). 2100 The Multicast Admission Control message M3 is illustrated below: 2102 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 2103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2104 | Type (0x88-0C) | Length | 2105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2106 | Vers | Sub |MessageType=92 | 0x00 | Code | 2107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2108 | Partition ID | Transaction Identifier = 0002 | 2109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2110 |I| SubMessage Number | Length | 2111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2112 | Type = 0x1000 (Target) | Target TLV Length | 2113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2114 | Access-Loop-Circuit-ID 0x0002 | Circuit-ID Length | 2115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2116 | | 2117 ~ Access Loop Circuit ID ~ 2118 | | 2119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2120 | Type = 0xTBD (Command) TLV | Command-TLV Length | 2121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2122 | Cmd Code=0x02 |0 0 1 | Command Length | 2123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2124 | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | 2125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2126 | AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.2 | 2127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 2128 |Type = 0xTBD (Request-S.) TLV | Request-S.-TLV Length | 2129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2130 |Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length | 2131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2132 | AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 | 2133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 2135 7.1.4. Admission Control Reject without NAS Response 2137 The message flow in Figure 15 illustrates the ANCP message flow in 2138 case of a join that is rejected by the NAS because of admission 2139 control and without explicit response from the NAS. In that case, 2140 the multicast flow is never replicated simply by virtue of the NAS 2141 not requesting replication. 2143 +----------+ +-------+ +-----+ ANCP +-----+ 2144 |Subscriber| | Home | | AN |<---------->| NAS | 2145 +----------+ |Gateway| +-----+ +-----+ 2146 | +-------+ | | 2147 | | | | 2148 | Join(Grey-Fl) | Admission | 2149 |-----------+---------->| Control (M1) | 2150 | | |------------------>| 2151 | | | | 2152 | | | (*) 2153 | | | | 2154 | Mcast Grey Flow | | 2155 | not replicated x | 2156 | | | | 2158 Grey-Fl : Multicast Flow matching an entry in Grey List 2159 (Bandwidth Delegation not activated on AN) 2161 (*) The NAS may optionally seek direction from an external 2162 Autorization/Policy Server 2164 Figure 15: Admission Control Reject without NAS Response 2166 The Multicast Admission Control message M1 contains: 2168 o an ANCP Header with: 2170 * Message-Type = 92 - Multicast Admission Control 2172 * Result= 0x00 2174 * Transaction-ID = Transaction-ID maintained by AN 2176 o a Target TLV identifying the AN Port 2178 o a Command TLV containing: 2180 * a Command Code = Add 2182 * R = 0 2184 * O = 0 2186 * the multicast flow for which the IGMP join was received by AN= 2187 (192.0.2.1, 233.252.2.3). 2189 * a Request-Source-IP sub-TLV containing the IGMP join source IP 2190 (192.0.2.100). 2192 The Multicast Admission Control message M1 is illustrated below: 2194 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 2195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2196 | Type (0x88-0C) | Length | 2197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2198 | Vers | Sub |MessageType=92 | 0x00 | Code | 2199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2200 | Partition ID | Transaction Identifier = 0003 | 2201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2202 |I| SubMessage Number | Length | 2203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2204 | Type = 0x1000 (Target) | Target TLV Length | 2205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2206 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 2207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2208 | | 2209 ~ Access Loop Circuit ID ~ 2210 | | 2211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2212 | Type = 0xTBD (Command) TLV | Command-TLV Length | 2213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2214 | Cmd Code=0x01 |0 0 1 | Command Length | 2215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2216 | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | 2217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2218 | AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.3 | 2219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 2220 |Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length | 2221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2222 | AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 | 2223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 2225 7.1.5. Admission Control Reject with NAS Response 2227 The message flow in Figure 16 illustrates the ANCP message flow in 2228 case of a join that is rejected by the NAS because of admission 2229 control and with explicit response from the NAS. In that case, the 2230 multicast flow is not replicated by virtue of the NAS explicitely 2231 signaling to the AN that the multicast flow is not to be replicated. 2233 +----------+ +-------+ +-----+ ANCP +-----+ 2234 |Subscriber| | Home | | AN |<---------->| NAS | 2235 +----------+ |Gateway| +-----+ +-----+ 2236 | +-------+ | | 2237 | | | | 2238 | Join(Grey-Fl) | Admission | 2239 |-----------+---------->| Control (M1) | 2240 | | |------------------>| 2241 | | | | 2242 | | | Multicast (*) 2243 | | | Replication | 2244 | | | Control (M2) | 2245 | Mcast Grey Flow |<------------------| 2246 | not replicated x | 2247 | | | | 2249 Grey-Fl : Multicast Flow matching an entry in Grey List 2250 (Bandwidth Delegation not activated on AN) 2252 (*) The NAS may optionally seek direction from an external 2253 Autorization/Policy Server 2255 Figure 16: Admission Control Reject with NAS Response 2257 The Multicast Admission Control message M1 contains: 2259 o an ANCP Header with: 2261 * Message-Type = 92 - Multicast Admission Control 2263 * Result= 0x00 2265 * Transaction-ID = Transaction-ID maintained by AN 2267 o a Target TLV identifying the AN Port 2269 o a Command TLV containing: 2271 * a Command Code = Add 2273 * R = 0 2275 * O = 0 2277 * the multicast flow for which the IGMP join was received by AN= 2278 (192.0.2.1, 233.252.2.4). 2280 * a Request-Source-IP sub-TLV containing the IGMP join source IP 2281 (192.0.2.100). 2283 The Multicast Admission Control message M1 is illustrated below: 2285 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 2286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2287 | Type (0x88-0C) | Length | 2288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2289 | Vers | Sub |MessageType=92 | 0x00 | Code | 2290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2291 | Partition ID | Transaction Identifier = 0004 | 2292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2293 |I| SubMessage Number | Length | 2294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2295 | Type = 0x1000 (Target) | Target TLV Length | 2296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2297 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 2298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2299 | | 2300 ~ Access Loop Circuit ID ~ 2301 | | 2302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2303 | Type = 0xTBD (Command) TLV | Command-TLV Length | 2304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2305 | Cmd Code=0x01 |0 0 1 | Command Length | 2306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2307 | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | 2308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2309 | AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.4 | 2310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 2311 |Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length | 2312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2313 | AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 | 2314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 2316 The Multicast Replication Control message M2 contains: 2318 o an ANCP Header with: 2320 * Message-Type = 90 - Multicast Replication Control 2322 * Result= 0x00 2324 * Transaction-ID = Transaction-ID maintained by NAS 2326 o a Target TLV identifying the AN Port 2328 o a Command TLV containing: 2330 * a Command Code = Admission Control Reject (since in our example 2331 the flow is rejected by NAS because of bandwidth admission 2332 control and not because of conditional access) 2334 * R= 0 (since in our example the flow resources have not been 2335 admitted by NAS) 2337 * O = 0 (since in our example flow accounting is not required) 2339 * the multicast flow (192.0.2.1, 233.252.2.4) 2341 * a Request-Source-IP sub-TLV containing the IGMP join source IP 2342 (192.0.2.100). 2344 The Multicast Admission Control message M2 is illustrated below: 2346 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 2347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2348 | Type (0x88-0C) | Length | 2349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2350 | Vers | Sub |MessageType=90 | 0x00 | Code | 2351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2352 | Partition ID | Transaction Identifier = 0010 | 2353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2354 |I| SubMessage Number | Length | 2355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2356 | Type = 0x1000 (Target) | Target TLV Length | 2357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2358 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 2359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2360 | | 2361 ~ Access Loop Circuit ID ~ 2362 | | 2363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2364 | Type = 0xTBD (Command) TLV | Command-TLV Length | 2365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2366 | Cmd Code=0xTBD|0 0 1 | Command Length | 2367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2368 | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | 2369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2370 | AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.4 | 2371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 2372 |Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length | 2373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2374 | AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 | 2375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 2377 7.2. Example Flows For Bandwidth Delegation 2379 As noted in Section 5.1.1, the operation of bandwidth delegation is 2380 supplemental to the operation of request processing in the absence of 2381 bandwidth delegation. Thus the same flows shown in the previous 2382 section continue to hold, except that the AN does multicast call 2383 admission before doing grey and white list processing. The example 2384 flows of this section are therefore limited to the incremental 2385 operations of bandwidth delegation. They include initial 2386 provisioning, a successful request from the AN for an increase in 2387 delegated bandwidth, an autonomous transfer of the borrowed bandwidth 2388 back to the NAS, and the initiation of the bandwidth reset procedure 2389 (Section 4.10) by the NAS when it finds that the amount of delegated 2390 bandwidth passed by the AN is larger than its current view of that 2391 amount. 2393 7.2.1. Activation and Provisioning of Delegated Bandwidth 2395 Activation of bandwidth delegation occurs at the level of the AN as a 2396 whole and is done by including a Bandwidth-Delegation-Control TLV in 2397 the Provisioning message with the E-flag set to 1. The message flow 2398 is as shown in Figure 11. In place of Figure 12 we have the 2399 following content within the Provisioning message: 2401 1 2 3 2402 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 2403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2404 | Type (0x88-0C) | Length | 2405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2406 | Vers | Sub |MessageType=93 | 0x00 | Code | 2407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2408 | Partition ID | Transaction Identifier = 0008 | 2409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2410 |I| SubMessage Number | Length | 2411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2412 | Mcast-Service-Prof TLV Type | Mcast-Service-Prof TLV Length | 2413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2414 | sub-TLV Type = 0x0001 | sub-TLV Length | 2415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2416 | | 2417 ~ Multicast service profile name ~ 2418 | | 2419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2420 | sub-TLV Type = 0x0003 | sub-TLV Length = 0x06 | 2421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2422 | IP ver = 0x00 | List length = 0x02 | 2423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2424 | Grp PLen=0x00 | Src PLen=0x00 | Padding = 0x00 | 2425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2426 | TLV Type = Band-Del-Control | TLV Length = 0x04 | 2427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2428 |E| Reserved = 0x00 | Reserved = 0x00 | 2429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2431 Figure 17 2433 Once bandwidth delegation has been activated, the NAS must provision 2434 the amount of delegated bandwidth for each access line (unless it is 2435 pre-configured on the AN). This requires a Port Management message 2436 with a Bandwidth-Allocation TLV. The same Port Management message 2437 may be used to provision other information, such as the multicast 2438 service profile name applicable to the access line. The information 2439 flow is therefore similar to that in Figure 13. In the following 2440 figure, an initial allocation of 8000 kbits/s is provided. 2442 0 1 2 3 2443 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 2444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2445 | Vers | Sub | Msg Type = 32 |Rslt =1| Code = 0 | 2446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2447 | Partition ID | Transaction Identifier | 2448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2449 |I| SubMessage Number | Length | 2450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2451 | Port = 0 | 2452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2453 | Port Session Number | 2454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2455 | Event Sequence Number | 2456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2457 |R|x|x|x|x|x|x|x| Duration | Func = 8 | X-Func = 0 | 2458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2459 | Event Flags | Flow Control Flags | 2460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2461 |x|x|x|x|x|x|x|x| Msg Type = 32 | Tech Type = 5 | Block Len = 0 | 2462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2463 | # of TLVs = 2 | Ext Block length | 2464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2465 | TLV Type = 0x01 | Access-Loop-Cct-ID length | 2466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2467 | | 2468 ~ Access-Loop-Circuit-ID ~ 2469 | | 2470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2471 | TLV Type = Bandwidth-Alloc | TLV length = 4 | 2472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2473 | Delegated amount = 8000 | 2474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2476 Figure 18: Port Management Message Allocating Delegated Bandwidth 2478 7.2.2. Successful Request For More Delegated Bandwidth 2480 Suppose that the AN allocates all 8000 kbits/s of its delegated 2481 amount and receives a Join request requiring another 2000 kbits/s. 2482 The AN issues a Bandwidth Reallocation Request message where the 2483 required amount field is set to acquire this amount of additional 2484 bandwidth. Since the request is framed in terms of total delegated 2485 bandwidth, required amount is 10000 kbits/s. Suppose that the AN is 2486 configured with a policy that causes it to request enough for one 2487 additional channel as a preferred amount. Hence the preferred amount 2488 is set to 12000 kbits/s. The Bandwidth Reallocation Request message 2489 has the following format: 2491 0 1 2 3 2492 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 2493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2494 | Vers | Sub | MsgTyp = 94 |Rslt=0 | Code = 0 | 2495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2496 | Partition ID | Transaction Identifier | 2497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2498 |I| SubMessage Number | Length | 2499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2500 | TLV Type = Target | Target-TLV Length | 2501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2502 | Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length | 2503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2504 | | 2505 ~ Access Loop Circuit ID ~ 2506 | | 2507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2508 |TLV Type = Bandwidth-Request | TLV Length = 8 | 2509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2510 | Required amount = 10000 | 2511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2512 | Preferred amount = 12000 | 2513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2515 Figure 19: Example Bandwidth Reallocation Request Message 2517 In response to this request, the NAS is willing to grant the full 2518 preferred amount. (It could have granted any value between 10000 and 2519 12000, or it could have rejected the request.) The Bandwidth 2520 Transfer message sent as a response indicates that the new delegated 2521 bandwidth amount is 12000 kbits/s, as shown in the next figure. 2523 0 1 2 3 2524 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 2525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2526 | Vers | Sub | MsgTyp = 95 |Rslt=3 | Code = 0 | 2527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2528 | Partition ID | Transaction Identifier | 2529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2530 |I| SubMessage Number | Length | 2531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2532 | TLV Type = Target | Target-TLV Length | 2533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2534 | Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length | 2535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2536 | | 2537 ~ Access Loop Circuit ID ~ 2538 | | 2539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2540 |TLV Type = Bandwidth-Alloc | TLV Length = 4 | 2541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2542 | Delegated amount = 12000 | 2543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2545 Figure 20: Example Bandwidth Transfer Message (Success Response) 2547 7.2.3. Failed Autonomous Transfer With Reset 2549 Suppose the AN decides after an interval that it should return 2000 2550 kbits/s of the 4000 kbits/s that it acquired from the NAS in the 2551 previous transaction. It therefore issues a Bandwidth Transfer 2552 message of its own. This message differs from the message in 2553 Figure 20 in two ways. First, because this is an autonomous transfer 2554 rather than a response, the Result field in the header is set to 2555 Ignore (0x0). Secondly, the Delegated amount is reduced to 10000 2556 kbits/s. 2558 Now suppose that somehow the NAS forgot that it passed an additional 2559 4000 kbits/s to the AN. Thus its current view of the amount of 2560 delegated bandwidth is 8000 kbits/s. The 10000 kbits/s appearing in 2561 the Bandwidth Transfer message is higher than this, so there is 2562 clearly a disgareement between the NAS and the AN. The NAS chooses 2563 to initiate the reset procedure, perhaps because it is close to 2564 committing all of its available video bandwidth for unicast service. 2565 As the initial step in this procedure, it issues a Multicast Status 2566 message indicating that a reset of the delegated amount is required. 2567 This is shown in the following figure. 2569 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 2570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2571 | Type (0x88-0C) | Length | 2572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2573 | Vers | Sub |MessageType=91 | 0x4 | Code = 0 | 2574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2575 | Partition ID | Transaction Identifier | 2576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2577 |I| SubMessage Number | Length | 2578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2579 | Status-info-TLV=TBD | Status-TLV-Length | 2580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2581 |Rslt Code = xx | Cmd No = 1 | Error Message Length | 2582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2583 | Error Message (padded to 4) if Length > 0 | 2584 +---------------------------------------------------------------+ 2585 | TLV Type = Target | Target-TLV Length | 2586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2587 | Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length | 2588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2589 | | 2590 ~ Access Loop Circuit ID ~ 2591 | | 2592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2593 |TLV Type = Bandwidth-Alloc | TLV Length = 4 | 2594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2595 | Delegated amount = 8000 | 2596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2598 The Result Code field within the Status-Info TLV contains the value: 2599 delegated bandwidth reset required (0xTBD). 2601 Figure 21: Example Initiation of Delegated Bandwidth Reset 2603 The NAS stops processing video service requests for the given access 2604 line when it sends this message. Similarly, the AN stops processing 2605 multicast video service requests when it receives the message. [To 2606 think about: can service requests that release bandwidth be safely 2607 processed? Probably.] The next step is up to the NAS: it sends a 2608 Bandwidth Delegation Query Request message to the AN. The Result 2609 field in the header is set to Ignore (0x0) as usual for multicast- 2610 related messages. The Target TLV is a copy of the one received in 2611 the original Bandwidth Transfer message. The message is shown in the 2612 following figure: 2614 0 1 2 3 2615 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 2616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2617 | Vers | Sub | MsgTyp = 96 |Rslt=0 | Code = 0 | 2618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2619 | Partition ID | Transaction Identifier | 2620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2621 |I| SubMessage Number | Length | 2622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2623 | TLV Type = Target | Target-TLV Length | 2624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2625 | Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length | 2626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2627 | | 2628 ~ Access Loop Circuit ID ~ 2629 | | 2630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2632 Figure 22: Example Delegated Bandwidth Query Request Message 2634 The AN returns a Delegated Bandwidth Query Response message showing 2635 that it believes that the amount of delegated bandwidth is 10000 2636 kbits/s and it has committed 8000 kbits/s of it. The Result field in 2637 the header shows Success (0x3) to distinguish the response. [... in 2638 case we decide to make the query bidirectional ...] 2639 0 1 2 3 2640 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 2641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2642 | Vers | Sub | MsgTyp = 96 |Rslt=3 | Code = 0 | 2643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2644 | Partition ID | Transaction Identifier | 2645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2646 |I| SubMessage Number | Length | 2647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2648 | TLV Type = Target | Target-TLV Length | 2649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2650 | Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length | 2651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2652 | | 2653 ~ Access Loop Circuit ID ~ 2654 | | 2655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2656 |TLV Type = Bandwidth-Request | TLV Length = 8 | 2657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2658 | Delegated amount = 10000 | 2659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2660 | Committed amount = 8000 | 2661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2663 Figure 23: Example Delegated Bandwidth Query Response Message 2665 The NAS decides to reset the delegated bandwidth amount to 8000 2666 kbits/s. It issues a Port Management message looking exactly like 2667 the one in Figure 18. Once it sends this message, it resumes 2668 processing service requests for the access line concerned. 2669 Similarly, the AN resumes request processing after it receives the 2670 Port Management message and resets its view of the current delegated 2671 bandwidth. In the short run, this means that it will have to ask for 2672 more bandwidth if it receives another Join request. [It seems 2673 reasonable that the AN would not do so for a period of time after a 2674 reset or a response to a Bandwidth Reallocation Request that grants 2675 less than the preferred amount. Should we establish a timer?] 2677 7.3. Example Flows For Multicast Flow Reporting 2679 7.3.1. Per Port Multicast Flow Reporting 2681 Figure 24 illustrate a message flow in the case where the NAS queries 2682 the AN about which multicast flow is active on port 10, on port 20 2683 and on port 11 of the AN. 2685 +----------+ +-------+ +-----+ ANCP +-----+ 2686 |Subscriber| | Home | | AN |<---------->| NAS | 2687 +----------+ |Gateway| +-----+ +-----+ 2688 | +-------+ | | 2689 | | | Multicast Flow | 2690 | | | Query Request | 2691 | | | (M1) | 2692 | | |<------------------| 2693 | | | | 2694 | | | Multicast Flow | 2695 | | | Query Response | 2696 | | | (M2) | 2697 | | |------------------>| 2698 | | | | 2699 | | | | 2701 Figure 24: Per Port Multicast Flow Reporting 2703 The Multicast Flow Query Request message (M1) is illustrated in 2704 Figure 25. 2706 0 1 2 3 2707 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 2708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2709 | Vers | Sub | Msg Type = 97 |Rslt=00| Code = 0 | 2710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2711 | Partition ID | Transaction Identifier | 2712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2713 |I| SubMessage Number | Length | 2714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2715 | Type = 0x1000 (Target) | Target TLV Length | 2716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2717 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 2718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2719 | | 2720 ~ Access Loop Circuit ID (port10) ~ 2721 | | 2722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2723 | Type = 0x1000 (Target) | Target TLV Length | 2724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2725 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 2726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2727 | | 2728 ~ Access Loop Circuit ID (port20) ~ 2729 | | 2730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2731 | Type = 0x1000 (Target) | Target TLV Length | 2732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2733 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 2734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2735 | | 2736 ~ Access Loop Circuit ID (port11) ~ 2737 | | 2738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2740 Figure 25: Multicast Flow Query Request message for per-port Mulicast 2741 Flow Reporting 2743 The Multicast Flow Query Response message (M2) is illustrated in 2744 Figure 26. It indicates that there is one active multicast flow 2745 [(192.0.2.1, 233.252.2.4)] on port 10, no active multicast flow on 2746 port 20 and two active multicast flows [(192.0.2.1, 233.252.2.4) and 2747 (192.0.2.2, 233.252.2.10)] on port 11. 2749 0 1 2 3 2750 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 2751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2752 | Vers | Sub | Msg Type = 97 |Rslt=00| Code = 0 | 2753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2754 | Partition ID | Transaction Identifier | 2755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2756 |I| SubMessage Number | Length | 2757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2758 | Type = 0x1000 (Target) | Target TLV Length | 2759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2760 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 2761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2762 | | 2763 ~ Access Loop Circuit ID (port10) ~ 2764 | | 2765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2766 |Type=0x19 (Multicast-Flow) TLV | Multicast Flow-TLV Length | 2767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2768 | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | 2769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2770 | AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.4 | 2771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 2772 | Type = 0x1000 (Target) | Target TLV Length | 2773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2774 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 2775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2776 | | 2777 ~ Access Loop Circuit ID (port20) ~ 2778 | | 2779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2780 | Type = 0x1000 (Target) | Target TLV Length | 2781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2782 | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | 2783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2784 | | 2785 ~ Access Loop Circuit ID (port11) ~ 2786 | | 2787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2788 |Type=0x19 (Multicast-Flow) TLV | Multicast Flow-TLV Length | 2789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2790 | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | 2791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2792 | AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.4 | 2793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 2794 |Type=0x19 (Multicast-Flow) TLV | Multicast Flow-TLV Length | 2795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2796 | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.2 | 2797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2798 | AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.10 | 2799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ 2800 Figure 26: Multicast Flow Query Response message for per-port 2801 Mulicast Flow Reporting 2803 8. Security Considerations 2805 The security considerations of ANCP are discussed in 2806 [I-D.ietf-ancp-protocol] and in [I-D.ietf-ancp-security-threats]. 2808 9. IANA Considerations 2810 This document defines the following additional values within the 2811 GSMPv3 Message Type Name Space registry: 2813 +--------------------------------+--------+---------------+ 2814 | Message | Number | Source | 2815 +--------------------------------+--------+---------------+ 2816 | Multicast Replication Control | 90 | This document | 2817 | | | | 2818 | Multicast Status | 91 | This document | 2819 | | | | 2820 | Multicast Admission Control | 92 | This document | 2821 | | | | 2822 | Bandwidth Reallocation Request | 94 | This document | 2823 | | | | 2824 | Bandwidth Transfer | 95 | This document | 2825 | | | | 2826 | Delegated Bandwidth Query | 96 | This document | 2827 | | | | 2828 | Multicast Flow Query | 97 | This document | 2829 +--------------------------------+--------+---------------+ 2831 This document defines the following values for the ANCP Status-Info 2832 Result Code Registry : 2834 +----------------------------------------------+--------+-----------+ 2835 | Status | Number | Reference | 2836 +----------------------------------------------+--------+-----------+ 2837 | Command not supported | 0x02 | This | 2838 | | | document | 2839 | | | | 2840 | Flag set but not supported | 0x03 | This | 2841 | | | document | 2842 | | | | 2843 | Unsupported Address Family | 0x05 | This | 2844 | | | document | 2845 | | | | 2846 | Malformed flow address | 0x06 | This | 2847 | | | document | 2848 | | | | 2849 | Configuration error (such as Port not | 0x0a | This | 2850 | enabled for multicast) | | document | 2851 | | | | 2852 | Multicast flow does not exist | 0x0b | This | 2853 | | | document | 2854 | | | | 2855 | Unsupported address encoding | 0x0c | This | 2856 | | | document | 2857 | | | | 2858 | Additional info needed to execute command | 0x0d | This | 2859 | (payload MAY contain an indication of the | | document | 2860 | expected info) | | | 2861 | | | | 2862 | Multicast flow count exceeded | 0x0e | This | 2863 | | | document | 2864 | | | | 2865 | M Flag set, but no IP Source address | 0x0f | This | 2866 | provided | | document | 2867 | | | | 2868 | Invalid preferred bandwidth amount | 0x11 | This | 2869 | | | document | 2870 | | | | 2871 | Bandwidth delegation not activated | 0x12 | This | 2872 | | | document | 2873 | | | | 2874 | Delegated bandwidth reset required | 0x13 | This | 2875 | | | document | 2876 +----------------------------------------------+--------+-----------+ 2878 This document defines the following additional values within the ANCP 2879 TLV Type Registry: 2881 +--------------------------------+-----------+---------------+ 2882 | TLV Name | Type Code | Reference | 2883 +--------------------------------+-----------+---------------+ 2884 | Multicast-Service-Profile | 0x13 | This document | 2885 | | | | 2886 | Bandwidth-Delegation-Control | 0x14 | This document | 2887 | | | | 2888 | Bandwidth-Allocation | 0x15 | This document | 2889 | | | | 2890 | Bandwidth-Request | 0x16 | This document | 2891 | | | | 2892 | Bandwidth-Status | 0x17 | This document | 2893 | | | | 2894 | Multicast-Service-Profile-Name | 0x18 | This document | 2895 | | | | 2896 | Multicast-Flow | 0x19 | This document | 2897 +--------------------------------+-----------+---------------+ 2899 This document defines the following values for the ANCP Command Code 2900 registry: 2902 +-------------------------------------+----------------+------------+ 2903 | Command Code Directive Name | Command Code | Reference | 2904 | | Value | | 2905 +-------------------------------------+----------------+------------+ 2906 | Add | 0x01 | This | 2907 | | | document | 2908 | | | | 2909 | Delete | 0x02 | This | 2910 | | | document | 2911 | | | | 2912 | Delete All | 0x03 | This | 2913 | | | document | 2914 | | | | 2915 | Admission Control Reject | 0x04 | This | 2916 | | | document | 2917 | | | | 2918 | Conditional Access Reject | 0x05 | This | 2919 | | | document | 2920 | | | | 2921 | Admission Control and Conditional | 0x06 | This | 2922 | Access Reject | | document | 2923 +-------------------------------------+----------------+------------+ 2925 This document defines the following additional values to the ANCP 2926 sub-TLV Type registry: 2928 +--------------------+-----------+---------------+ 2929 | sub-TLV Name | Type Code | Reference | 2930 +--------------------+-----------+---------------+ 2931 | Request-Source-IP | 0x92 | This document | 2932 | | | | 2933 | Request-Source-MAC | 0x93 | This document | 2934 +--------------------+-----------+---------------+ 2936 10. Acknowledgements 2938 The authors would like to acknowledge Wojciech Dec for providing 2939 useful input to this document, Robert Rennison for his help in 2940 shaping the definition of the Multicast-Service-Profile TLV, Shridhar 2941 Rao for his comments and suggestions and Aniruddha A for his proposal 2942 that formed the base of the Multicast Flow Reporting solution. 2943 Philippe Champagne, Sanjay Wadhwa and Stefaan De Cnodder provided 2944 substantial contributions on the solution for the NAS initiated 2945 multicast control use case. 2947 11. References 2949 11.1. Normative References 2951 [I-D.ietf-ancp-framework] 2952 Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. 2953 Wadhwa, "Framework and Requirements for an Access Node 2954 Control Mechanism in Broadband Multi-Service Networks", 2955 draft-ietf-ancp-framework-10 (work in progress), May 2009. 2957 [I-D.ietf-ancp-protocol] 2958 Wadhwa, S., Moisand, J., Subramanian, S., Haag, T., Voigt, 2959 N., and R. Maglione, "Protocol for Access Node Control 2960 Mechanism in Broadband Networks", 2961 draft-ietf-ancp-protocol-05 (work in progress), 2962 March 2009. 2964 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2965 Requirement Levels", BCP 14, RFC 2119, March 1997. 2967 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 2968 Listener Discovery (MLD) for IPv6", RFC 2710, 2969 October 1999. 2971 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 2972 Thyagarajan, "Internet Group Management Protocol, Version 2973 3", RFC 3376, October 2002. 2975 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 2976 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 2978 11.2. Informative References 2980 [I-D.ietf-ancp-security-threats] 2981 Moustafa, H., Tschofenig, H., and S. Cnodder, "Security 2982 Threats and Security Requirements for the Access Node 2983 Control Protocol (ANCP)", 2984 draft-ietf-ancp-security-threats-07 (work in progress), 2985 March 2009. 2987 [I-D.morin-mboned-igmpmld-error-feedback] 2988 Morin, T. and B. Haberman, "IGMP/MLD Error Feedback", 2989 draft-morin-mboned-igmpmld-error-feedback-02 (work in 2990 progress), November 2008. 2992 [IANAAEA] "http://www.iana.org/assignments/address-family-numbers", 2993 2005. 2995 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 2996 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 2997 Protocol Specification (Revised)", RFC 4601, August 2006. 2999 Authors' Addresses 3001 Francois Le Faucheur 3002 Cisco Systems 3003 Greenside, 400 Avenue de Roumanille 3004 Sophia Antipolis 06410 3005 France 3007 Phone: +33 4 97 23 26 19 3008 Email: flefauch@cisco.com 3010 Roberta Maglione 3011 Telecom Italia 3012 Via Reiss Romoli 274 3013 Torino 10148 3014 Italy 3016 Phone: 3017 Email: roberta.maglione@telecomitalia.it 3019 Tom Taylor 3020 Huawei Technologies 3021 1852 Lorraine Ave 3022 Ottawa, Ontario K1H 6Z8 3023 Canada 3025 Phone: +1 613 680 2675 3026 Email: tom.taylor@rogers.com