idnits 2.17.00 (12 Aug 2021) /tmp/idnits31205/draft-maglione-ancp-mcast-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1314. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1325. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1332. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1338. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 1210 has weird spacing: '...tion of x ...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 11, 2008) is 5055 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 1240, but no explicit reference was found in the text == Unused Reference: 'RFC3292' is defined on line 1243, but no explicit reference was found in the text == Outdated reference: draft-ietf-ancp-framework has been published as RFC 5851 ** Downref: Normative reference to an Informational draft: draft-ietf-ancp-framework (ref. 'I-D.ietf-ancp-framework') == Outdated reference: draft-ietf-ancp-protocol has been published as RFC 6320 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANCP R. Maglione 3 Internet-Draft A. Garofalo 4 Intended status: Standards Track Telecom Italia 5 Expires: January 12, 2009 F. Le Faucheur 6 T. Eckert 7 Cisco 8 T. Taylor 9 Huawei 10 July 11, 2008 12 ANCP Multicast Handling Sessions 13 draft-maglione-ancp-mcast-01.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on January 12, 2009. 40 Abstract 42 This memorandum aims at presenting ANCP Multicast handling. It 43 proposes updated description of the Multicast Use cases and 44 corresponding updated ANCP requirements. It also presents the 45 corresponding Message Flows. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 51 3. Multicast Use Cases . . . . . . . . . . . . . . . . . . . . . 8 52 3.1. Conditional Access . . . . . . . . . . . . . . . . . . . . 8 53 3.2. Multicast Admission Control . . . . . . . . . . . . . . . 9 54 3.2.1. When not to perform Admission Control for a subset 55 of flows . . . . . . . . . . . . . . . . . . . . . . . 12 56 3.2.2. Multicast Admission Control and White Lists . . . . . 12 57 3.3. Multicast Accounting and Reporting . . . . . . . . . . . . 12 58 3.4. Spontaneous Admission Response . . . . . . . . . . . . . . 12 59 4. Multicast Protocol Requirements . . . . . . . . . . . . . . . 13 60 4.1. ANCP Multicast Requirements . . . . . . . . . . . . . . . 13 61 4.2. ANCP Access Node Multicast Requirements . . . . . . . . . 13 62 4.3. ANCP NAS Multicast Requirements . . . . . . . . . . . . . 15 63 5. Message Flows . . . . . . . . . . . . . . . . . . . . . . . . 17 64 5.1. Multicast Conditional Access without CAC . . . . . . . . . 17 65 5.1.1. List/Profile Provisioning . . . . . . . . . . . . . . 17 66 5.1.2. Profile Mapping . . . . . . . . . . . . . . . . . . . 18 67 5.1.3. Join & Leave Operations . . . . . . . . . . . . . . . 18 68 5.2. Multicast Conditional Access and CAC without AN 69 Bandwidth Delegation . . . . . . . . . . . . . . . . . . . 20 70 5.2.1. List/Profile Provisioning . . . . . . . . . . . . . . 20 71 5.2.2. Profile Mapping . . . . . . . . . . . . . . . . . . . 20 72 5.2.3. Join & Leave Operations . . . . . . . . . . . . . . . 20 73 5.3. Multicast Admission Control with AN Bandwidth 74 Delegation . . . . . . . . . . . . . . . . . . . . . . . . 21 75 5.3.1. List/Profile Provisioning . . . . . . . . . . . . . . 21 76 5.3.2. Profile Mapping and Initial Bandwidth Delegation . . . 22 77 5.3.3. Join & Leave Operations . . . . . . . . . . . . . . . 23 78 5.3.4. AN-Triggered Increase of Delegated Multicast 79 Bandwidth . . . . . . . . . . . . . . . . . . . . . . 25 80 5.3.5. NAS-Triggered Decrease of Delegated Multicast 81 Bandwidth . . . . . . . . . . . . . . . . . . . . . . 26 82 5.3.6. AN Release of Redundant Multicast Bandwidth . . . . . 26 83 5.4. Multicast Accounting . . . . . . . . . . . . . . . . . . . 27 84 5.4.1. List/Profile Provisioning . . . . . . . . . . . . . . 27 85 5.4.2. Profile Mapping . . . . . . . . . . . . . . . . . . . 28 86 5.4.3. Join & Leave Operations . . . . . . . . . . . . . . . 28 87 5.5. Multicast Reporting . . . . . . . . . . . . . . . . . . . 30 88 5.6. NAS-Controlled Multicast Replication . . . . . . . . . . . 30 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 32 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 91 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 93 9.1. Normative References . . . . . . . . . . . . . . . . . . . 35 94 9.2. Informative References . . . . . . . . . . . . . . . . . . 35 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 97 Intellectual Property and Copyright Statements . . . . . . . . . . 38 99 1. Introduction 101 [I-D.ietf-ancp-framework] defines a framework and requirements for an 102 Access Node Control Mechanism between a Network Access Server (NAS) 103 and an Access Node (e.g. a Digital Subscriber Line Access Multiplexer 104 (DSLAM)) in a multi-service reference architecture in order to 105 perform QoS-related, service-related and Subscriber-related 106 operations. [I-D.ietf-ancp-protocol] specifies a Protocol for Access 107 Node Control Mechanism in Broadband Networks in line with this 108 framework. 110 [I-D.ietf-ancp-framework] defines multicast use cases (in section 111 3.4) as well as the corresponding ANCP Multicast requirements, ANCP 112 Access Node Multicast Requirements and ANCP NAS Multicast 113 Requirements (respectively in sections 4.2, 4.7.7 and 4.8.6). The 114 multicast use cases addressed are "Conditional Access", "Admission 115 Control", "Accounting and Reporting", and finally "Spontaneous 116 Admission Response". The ANCP requirements associated with the 117 Admission Control use case support a number of models. One such 118 model is where ANCP allows Admission Control to be performed without 119 involvement of the Access Node i.e performed by the NAS (possibly 120 with interactions with a Policy Server). Another model is where 121 Admission Control is to be performed with some involvement of the 122 Access Node i.e. performed by NAS (possibly with interactions with a 123 Policy Server) but this time with some delegation of decision to the 124 Access Node. 126 This memorandum proposes some enhancements to the ANCP operations for 127 the model where some admission control decision is delegated to the 128 Access Node. The key enhancement is to explicitely delegate 129 multicast bandwidth to the Access Node for the purpose of multicast 130 admission control (instead of simply identifying multicast flows that 131 share the same admission control rules and access control rules, as 132 per current version of[I-D.ietf-ancp-framework]). This allows the 133 Access Node to perform admission control without ANCP signaling with 134 the NAS in more situations than the current proposal. 136 With this bandwidth delegation approach the AN manages a delegated 137 multicast bandwidth that is a subset of the total video bandwidth for 138 an AN port. The AN can autonomously perform admission control of 139 multicast flows within this delegated bandwidth. An initial value 140 for the delegated multicast bandwidth can be provisioned on the AN by 141 the NAS through ANCP. The AN and NAS then communicate via ANCP to 142 increase or decrease the delegated multicast bandwidth depending on 143 the relative demand of muticast flows versus unicast flows. The 144 proposed approach for admission control with bandwidth delegation is 145 compatible with all the conditional access methods supported by 146 [I-D.ietf-ancp-framework]. In particular, it allows multicast 147 admission control check to be performed by the AN even when the AN 148 needs to query the NAS for conditional access check. 150 This memorandum identifies all the corresponding changes that would 151 be required to [I-D.ietf-ancp-framework] in order to reflect the 152 proposed multicast admission control enhancement. The corresponding 153 message flows are also documented, in view of clarifying all the 154 proposed multicast ANCP operations and facilitating future 155 specification of the corresponding ANCP protocol extensions. 157 This memorandum does not propose any change to the other model of 158 operations for multicast Admission Control Control, nor to ANCP 159 operations for the other multicast use cases. 161 2. Terminology 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in RFC 2119. 167 3. Multicast Use Cases 169 This section describes the ANCP use cases related to Multicast. 171 3.1. Conditional Access 173 This section discusses the changes proposed to section 3.4.1 of 174 [I-D.ietf-ancp-framework]. 176 [I-D.ietf-ancp-framework] defines the concept of multicast flows that 177 share the same control rules (ie same Conditional Access rules and 178 same Admission Control rules). The objective of this concept was to 179 achieve a tradeoff between pre-provisioning the AN with all 180 Conditional Access and Admission Control information and querying the 181 NAS on a per join basis. The former may be a configuration burden 182 and may lead in large delays when the NAS or AN restarts, while the 183 latter may increase channel join and channel change times because of 184 the additional message processing involved in the AN, the NAS and 185 potentially the Policy Server. 187 Now considering that 189 o this memorandum proposes (in Section 3.2) the extension of the 190 concept of multicast flows that share the same Admission Control 191 rules into an approach of bandwidth delegation from NAS to the AN 192 whereby channels of equivalent bandwidth no longer need to be 193 provisioned into the AN by the NAS 195 o grey lists in case of the Conditional Access scenario are mainly 196 used in order to be able to have the conditional access decision 197 taken by the NAS or a Policy Server (especially in order to 198 address the case when conditional access information changes 199 frequently, or when the multicast groups are not known to a client 200 application in advance, thus where it may not be possible or 201 convenient to pre-provisioning AN with conditional access 202 information) 204 we propose to simplify operations of Conditional Access and remove 205 the notion of multicast flows sharing the same conditional access 206 rules. Specifically, we propose to remove the following two 207 paragraphs of section 3.4.1 [I-D.ietf-ancp-framework]: 209 "Querying the NAS before performing a join on the AN may increase 210 channel join and channel change times because of the additional 211 message processing involved in the AN, the NAS and potentially the 212 Policy Server. On the other hand, pre-provisioning per subscriber 213 profiles potentially different for each subscriber may be a 214 configuration burden, may result in large delays when the NAS or AN 215 restarts, or may not be viable when conditional access changes 216 frequently or are to remain under the control of an external 217 administrative entity. 219 In order to account for these operational factors and associated 220 trade-offs, in some cases, the provisioning and querying techniques 221 can be combined. In such a model, the AN sends an Admission Request 222 message to the NAS as a trigger for a particular multicast flow. The 223 NAS would then send back an Admission Response message to the AN, 224 including conditional access information for that multicast flow, as 225 well as for a set of multicast flows sharing the same conditional 226 access rules. The AN can then autonomously honor or deny requests 227 for a given user/port for the set of Multicast flows as indicated in 228 the Admission Response message." 230 3.2. Multicast Admission Control 232 Section 3.4.2 of [I-D.ietf-ancp-framework] presents the requirement 233 for synchronization between the entity performing multicast CAC, the 234 entity performing unicast CAC and the entity actually enforcing 235 multicast replication. It describes three approaches to perform this 236 synchronization. This memorandum proposes the following changes to 237 the methods described in the first and in the third bullet. 239 Replace the following text: 241 " One approach is for the AN to query the NAS so that both unicast 242 and multicast CAC for the access line are performed by the NAS. In 243 this case, the AN can use ANCP to query the NAS, that in turn 244 performs multicast CAC and responds to the AN indicating whether the 245 join is to be honored (and hence replication performed by the AN) or 246 denied. The NAS may locally maintain available "video" bandwidth on 247 the Access Loop, and perform video bandwidth accounting for the 248 Access Loop. Upon receiving an Admission Request from the AN, the 249 NAS can check available "video" bandwidth before admitting or denying 250 the multicast flow. In the process, the NAS may communicate with the 251 Policy Server. For unicast video services such as Video on Demand 252 (VoD), the NAS may also be queried (by a Policy Server or via on-path 253 CAC signaling), so that it can perform admission control for the 254 unicast flow, and update the available video bandwidth maintained by 255 the NAS. Similarly to what has been discussed in the Conditional 256 Access use case, in response to a Admission Request from the AN for 257 admission control of a multicast flow, the NAS may send back an 258 Admission Response message to the AN, including admission control 259 information for that multicast flow, as well as for a set of 260 multicast flows sharing the same admission control rules. The AN can 261 then autonomously honor or deny requests for a given user/port for 262 the set of Multicast flows as indicated in the Admission Response 263 message. The ANCP requirements to support this approach (where the 264 AN queries the NAS) are specified in this document;" 266 by the following text: 268 "One approach is where ANCP allows Admission Control to be performed 269 by the NAS (possibly with interactions with a Policy Server) either 270 without any involvement of the Access Node or with some involvement 271 of the Access Node in particular with the delegation of some 272 decisions to the Access Node. 274 The NAS uses ANCP to indicate to the AN whether or not Admission 275 Control is needed for each multicast flow on a given Access Port, and 276 where Admission Control is needed whether or not it is to be 277 performed with AN Bandwidth Delegation. In particular: 279 o multicast flows that require Admission Control without AN 280 Bandwidth Delegation are inserted in the Grey List and these 281 entries are flagged as "no Bandwidth Delegation"; 283 o multicast flows that require Admission Control with AN Bandwidth 284 Delegation are: 286 o 288 * inserted in the White list and flagged as "Bandwidth 289 Delegation", in case they do not require any Conditional Access 290 operation to be performed by the NAS 292 * inserted in the Grey List and flagged as "Bandwidth 293 Delegation", in case they require some Conditional Access 294 checks to be performed by the NAS. 296 In case of Admission Control without AN Bandwidth Delegation, the AN 297 can use ANCP to query the NAS, that in turn performs multicast 298 Admission Control check for the new multicast flow and responds to 299 the AN indicating whether the join is to be honored (and hence 300 replication performed by the AN) or denied. The NAS may locally 301 maintain available "video" bandwidth on the Access Loop, and perform 302 video bandwidth accounting for the Access Loop. Upon receiving an 303 Admission Request from the AN, the NAS can check available "video" 304 bandwidth before admitting or denying the multicast flow. In the 305 process, the NAS may communicate with the Policy Server. For unicast 306 video services such as Video on Demand (VoD), the NAS may also be 307 queried (by a Policy Server or via on-path CAC signaling), so that it 308 can perform admission control for the unicast flow, and update the 309 available video bandwidth maintained by the NAS. 311 In case of Admission Control with AN Bandwidth Delegation, the NAS 312 (possibly with interactions with a Policy Server) manages total 313 bandwidth for video admission, performs unicast admission control and 314 uses ANCP to delegate a certain amount of bandwidth for some 315 multicast flows to the Access Node. In this scenario upon receiving 316 a join to a multicast flow which matches the White or Grey Lists 317 whose entry is flagged as "Bandwidth Delegation" for a specific 318 Access Port, before starting the multicast flow replication the AN 319 must perform the necessary bandwidth admission control check for the 320 new multicast flow. 322 In some cases, the bandwidth that the NAS initially delegated to the 323 AN may not be enough to satisfy a multicast request for a new flow. 324 In this scenario the AN can use ANCP to query the NAS in order to 325 request additional multicast bandwidth; the NAS (possibly with 326 interactions with a Policy Server) decides if the request for more 327 bandwidth can be satisfied and uses ANCP to send a response to the AN 328 indicating the updated delegated multicast bandwidth. It is worth 329 noticing that in this case, the time taken to complete the procedure 330 is an increment to the zapping delay: in order to minimize the 331 zapping delay for future join requests the AN can insert in the 332 request message two values: the minimum amount of additional 333 multicast bandwidth requested, and the preferred additional amount. 334 The first value is the amount that allows the present join request to 335 be satisfied, the second value an amount that anticipates further 336 join requests. 338 In some cases, the NAS (or the Policy Server) may not have enough 339 unicast bandwidth to satisfy a new incoming video request: in these 340 scenarios the NAS can use ANCP to query (or instruct) the AN in order 341 to decrease the amount of multicast bandwidth previously delegated on 342 a given Access Port. The AN upon receiving this query from the NAS 343 can use ANCP to send a response to AN indicating the updated 344 delegated multicast bandwidth. Actually, based on considerations 345 similar to those of the previous paragraph, it indicates the minimum 346 amount of multicast bandwidth that it needs released and a preferred 347 amount, which may be larger. 349 In addition in some cases upon receiving a leave for a specific 350 multicast flow the AN can decides that it has an excess of delegated 351 but uncommitted bandwidth, thus the AN can use ANCP to send a message 352 to the NAS to release unused multicast bandwdth previously delegated. 354 The ANCP requirements to support this approach (where the AN queries 355 the NAS) are specified in this document; " 357 Replace this text: 359 " In a third approach, the Policy Server queries the AN (either 360 directly, or indirectly via the NAS) so that both unicast and 361 multicast CAC for the access line are performed by the AN. In this 362 case, a subscriber request for a unicast flow (e.g. a Video on Demand 363 session) will trigger a resource request message towards a Policy 364 Server; the latter will then query the AN, that in turn will perform 365 unicast CAC for the access line and respond, indicating whether the 366 unicast request is to be honored or denied. This method will not be 367 addressed in this document; it may be covered by means of ANCP 368 extensions at a later stage. " 370 by the following text: 372 "In a third approach, the Policy Server queries the AN directly so 373 that both unicast and multicast CAC for the access line are performed 374 by the AN. In this case, a subscriber request for a unicast flow 375 (e.g. a Video on Demand session) will trigger a resource request 376 message towards a Policy Server; the latter will then query the AN, 377 that in turn will perform unicast CAC for the access line and 378 respond, indicating whether the unicast request is to be honored or 379 denied. In this scenario the Policy Server queries the AN directly, 380 the approach doesn't require the use of ANCP. It is therefore beyond 381 the scope of this document." 383 3.2.1. When not to perform Admission Control for a subset of flows 385 This memorandum does not propose any update over the description of 386 this use case provided in section 3.4.2.1 of 387 [I-D.ietf-ancp-framework]. 389 3.2.2. Multicast Admission Control and White Lists 391 This memorandum does not propose any update over the description of 392 this use case provided in section 3.4.2.2 of 393 [I-D.ietf-ancp-framework]. 395 3.3. Multicast Accounting and Reporting 397 This memorandum does not propose any update over the description of 398 this use case provided in section 3.4.3 of [I-D.ietf-ancp-framework]. 400 3.4. Spontaneous Admission Response 402 This memorandum does not propose any update over the description of 403 this use case provided in section 3.4.4 of [I-D.ietf-ancp-framework]. 405 4. Multicast Protocol Requirements 407 4.1. ANCP Multicast Requirements 409 This memorandum proposes the following changes to section 4.2 of 410 [I-D.ietf-ancp-framework]. 412 Replace the following requirement: 414 o The ANCP must allow the NAS, when replying to an AN request, to 415 convey information on multiple multicast flows sharing the same 416 conditional access and/or admission control rules. This allows 417 the AN to take autonomous decisions for these flows later on. 419 by the following requirements: 421 o The ANCP must allow the NAS to indicate to the AN whether or not 422 Admission Control is needed for some multicast flows on a given 423 Access Port and where needed whether or not it is to be performed 424 with AN Bandwidth Delegation. 426 o In case of Admission Control without AN Bandwidth Delegation the 427 ANCP must allow the NAS to reply to a query from the AN indicating 428 whether or not a multicast flow may be replicated to a particular 429 Access Port. 431 o In case of Admission Control with AN Bandwidth Delegation, the 432 ANCP must allow the NAS to delegate a certain amount of bandwidth 433 to the AN for a given Access Port. 435 o In case of Admission Control with AN Bandwidth Delegation the ANCP 436 must allow the AN to query the NAS to request additional multicast 437 bandwidth on a given Access Port. 439 o In case of Admission Control with AN Bandwidth Delegation the ANCP 440 must allow the NAS to query (or to instruct) the AN to reduce the 441 amount of bandwidth previously delegated on a given Access Port. 443 o In case of Admission Control with AN Bandwidth Delegation the ANCP 444 must allow the AN to autonomous release redundant multicast 445 bandwidth on a given Access Port. 447 4.2. ANCP Access Node Multicast Requirements 449 This memorandum proposes the following changes to section 4.7.6 of 450 [I-D.ietf-ancp-framework]. 452 Replace the following requirements: 454 o The AN must accept any join to a multicast flow matching the White 455 List for the relevant Access Port. 457 o Upon receiving a join to a multicast flow which matches the Grey 458 List for a specific Access Port, the AN must support using ANCP to 459 query the NAS to receive a response indicating whether that join 460 is to be honored or denied. 462 o Upon querying the NAS, the AN should support receiving ANCP 463 messages from the NAS containing conditional access and/or 464 admission control information of multiple multicast flows. This 465 allows the AN to take autonomous decisions for these flows later 466 on. 468 o The AN should support using ANCP to notify the NAS when resources 469 for a multicast flow are no longer in use (e.g. the AN is no 470 longer replicating any multicast flows from a set of multicast 471 flows sharing the same admission control rules). This allows 472 corresponding bandwidth to be released on NAS. 474 by the following requirements: 476 o The AN must accept any join to a multicast flow matching the White 477 List and flagged as "no CAC" for the relevant Access Port. 479 o Upon receiving a join to a multicast flow which matches the White 480 List whose entry is flagged as "Bandwidth Delegation" for a 481 specific Access Port, before starting the multicast flow 482 replication the AN must perform the necessary bandwidth admission 483 control check for the new flow. 485 o Upon receiving a join to a multicast flow which matches the Grey 486 List whose entry is flagged as "no Bandwidth Delegation" for a 487 specific Access Port, the AN must support using ANCP to query the 488 NAS that in turn will perform both the necessary conditional 489 access and the admission control checks for the new flow and sends 490 a response indicating whether that join is to be honored or 491 denied. The AN must support using ANCP to notify the NAS when the 492 the user leaves the multicast flow. 494 o Upon receiving a join to a multicast flow which matches the Grey 495 List whose entry is flagged as "Bandwidth Delegation" for a 496 specific Access Port, the AN must perform the necessary bandwidth 497 admission control check for the new flow and if it is successful 498 the AN must support using ANCP to query the NAS to receive a 499 response indicating whether that join is to be honored or denied. 501 o In case of Admission Control with AN Bandwidth Delegation, the AN 502 must support using ANCP to query the NAS to request additional 503 delegated multicast bandwidth on a given Access Port; the AN 504 should be able to specify both the minimum and the preferred 505 amount of additional multicast bandwidth requested. 507 o In case of Admission Control with AN Bandwidth Delegation, upon 508 receiving a Bandwidth Delegation Request from the NAS querying or 509 instructing to decrease the delegated multicast bandwidth on a 510 given Access Port, the AN must support using ANCP to send a 511 Bandwidth Delegation Response indicating the new delegating 512 multicast bandwidth 514 o In case of Admission Control with AN Bandwidth Delegation, the AN 515 must support using ANCP to send a Bandwidth Release message to the 516 NAS in order to release unused delegated multicast bandwidth on a 517 given Access Port. 519 4.3. ANCP NAS Multicast Requirements 521 This memorandum proposes the following changes to section 4.8.6 of 522 [I-D.ietf-ancp-framework]. 524 Replace the following requirements: 526 o The NAS must support using ANCP to configure multicast conditional 527 access information to Access Ports on an Access Node, using Black 528 Lists and White Lists 530 o Upon receiving a query from the AN for a request to replicate a 531 multicast flow to a particular Access Port, the NAS must support 532 using ANCP to reply to the AN indicating whether the request is to 533 be honored or denied. 535 o Upon receiving a query from the AN for a request to replicate 536 multicast flow to a particular Access Port, the NAS should support 537 sending an Admission Response message containing conditional 538 access and/or admission control information of multiple multicast 539 flows. This allows the AN to take autonomous decisions for these 540 flows later on 542 by the following requirements: 544 o The NAS must support using ANCP to configure multicast conditional 545 access information to Access Ports on an Access Node, using Black 546 Lists, Grey Lists and White Lists. 548 o The NAS must support using ANCP to indicate to the AN whether or 549 not Admission Control is needed for some multicast flows on a 550 given Access Port and where needed whether or not it is to be 551 performed with AN Bandwidth Delegation. 553 o Upon receiving a query from the AN for a request to replicate a 554 multicast flow to a particular Access Port and where Admission 555 Control is not needed for that multicast flow on that Access Port, 556 the NAS must be able to perform the necessary conditional access 557 check for the new flow and the NAS must support using ANCP to 558 reply to the AN indicating whether the request is to be honored or 559 denied. 561 o Upon receiving a query from the AN for a request to replicate a 562 multicast flow to a particular Access Port and where Admission 563 Control without AN Bandwidth Delegation is needed for that 564 multicast flow on that Access Port, the NAS must be able to 565 perform both the necessary conditional access (if needed) and the 566 bandwidth admission control check for the new flow and the NAS 567 must support using ANCP to reply to the AN indicating whether the 568 request is to be honored or denied. 570 o In case of Admission Control with AN Bandwidth Delegation the NAS 571 must support using ANCP to delegate a certain amount of bandwidth 572 to the AN for a given Access Port. 574 o In case of Admission Control with AN Bandwidth Delegation, upon 575 receiving a Bandwidth Delegation Request from the AN requesting to 576 increase the delegated multicast bandwidth on a given Access Port, 577 the NAS must support using ANCP to send a Bandwidth Delegation 578 Response indicating the new delegating multicast bandwidth. 580 o In case of Admission Control with AN Bandwidth Delegation, the NAS 581 must support using ANCP to send a request the AN to decrease the 582 amount of multicast bandwidth previously delegated on a given 583 Access Port; the NAS should be able to specify both the minimum 584 and the preferred amount decrement of multicast bandwidth 585 requested. 587 o In case of Admission Control with AN Bandwidth Delegation, upon 588 receiving an ANCP Bandwidth Release message, the NAS must be able 589 to update accordingly its view of the multicast bandwidth 590 delegated to the AN. 592 5. Message Flows 594 This section documents the message flows associated with multicast 595 handling by ANCP. It is not proposed that these message flows be 596 incorporated in [I-D.ietf-ancp-framework] since message flows are 597 outside its scope. These messages flows are intended to clarify 598 operation of the ANCP Multicast and provide guidance for the 599 specification of ANCP Protocol extensions for support of multicast. 601 5.1. Multicast Conditional Access without CAC 603 This section describes ANCP operations when multicast flows are 604 subject to multicast Conditional Access but not subject to CAC. 606 5.1.1. List/Profile Provisioning 608 The AN provisioning is performed by NAS using a Provisioning message 609 that contains White/Black/Grey lists and their corresponding 610 "Multicast Profile ID". To indicate to the AN that it need not 611 perform any CAC operation on those flows, the White List entries are 612 flagged as "no CAC" and the Grey List entries are flagged as "no 613 Bandwidth Delegation". The corresponding message flow is illustrated 614 in Figure 1. 616 Although Figure 1 shows the three lists in the ANCP provisioning 617 message, the message may instead contain any subset of 2 or 1 list. 619 +----------+ +---------+ +-----+ +-----+ 620 |Subscriber| | Home | | AN | | NAS | 621 +----------+ | Gateway | +-----+ +-----+ 622 | +---------+ | | 623 | | | | 624 | | | Provisioning( | 625 | | | (White List(noCAC), | 626 | | | Grey List(noBD), | 627 | | | Black List, | 628 | | | Profile_ID) | 629 | | |<--------------------| 631 (noCAC): entries in the White List flagged as "no CAC" 632 (noBD) : entries in the Grey List flagged 633 as "no Bandwidth Delegation" 635 Figure 1: Provisioning AN with White/Grey/Black Lists for Conditional 636 Access 638 5.1.2. Profile Mapping 640 As soon as the AN port comes up, the AN sends an ANCP PORT_UP message 641 to the NAS specifying the Access Loop Circuit ID. The NAS replies 642 with an ANCP PORT_MNGT message that, together with the other 643 parameters, includes the Multicast Profile ID to be associated to 644 that Port. The corresponding message flow is illustrated in 645 Figure 2. 647 +----------+ +---------+ +-----+ +-----+ 648 |Subscriber| | Home | | AN | | NAS | 649 +----------+ | Gateway | +-----+ +-----+ 650 | +---------+ | | 651 | | | | 652 | | | | 653 | | DSL Synch. | | 654 | |--------------------->| | 655 | | | PORT_UP(Port ID) | 656 | | |-------------------->| 657 | | | (*) 658 | | | PORT_MNGT(Port ID, | 659 | | | Profile_ID) | 660 | | |<--------------------| 662 (*) The NAS may optionnaly communicate with an external 663 Autorization/Policy Server 665 Figure 2: Associating Profile ID to AN Port 667 5.1.3. Join & Leave Operations 669 The message flows in Figure 3 illustrates the behavior of the AN in 670 case of receiving a join and leave messages on the Access Port for 671 multicast flows respectively part of: 673 o white list (with matching entry flagged as "no CAC") 675 o black list 677 o grey list (with matching entry flagged as "no Bandwidth 678 Delegation") 680 +----------+ +-------+ +-----+ ANCP +-----+ 681 |Subscriber| | Home | | AN |<---------->| NAS | 682 +----------+ |Gateway| +-----+ +-----+ 683 | +-------+ | | 684 | | | | 685 | | | | 686 | Join(WhiteNoCAC-Fl) | | 687 |------------+--------->| | 688 | | | | 689 | Mcast White Flow | | 690 |<======================+ | 691 | | | | 692 | | | | 693 | Leave(WhiteNoCAC-Fl) | | 694 |------------+--------->| | 695 | | | | 696 | Join(Black-Fl) | | 697 |-----------+---------->x | 698 | | | 699 | | | 700 | | | | 701 | | | | 702 | Join(GreyNoBD-Fl) | Admission | 703 |-----------+---------->| Request | 704 | | |------------------>| 705 | | | Admission (*) 706 | | | Response | 707 | Mcast Grey Flow |<------------------| 708 |<======================+ | 709 | | | 710 | | | | 711 | Leave(GreyNoBD-Fl) | Admission | 712 |-----------+---------->| Release | 713 | | |------------------>| 714 | | | | 716 WhiteNoCAC-Fl : Multicast Flow matching an entry in White List 717 flagged as "No CAC" 718 GreyNoBD-Fl : Multicast Flow matching an entry in Grey List 719 flagged as "No Bandwidth Delegation" 720 (*) The NAS may optionnaly communicate with an external 721 Autorization/Policy Server 723 Figure 3: Multicast Conditional Access 725 5.2. Multicast Conditional Access and CAC without AN Bandwidth 726 Delegation 728 This section describes ANCP operations when multicast flows are 729 subject to multicast Conditional Access and subject to CAC on NAS 730 without bandwidth delegation on the Access Node. 732 5.2.1. List/Profile Provisioning 734 The AN provisioning is performed by NAS using a Provisioning message 735 that contains Black/Grey lists and their corresponding "Multicast 736 Profile ID". To indicate to the AN that it need not perform any CAC 737 operation on those flows, the Grey List entries are flagged as "no 738 Bandwidth Delegation". The corresponding message flow is illustrated 739 in Figure 4. 741 +----------+ +---------+ +-----+ +-----+ 742 |Subscriber| | Home | | AN | | NAS | 743 +----------+ | Gateway | +-----+ +-----+ 744 | +---------+ | | 745 | | | | 746 | | | Provisioning( | 747 | | | (Grey List(noBD), | 748 | | | Black List, | 749 | | | Profile_ID) | 750 | | |<--------------------| 752 (noBD) : entries in the Grey List flagged 753 as "no Bandwidth Delegation" 755 Figure 4: Provisioning AN with Grey/Black Lists for Conditional 756 Access and CAC without Bandwidth Delegation 758 5.2.2. Profile Mapping 760 The "Profile ID" is associated to the port when the DSL line comes up 761 in the exact same way as illustrated in Figure 2. 763 5.2.3. Join & Leave Operations 765 Upon receiving a join request for a multicast flow in a Grey List 766 whose entry is flagged as "No Bandwidth Delegation", the AN uses ANCP 767 to query the NAS, that in turn will perform the necessary conditional 768 access check and bandwidth admission control check for the new flow 769 and then it will respond to the AN indicating whether the join is to 770 be honored (and hence replication performed by the AN) or denied (and 771 hence replication not performed by the AN). This is illustrated in 772 Figure 5. 774 +----------+ +-------+ +-----+ ANCP +-----+ 775 |Subscriber| | Home | | AN |<---------->| NAS | 776 +----------+ |Gateway| +-----+ +-----+ 777 | +-------+ | | 778 | | | | 779 | | | | 780 | Join(Black-Fl) | | 781 |-----------+---------->x | 782 | | | 783 | | | 784 | | | | 785 | Join(GreyNoBD-Fl) | Admission | 786 |-----------+---------->| Request | 787 | | |------------------>| 788 | | | (*) 789 | | | Admission | 790 | | | Response | 791 | Mcast-Flow |<------------------| 792 |<======================+ | 793 | | | | 794 | | | | 795 | Leave(GreyNoBD-Fl) | Admission | 796 |-----------+---------->| Release | 797 | | |------------------>| 799 (*) The NAS may optionnaly communicate with an external 800 Autorization/Policy Server 802 Figure 5: Multicast Admission Control without AN Bandwidth Delegation 804 5.3. Multicast Admission Control with AN Bandwidth Delegation 806 This section describes ANCP operations when multicast flows are 807 subject to multicast Conditional Access and subject to CAC on NAS 808 with bandwidth delegation on the Access Node. 810 5.3.1. List/Profile Provisioning 812 The AN provisioning is performed by NAS using a Provisioning message 813 that contains White/Black/Grey lists and their corresponding 814 "Multicast Profile ID". To indicate to the AN that it need perform 815 CAC in compliance with Bandwidth Delegation on those flows, the White 816 List entries and Grey List Entries are flagged as "Bandwidth 817 Delegation". The corresponding message flow is illustrated in 818 Figure 1. 820 Although Figure 6 shows the three lists in the ANCP provisioning 821 message, the message may instead contain any subset of 2 or 1 list. 823 The AN is configured by other means with the multicast bandwidth 824 required for each multicast flow. 826 +----------+ +---------+ +-----+ +-----+ 827 |Subscriber| | Home | | AN | | NAS | 828 +----------+ | Gateway | +-----+ +-----+ 829 | +---------+ | | 830 | | | | 831 | | | Provisioning( | 832 | | | (White List(BD), | 833 | | | Grey List(BD), | 834 | | | Black List, | 835 | | | Profile_ID) | 836 | | |<--------------------| 838 (BD): entries in the White/Grey List flagged 839 as "Bandwidth Delegation" 841 Figure 6: Provisioning AN with White/Grey/Black Lists for Conditional 842 Access 844 5.3.2. Profile Mapping and Initial Bandwidth Delegation 846 The "Profile ID" is associated to the port when the DSL line comes up 847 in the same way as illustrated in Figure 2. In addition, the NAS 848 passes to the AN the total video bandwidth (unicast plus multicast) 849 associated to the AN port and the initial AN allocation of multicast 850 bandwidth for the port. The message flow combining these two steps 851 is illustrated in Figure 7. 853 +----------+ +---------+ +-----+ +-----+ 854 |Subscriber| | Home | | AN | | NAS | 855 +----------+ | Gateway | +-----+ +-----+ 856 | +---------+ | | 857 | | | | 858 | | | | 859 | | DSL Synch. | | 860 | |--------------------->| | 861 | | | PORT_UP(Port ID) | 862 | | |-------------------->| 863 | | | (*) 864 | | | PORT_MNGT(Port ID, | 865 | | | Profile_ID, | 866 | | | Total Video bw, | 867 | | | Delegated multicast | 868 | | | Bandwidth) | 869 | | |<--------------------| 870 | | | | 871 | | | Response | 872 | | |-------------------->| 873 | | | | 874 | | | (*) 875 | | | | 877 (*) The NAS may optionnaly communicate with an 878 external Policy Server 880 Figure 7: Multicast Admission Control with AN Bandwidth Delegation 882 5.3.3. Join & Leave Operations 884 Upon receiving a join request for a multicast flow in a Grey List 885 whose entry is flagged as "Bandwidth Delegation", the AN performs 886 admission control of the flow in accordance with Bandwidth Delegation 887 and uses ANCP to query the NAS that in turn will perform the 888 necessary conditional access check for the new flow. The NAS will 889 respond to the AN indicating whether the join is to be honored (and 890 hence replication performed by the AN) or denied (and hence 891 replication not performed by the AN). This is illustrated in 892 Figure 8. In the case where the NAS reponses indicates that the 893 replication is not to be honored, the AN will reflect this in his 894 Bandwidth Delegation operation (ie release corresponding bandwidth 895 within the delegated bandwidth). 897 +----------+ +-------+ +-----+ ANCP +-----+ 898 |Subscriber| | Home | | AN |<---------->| NAS | 899 +----------+ |Gateway| +-----+ +-----+ 900 | +-------+ | | 901 | | | | 902 | Join(WhiteBD-Fl) | | 903 |-----------+---------->| | 904 | | | | 905 | Mcast-Flow | | 906 |<======================| | 907 | | | | 908 | Leave(WhiteBD-Fl) | | 909 |-----------+---------->| | 910 | | | | 911 | | | | 912 | | | | 913 | JOIN(Black-Fl) | | 914 |-----------+---------->| | 915 | | | 916 | | | 917 | | | | 918 | Join(GreyBD-Fl) | Admission | 919 |-----------+---------->| Request | 920 | | |------------------>| 921 | | | (*) 922 | | | Admission | 923 | | | Response | 924 | Mcast-Flow |<------------------| 925 |<======================| | 926 | | | | 927 | Leave(GreyBD-FL) | Admission | 928 |-----------+---------->| Release | 929 | | |------------------>| 931 WhiteBD-Fl : Multicast Flow matching an entry in White List 932 flagged as "Bandwidth Delegation" 933 GreyBD-Fl : Multicast Flow matching an entry in Grey List 934 flagged as "Bandwidth Delegation" 935 (*) The NAS may optionnaly communicate with an 936 external Autorization/Policy Server 938 Figure 8: Multicast Admission Control with AN Bandwidth Delegation 940 5.3.4. AN-Triggered Increase of Delegated Multicast Bandwidth 942 +----------+ +-------+ +-----+ ANCP +-----+ 943 |Subscriber| | Home | | AN |<---------->| NAS | 944 +----------+ |Gateway| +-----+ +-----+ 945 | +-------+ | | 946 | | | | 947 | Join(WhiteBD-Fl1) | | 948 |-----------+---------->| | 949 | | | | 950 | Mcast-Flow | | 951 |<======================| | 952 | | | | 953 | Leave(Flow) | | 954 |-----------+---------->| | 955 | | | | 956 | | | | 957 | Join(WhiteBD-Fl2) | Band Delegation | 958 |-----------+---------->| Request | 959 | | | (min increment, | 960 | | |(pref increment) | 961 | | |------------------>| 962 | | | (*) 963 | | | Band Delegation | 964 | | | Response | 965 | | | (delegated | 966 | | | multicast bw) | 967 | Mcast-Flow |<------------------| 968 |<======================| | 969 | | | | 970 | Leave(Flow) | | 971 |-----------+---------->| | 972 | | | | 974 WhiteBD-Fl1 : Multicast Flow matching an entry in White List 975 flagged as "Bandwidth Delegation" 976 WhiteBD-Fl2 : Multicast Flow matching an entry in White List 977 flagged as "Bandwidth Delegation" 978 WhiteBD-Fl2 requires more bandwidth than currently 979 remaining available from the multicast delegated bandwidth 981 (*) The NAS may optionnaly communicate with an 982 external Autorization/Policy Server 984 Figure 9: Requesting More Multicast Bandwidth 986 5.3.5. NAS-Triggered Decrease of Delegated Multicast Bandwidth 988 +----------+ +-------+ +-----+ ANCP +-----+ 989 |Subscriber| | Home | | AN |<---------->| NAS | 990 +----------+ |Gateway| +-----+ +-----+ 991 | +-------+ | | 992 | | | | 993 | | | (*) 994 | | | | 995 | | | Band Delegation | 996 | | | Request | 997 | | | (min increment, | 998 | | |(pref increment) | 999 | | |<------------------| 1000 | | | | 1001 | | | Band Delegation | 1002 | | | Response | 1003 | | | (delegated | 1004 | | | multicast bw) | 1005 | | |------------------>| 1006 | | | | 1007 | | | (*) 1008 | | | | 1010 (*) The NAS may optionnaly communicate with an 1011 external Autorization/Policy Server 1013 Figure 10: Requesting More Unicast Bandwidth 1015 5.3.6. AN Release of Redundant Multicast Bandwidth 1016 +----------+ +-------+ +-----+ ANCP +-----+ 1017 |Subscriber| | Home | | AN |<-------------->| NAS | 1018 +----------+ |Gateway| +-----+ +-----+ 1019 | +-------+ | | 1020 | | | | 1021 | Leave(WhiteBD-Fl) | | 1022 |----------------------->| Band Release | 1023 | | | (allocated multicast| 1024 | | | bandwidth) | 1025 | | |--------------------->| 1026 (*) 1028 WhiteBD-Fl : Multicast Flow matching an entry in White List 1029 flagged as "Bandwidth Delegation" 1031 (*) The NAS may optionnaly communicate with an 1032 external Autorization/Policy Server 1034 Figure 11: AN Autonomous Release of Multicast Bandwidth 1036 5.4. Multicast Accounting 1038 The NAS specifies if accounting is needed for a particular multicast 1039 flow: for Multicast flows belonging to the Grey list this can be 1040 conveyed in the ANCP Admission Response message sent from NAS to AN. 1041 For Multicast flows whose replication is controlled by the AN via the 1042 White list, the AN starts the multicast replication without querying 1043 the NAS and thus the NAS does not send Admission Response message; in 1044 this case the need for accounting is conveyed by the NAS in the White 1045 list during the White list provisioning phase. 1047 5.4.1. List/Profile Provisioning 1049 The AN provisioning is performed by NAS using a Provisioning message 1050 that contains White/Black/Grey lists and their corresponding 1051 "Multicast Profile ID". To indicate to the AN that it need perform 1052 Accounting on those flows, the White List entries are flagged as 1053 either "Basic Accounting" or "Detailed Accounting". The 1054 corresponding message flow is illustrated in Figure 12. 1056 Although Figure 6 shows the three lists in the ANCP provisioning 1057 message, the message may instead contain any subset of 2 or 1 list. 1059 +----------+ +---------+ +-----+ +-----+ 1060 |Subscriber| | Home | | AN | | NAS | 1061 +----------+ | Gateway | +-----+ +-----+ 1062 | +---------+ | | 1063 | | | | 1064 | | | Provisioning( | 1065 | | |(White List (Accounting), | 1066 | | | Grey List, | 1067 | | | Black List, | 1068 | | | Profile_ID) | 1069 | | |<-------------------------| 1070 | | | | 1072 (Accounting): entries in the White List flagged 1073 as "Basic Accounting" or "Detailed Accounting" 1075 Figure 12: Provisioning AN with White/Grey/Black Lists for Accounting 1077 5.4.2. Profile Mapping 1079 The "Profile ID" is associated to the port when the DSL line comes up 1080 in the exact same way as illustrated in Figure 2. 1082 5.4.3. Join & Leave Operations 1084 The message flows in Figure 13 illustrates the behavior of the AN in 1085 case of receiving a join and leave messages on the Access Port for 1086 multicast flows respectively part of: 1088 o white list (with matching entry flagged as "Basic Accounting" or 1089 "Detailed Accouting") 1091 o black list 1093 o grey list 1094 +----------+ +-------+ +-----+ ANCP +-----+ 1095 |Subscriber| | Home | | AN |<---------->| NAS | 1096 +----------+ |Gateway| +-----+ +-----+ 1097 | +-------+ | | 1098 | | | | 1099 | | | | 1100 | Join(WhiteAcct-Fl) | | 1101 |------------+----------->| | 1102 | | | | 1103 | Mcast White Flow | | 1104 |<========================+ Replication Start | 1105 | | |------------------->| 1106 | | | | 1107 | | | | 1108 | | | | 1109 | Leave(WhiteAcct-Fl) | | 1110 |------------+----------->| Information Report | 1111 | | |------------------->| 1112 | | | | 1113 | Join(Black-Fl) | | 1114 |------------+----------->x | 1115 | | | 1116 | | | 1117 | | | | 1118 | | | | 1119 | Join(Grey-Fl) | Admission | 1120 |------------+----------->| Request | 1121 | | |------------------->| 1122 | | | Admission (*) 1123 | | |Response(Accounting)| 1124 | Mcast Grey Flow |<-------------------| 1125 |<========================+ | 1126 | | | 1127 | | | Replication Start | 1128 | | |------------------->| 1129 | Leave(Grey-Fl) | | 1130 |------------+----------->| Information Report | 1131 | | |------------------->| 1132 | | | | 1134 WhiteAcct-Fl : Multicast Flow matching an entry in White List 1135 flagged as "Basic Accouting" 1136 Grey-Fl : Multicast Flow matching an entry in Grey List 1138 (*) The NAS may optionnaly communicate with an external 1139 AAA Server 1140 Figure 13: Multicast Accounting 1142 5.5. Multicast Reporting 1144 NAS uses "Port Report-Query" to query the AN to know which flows are 1145 currently active on a specific port; 1147 NAS uses "Multicast Flow Report-Query" to query the AN to know on 1148 which ports the specified multicast flow is currently active; 1150 NAS uses "AN global Report-Query" to query the AN to know all 1151 multicast flows currently active on all AN ports. 1153 The message flows in Figure 14 illustrates the behavior of the AN in 1154 case of receiving one of three Report Query messages from the NAS. 1156 +----------+ +-------+ +-----+ ANCP +-----+ 1157 |Subscriber| | Home | | AN |<---------->| NAS | 1158 +----------+ |Gateway| +-----+ +-----+ 1159 | +-------+ | | 1160 | | | | 1161 | | | Port Report-Query | 1162 | | | (Port ID) | 1163 | Report (Mcast flows) |<------------------| 1164 |------------+----------->| | 1165 | | | | 1166 | | | | 1167 | | | Flow Report-Query | 1168 | | | (Mcast Flow) | 1169 | Report (Port IDi, |<------------------| 1170 | Port IDj,..) | | 1171 |------------+----------->| | 1172 | | | | 1173 | | | | 1174 | | |Global-Report-Query| 1175 | | | (Port ID) | 1176 | | | | 1177 |Report (All Mast Flows) |<------------------| 1178 |------------+----------->| | 1180 Figure 14: Multicast Reporting 1182 5.6. NAS-Controlled Multicast Replication 1184 The Replication Control Request Message is sent by the NAS to the AN 1185 with a directive to either join or leave one or more multicast flows. 1186 The AN will use a Replication Control Response message when conveying 1187 the outcome of the directive. The message flows in Figure 15 1188 illustrates the behavior of the AN in case of receiving a Replication 1189 Control Request Message. 1191 +----------+ +-------+ +-----+ ANCP +-----+ 1192 |Subscriber| | Home | | AN |<------------>| NAS | 1193 +----------+ |Gateway| +-----+ +-----+ 1194 | +-------+ | | 1195 | | | | 1196 | | | Replication-Crl( | 1197 | | | Port ID,add Flow1)| 1198 | | |<--------------------| 1199 | Mcast Flow 1 | | 1200 |<==========================+ | 1201 | | |Replication-Response | 1202 | | | (status) | 1203 | | |-------------------->| 1204 | | | | 1205 | | | | 1206 | | | Replication-Crl( | 1207 | | |Port ID,delete Flow1)| 1208 | | |<--------------------| 1209 | | | | 1210 | |Replication-Response | 1212 | | | (status) | 1213 | | |-------------------->| 1215 Figure 15: NAS-Controlled Multicast Replication 1217 6. Security Considerations 1219 Those are addressed in [I-D.ietf-ancp-framework]. 1221 7. IANA Considerations 1223 Not applicable. 1225 8. Acknowledgements 1227 The authors would like to thank Wojciech Dec for his valuable 1228 comments. 1230 9. References 1232 9.1. Normative References 1234 [I-D.ietf-ancp-framework] 1235 Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. 1236 Wadhwa, "Framework and Requirements for an Access Node 1237 Control Mechanism in Broadband Multi-Service Networks", 1238 draft-ietf-ancp-framework-06 (work in progress), May 2008. 1240 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1241 Requirement Levels", BCP 14, RFC 2119, March 1997. 1243 [RFC3292] Doria, A., Hellstrand, F., Sundell, K., and T. Worster, 1244 "General Switch Management Protocol (GSMP) V3", RFC 3292, 1245 June 2002. 1247 9.2. Informative References 1249 [I-D.ietf-ancp-protocol] 1250 Wadhwa, S., "Protocol for Access Node Control Mechanism in 1251 Broadband Networks", draft-ietf-ancp-protocol-02 (work in 1252 progress), November 2007. 1254 Authors' Addresses 1256 Roberta Maglione 1257 Telecom Italia 1258 Via Reiss Romoli 274 1259 Torino 10148 1260 Italy 1262 Phone: 1263 Email: roberta.maglione@telecomitalia.it 1265 Angelo Garofalo 1266 Telecom Italia 1267 Via Reiss Romoli 274 1268 Torino 10148 1269 Italy 1271 Phone: 1272 Email: angelo.garofalo@telecomitalia.it 1274 Francois Le Faucheur 1275 Cisco Systems 1276 Greenside, 400 Avenue de Roumanille 1277 Sophia Antipolis 06410 1278 France 1280 Phone: +33 4 97 23 26 19 1281 Email: flefauch@cisco.com 1283 Toerless Eckert 1284 Cisco Systems 1285 Tasman Drive 1286 San Jose, CA 95134 1287 USA 1289 Phone: 1290 Email: ackert@cisco.com 1291 Tom Taylor 1292 Huawei Technologies 1293 1852 Lorraine Ave 1294 Ottawa, Ontario K1H 6Z8 1295 Canada 1297 Phone: +1 613 680 2675 1298 Email: tom.taylor@rogers.com 1300 Full Copyright Statement 1302 Copyright (C) The IETF Trust (2008). 1304 This document is subject to the rights, licenses and restrictions 1305 contained in BCP 78, and except as set forth therein, the authors 1306 retain all their rights. 1308 This document and the information contained herein are provided on an 1309 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1310 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1311 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1312 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1313 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1314 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1316 Intellectual Property 1318 The IETF takes no position regarding the validity or scope of any 1319 Intellectual Property Rights or other rights that might be claimed to 1320 pertain to the implementation or use of the technology described in 1321 this document or the extent to which any license under such rights 1322 might or might not be available; nor does it represent that it has 1323 made any independent effort to identify any such rights. Information 1324 on the procedures with respect to rights in RFC documents can be 1325 found in BCP 78 and BCP 79. 1327 Copies of IPR disclosures made to the IETF Secretariat and any 1328 assurances of licenses to be made available, or the result of an 1329 attempt made to obtain a general license or permission for the use of 1330 such proprietary rights by implementers or users of this 1331 specification can be obtained from the IETF on-line IPR repository at 1332 http://www.ietf.org/ipr. 1334 The IETF invites any interested party to bring to its attention any 1335 copyrights, patents or patent applications, or other proprietary 1336 rights that may cover technology that may be required to implement 1337 this standard. Please address the information to the IETF at 1338 ietf-ipr@ietf.org.