idnits 2.17.1 draft-ietf-mboned-multiaaa-framework-10.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-mboned-maccnt-req]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, 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 (August 4, 2009) is 5380 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-ancp-framework' is defined on line 839, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-ancp-framework-11 == Outdated reference: A later version (-10) exists of draft-ietf-mboned-maccnt-req-08 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 mboned T. Hayashi 2 Internet-Draft NTT Network Innovation 3 Intended status: Informational Laboratories 4 Expires: February 5, 2010 H. He 5 Nortel 6 H. Satou 7 H. Ohta 8 NTT Network Service Systems 9 Laboratories 10 C. Jacquenet 11 France Telecom 12 August 4, 2009 14 AAA and Admission Control Framework for Multicasting 15 draft-ietf-mboned-multiaaa-framework-10 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. This document may contain material 21 from IETF Documents or IETF Contributions published or made publicly 22 available before November 10, 2008. The person(s) controlling the 23 copyright in some of this material may not have granted the IETF 24 Trust the right to allow modifications of such material outside the 25 IETF Standards Process. Without obtaining an adequate license from 26 the person(s) controlling the copyright in such materials, this 27 document may not be modified outside the IETF Standards Process, and 28 derivative works of it may not be created outside the IETF Standards 29 Process, except to format it for publication as an RFC or to 30 translate it into languages other than English. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on February 5, 2010. 50 Copyright Notice 52 Copyright (c) 2009 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents in effect on the date of 57 publication of this document (http://trustee.ietf.org/license-info). 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. 61 Abstract 63 IP multicast-based services, such as TV broadcasting or 64 videoconferencing raise the issue of making sure that potential 65 customers are fully entitled to access the corresponding contents. 66 There is indeed a need for service and content providers to identify 67 users (if not authenticate, especially within the context of 68 enforcing electronic payment schemes) and to retrieve statistical 69 information for accounting purposes, as far as content and network 70 usage are concerned. This memo describes the framework for 71 specifying the Authorization, Authentication and Accounting (AAA) 72 capabilities that could be activated within the context of the 73 deployment and the operation of IP multicast-based services. This 74 framework addresses the requirements presented in "Requirements for 75 Accounting, Authentication and Authorization in Well Managed IP 76 Multicasting Services" [I-D.ietf-mboned-maccnt-req]. The memo 77 provides a basic AAA enabled model as well as an extended fully 78 enabled model with resource and admission control coordination. 80 Table of Contents 82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 83 1.1. Purpose and Background . . . . . . . . . . . . . . . . . . 4 84 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 5 85 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 86 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 87 3. Common use models and network architecture implications . . . 7 88 4. Framework and Roles of Entities . . . . . . . . . . . . . . . 8 89 4.1. AAA Framework in Multicast-Enabled Environments . . . . . 8 90 4.2. User ID . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 4.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 11 92 4.4. Access Control and CP selection by NSP . . . . . . . . . . 12 93 4.5. Admission Control Information by NSP . . . . . . . . . . . 13 94 4.6. Access Control and Distinguishing of Users by CP . . . . . 14 95 4.7. AAA proxy in NSP . . . . . . . . . . . . . . . . . . . . . 14 96 5. Network Connection Model and Functional Components . . . . . . 14 97 5.1. Basic Connection Model . . . . . . . . . . . . . . . . . . 15 98 5.2. Constituent Logical Functional Components of the fully 99 enabled AAA Framework . . . . . . . . . . . . . . . . . . 16 100 5.3. Modularity of the framework . . . . . . . . . . . . . . . 20 101 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 102 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 103 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20 104 9. Normative References . . . . . . . . . . . . . . . . . . . . . 20 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 107 1. Introduction 109 1.1. Purpose and Background 111 IP multicasting is designed to serve cases of group communication 112 schemes of any kind, such as one-to-many (case of TV broadcasting 113 services for example) or many-to- many (case of videoconferencing 114 services, for example). 116 In these environments, IP multicast provides a better resource 117 optimization than using a unicast transmission scheme, where data 118 need to be replicated as many times as there are receivers. 119 Activation of IP multicast capabilities in networks yields the 120 establishment and the maintenance of multicast distribution trees 121 that are receiver-initiated by nature: multicast-formatted data are 122 forwarded to receivers who explicitly request them. IP multicast- 123 based services, such as TV broadcasting or videoconferencing raise 124 the issue of making sure that potential customers are fully entitled 125 to access the corresponding contents. There is indeed a need for 126 service and content providers to identify (if not authenticate, 127 especially within the context of enforcing electronic payment 128 schemes) and to invoice such customers in a reliable and efficient 129 manner. Solutions should consider a wide range of possible content 130 delivery applications: content delivered over the multicast network 131 may include video, audio, images, games, software and information 132 such as financial data, etc. 134 This memo describes a framework for specifying the Authorization, 135 Authentication and Accounting (AAA) capabilities that could be 136 activated within the context of the deployment and the operation of 137 IP multicast-based services. This memo also describes a framework to 138 realize high-quality multicast transport using a Multicast Admission 139 Control Function (MACF) with multicast Authorization. 141 Specifically, this framework addresses the requirements presented in 142 "Requirements for Multicast AAA coordinated between Content 143 Provider(s) and Network Service Provider(s)" which describes the 144 requirements in CDN services using IP multicast. The requirements 145 are derived from: 147 need for user tracking and billing capabilities 149 need for network access control to satisfy the requirements of the 150 Network Service Provider (NSP) and/or content access control to 151 satisfy the requirements of the Content Provider (CP) 153 methods for sharing information between the network service 154 provider and content provider to make it possible to fulfill the 155 above two requirements. [I-D.mboned-maccnt- req] 157 Detailed requirements are presented in "Requirements for Accounting, 158 Authentication and Authorization in Well Managed IP Multicasting 159 Services" [I-D.ietf-mboned-maccnt-req]. These requirements include 160 mechanisms for recording end- user requests and provider responses 161 for content-delivery, sharing user information (possibly anonymously 162 depending on the trust model) between content provider and network 163 service provider, and protecting resources through the prevention of 164 network and content access by unauthorized users, as well as other 165 AAA related requirements. 167 The purpose of this memo is to provide a generalized framework for 168 specifying multicast-inferred AAA capabilities that can meet these 169 requirements. This framework is to provide a basis for future work 170 of investigating the applicability of existing AAA protocols to 171 provide these AAA capabilities in IP multicast specific context 172 and/or if deemed necessary, the refining or defining of protocols to 173 provide these capabilities. 175 2. Definitions and Abbreviations 177 2.1. Definitions 179 For the purpose of this memo the following definitions apply: 181 Accounting: The set of capabilities that allow the retrieval of a 182 set of statistical data that can be defined on a per customer 183 and/or a per service basis, within the context of the deployment 184 of multicast-based services. Such data are retrieved for billing 185 purposes, and can be retrieved on a regular basis or upon 186 unsolicited requests. Such data include (but are not necessarily 187 limited to) the volume of multicast-formatted data that have been 188 forwarded to the receiver over a given period of time, the volume 189 of multicast-formatted data that have been exchanged between a 190 receiver (or set of) and a given source over a given period of 191 time (e.g. the duration of a multicast session), etc. 193 Authentication: action for identifying a user as a genuine one. 195 Authorization: The set of capabilities that need to be activated 196 to make sure an authenticated user is fully entitled to access a 197 set of services. 199 Join: Signaling mechanism used by receivers to indicate they want 200 to access a multicast group and receive the corresponding traffic. 202 Leave: Signaling mechanism used by receivers to indicate they want 203 to leave a multicast group and not receive the corresponding 204 traffic anymore. 206 Receiver: an end-host or end-client which receives content. A 207 receiver may be identified by a network ID such as MAC address or 208 IP address. 210 User: a human with a user account. A user may possibly use 211 multiple reception devices. Multiple users may use the same 212 reception device. (Note: The definition of a receiver (device) 213 and a user (human) should not be confused.) 215 2.2. Abbreviations 217 For the purpose of this draft the following abbreviations apply: 219 AAA: Authentication.Authorization.and Accounting 221 ACL: Access Control List 223 AN: Access Node 225 CDN: Content Delivery Network 227 CDS: Content Delivery Services 229 CP: Content Provider 231 CP-AAA: Authentication, Authorization, and Accounting functions 232 used by a Content Provider 234 CPE: Customer Premise Equipment 236 ID: Identifier 238 IF: network interface 240 mAAA: Authentication, Authorization, and Accounting functions 241 activated in multicast-enabled environments 243 MACF: Multicast Admission Control Function 245 NAS: Network Access Server (RFC2881) 247 NSP: Network Service Provider 248 NSP-mAAA: Authentication, Authorization, and Accounting functions 249 used by a Network Service provider 251 QoS: Quality of Service 253 3. Common use models and network architecture implications 255 In some cases a single entity may design and be responsible for a 256 system that covers the various common high-level requirements of a 257 multicasting system such as 1) content serving, 2) the infrastructure 258 to multicast it, 3) network and content access control mechanisms. 260 In many cases however the content provision and network provision 261 roles are divided between separate entities. Commonly, Content 262 Providers (CP) do not build and maintain their own multicast network 263 infrastructure as this is not their primary business area. CP often 264 purchase transport and management services from network service 265 providers instead. Similarly Network Service Providers (NSP) may not 266 make their business in providing content. [I-D.mboned- maccnt-req] 267 provides more detail of the multiple versus single-entity Content 268 Delivery Service (CDS) network models. 270 In the usage model where a single NSP provides multicast services to 271 multiple CPs, the following general requirements from [I-D.ietf- 272 mboned-maccnt-req] apply: 274 Need for user tracking and billing capabilities 276 Need for QoS control such as resource management and admission 277 control 279 Need for conditional multicast access control satisfactory to the 280 requirements of the CP 282 Methods for sharing information between the NSP and CP to make the 283 above two possible 285 When the NSP and CP are the same single entity then the general 286 requirements are as follows. 288 Need for user tracking and user-billing capabilities 290 Need for access control and/or content protection at level the 291 entity deems appropriate 293 4. Framework and Roles of Entities 295 4.1. AAA Framework in Multicast-Enabled Environments 297 A general high-level framework is depicted in Figure 1. 299 +------------------------------+ 300 | user | 301 | | 302 +------------------------------+ 303 | 304 | 305 | 306 +------------------------------+ 307 | NSP | 308 | | 309 +------------------------------+ 310 | 311 | 312 | 313 +------------------------------+ 314 | CP | 315 | | 316 +------------------------------+ 318 Figure 1: High-level AAA framework in Multicast-Enabled Environments 320 Figure 1 322 For the sake of simplicity, the above diagram portrays a case where 323 there is a single NSP entity and a single CP entity (one-to-one 324 model), but multiple CPs can be connected to a single NSP (e.g. NSP 325 may provide connections to multiple CPs to provide a wide selection 326 of content categories: one-to-many model) It is also possible for a 327 single CP to be connected to multiple NSP networks (e.g. network 328 selection). Furthermore it is possible that the NSP and CP could be 329 the same entity. A NSP and CP authenticate and authorize each other 330 when they establish connectivity. Below the general case of multiple 331 NSPs with multiple CPs is explained. Then, the various combinations 332 of single and multiple CPs and NSPs are described in relation to the 333 general case. 335 4.1.1. Multiple CPs are connected to multiple NSPs 337 The user subscribes to multiple NSPs and multiple CPs in this usage 338 case. The user selects a CP and a NSP when the user requests 339 content. The NSP may be automatically selected by a user terminal: 341 e.g. a fixed line NSP by a set top box or a mobile NSP by a mobile 342 phone. In some usage cases it is possible that the NSP used by a 343 certain user will not always be the same. For example a user may 344 have contracted with more than one NSP: one for fixed line access and 345 another for mobile roaming access. 347 The content may be associated with (or managed by) a specific CP. In 348 this case, when the user selects content, the CP is automatically 349 selected. 351 Requests for multicast sent by the user to a selected NSP should 352 include enough information not only for authentication by the CP but 353 also for CP selection and admission control by the NSP. 355 When an NSP receives a request for multicast from a user, the NSP 356 requests the appropriate CP to make sure that the user is entitled to 357 access the corresponding content As the NSP is responsible for 358 managing its network resources, the NSP may perform admission 359 control.The NSP will allow access to the multicast service, depending 360 on both the response sent by the CP and the availability of resources 361 operated by the NSP. That is, the NSP will forward multicast traffic 362 towards the user only when the NSP has 1) made sure the user is 363 entitled to access the network resources operated by the NSP, 2) 364 received a confirmation from the CP that the user is entitled to 365 access the content and (possibly) 3) determined that the network 366 resources (e.g. bandwidth) are sufficient to deliver the multicast 367 traffic to the user with the relevant level of quality. When neither 368 of the first two conditions are met, the NSP will not forward 369 multicast traffic to the user. Condition #3 may also be a 370 showstopper. When the NSP already knows that network resources are 371 insufficient or there is a network failure, the NSP may choose to not 372 request the CP about the user's ability to retrieve content. The NSP 373 is also responsible for notifiying the user whether he/she is 374 eligible to receive content depending on the response sent by the CP. 375 In cases where the NSP does not start multicasting because of its own 376 network issues (e.g. lack of network resources or network failure), 377 the NSP notifies the user with a reason for rejecting the request. 379 A CP receives an inquiry from the NSP. The CP authenticates the 380 NSP's identity and makes an authorization decision regarding the 381 user's eligibility to access the requested contents. The CP is 382 responsible for the authentication and authorization of users so that 383 they can access the content managed by the CP. The CP notifies the 384 NSP accordingly. When the CP cannot (e.g. error or resource issues) 385 or decides not (e.g. policy issues) to deliver content, the CP is 386 responsible for notifying the NSP about the reason. It is up to the 387 NSP to relay or translate the reasons for rejection to the user. 389 A CP may delegate AAA responsibility to a NSP. 'AAA proxy in NSP' is 390 described in 4.7 for this case. 392 As defined in [I-D.ietf-mboned-maccnt-req], the CP may require the 393 retrieval of accounting information related to the access of its 394 content. 396 4.1.2. Multiple CPs are connected to a single NSP 398 The user subscribes to a single NSP which provides multicasting from 399 multiple CPs in this usage case. In this case the user does not 400 select an NSP. The user selects a CP when the user requests content. 401 The content may be associated with (or managed by) the specific CP, 402 so that when the user selects content, the CP is automatically 403 selected. 405 The user should send a request for multicast to the specific NSP with 406 enough information not only for authentication by the CP but also for 407 CP selection and admission control by the NSP. 409 The role of the NSP is the same as that described in 4.1.1. 411 The role of a CP is the same as that described in 4.1.1. 413 4.1.3. Multiple CPs are connected to a single NSP 415 In this usage case, a user subscribes to multiple NSPs but only a 416 single CP. A user selects the NSP when the user requests multicast 417 but the CP is fixed. The user should send a request for multicast to 418 the selected NSP with enough information not only for authentication 419 by the CP but also for admission control by the NSP. 421 The role of the NSP is similar to the description in 4.1.1, with the 422 exception that when a NSP receives a request from a user, NSP makes 423 an inquiry to the CP without CP selection. 425 The role of the CP is the same as that described in 4.1.1. 427 4.1.4. A single CP is connected to single NSP 429 In this case, a user subscribes to only one NSP and one CP. The user 430 does not select a NSP and CP in this scenario. Requests for 431 multicast sent by the user to a selected NSP should include enough 432 information not only for authentication by the CP but also for 433 admission control by the NSP. 435 The role for the NSP is the same as 4.1.3 The role of the CP is the 436 same as the description in 4.1.1. 438 The NSP and CP could be the same entity. In this case, the roles of 439 the NSP and CP may be combined. 441 4.2. User ID 443 Users may hold multiple user IDs: IDs which have been separately 444 assigned for each subscription to various NSPs and CPs. The NSPs and 445 CPs manage the user IDs for their respective domains. A CP 446 identifies a user by a user ID assigned by the CP itself. A NSP 447 identifies a user by a user ID assigned by the NSP itself. The user 448 IDs are only meaningful within the context of each domain. Users may 449 hold multiple user IDs which have been separately assigned for each 450 subscription they may have for various NSPs and CPs. 452 4.2.1. CP-assigned user ID 454 CPs assign user IDs to their users. The user may have more than one 455 CP-assigned user ID per specific CP. A user requests multicast to a 456 NSP, the CP-assigned user ID should be indicated so that the CP can 457 identify the user requesting content access. A NSP should notify the 458 CP- assigned user ID to the CP. A NSP should not share a CP- 459 assigned user ID with any CP except the one which assigned it and 460 should not relay it at all if there is no appropriate CP that 461 assigned the user ID. 463 4.2.2. NSP-assigned user ID 465 NSPs assign user IDs to their users. A user may have more than one 466 NSP-assigned user ID per a specific NSP. A user requests for 467 multicast to a NSP, the NSP-assigned user ID may be indicated in the 468 request so that the NSP can identify the user. The NSP should not 469 inform the NSP- assigned user ID to the CP for security reasons. The 470 NSP may identify the multicast-access user by other methods than the 471 NSP-assigned userID, e.g. by the access port. 473 The actual mapping rules for NSP-assigned user IDs with CP- user 474 assigned IDs in account logs is a matter for the providers and out of 475 the scope of this framework. 477 4.3. Accounting 479 There are some accounting issues specific to multicasting. An (S,G) 480 should be recorded as a channel identifier. The last hop device, 481 such as an IGMP or MLD router or an IGMP or MLD proxy, notifies the 482 NSP's mAAA function of the (S,G) channel identifier. The NSP should 483 notify the CP of the (S,G) information in the accounting report 484 messages. 486 A NSP records an accounting start corresponding to only the first 487 Join for a specific user-access session. A NSP should not treat a 488 "Join" response to a Query as the accounting start. 490 A NSP records an accounting stop triggered by any of the following: 491 1) a user requested Leave, 2) a timeout of a multicast state or 3) a 492 re-authentication failure. A NSP may also record an accounting stop 493 due to network availability reasons such as failure. The NSP logs 494 the reason for each accounting stop. 496 Intermittent logs between the join and leave would allow for finer 497 diagnostics and therefore could serve useful in billing 498 discrepancies, and provide for a better estimation of the time-span 499 that content was multicast, in the event that users disconnect 500 without sending leave messages. 502 There are two levels of accounting report messaging. Messages in 503 Accounting level 1 include a channel identifier, a user identifier, 504 and the accounting start and stop time information. Accounting level 505 2 includes all information of Level 1, plus traffic volume 506 information. 508 QoS class is an optional item for each accounting level. Whether to 509 send, and at what interval to send intermittent log information is 510 optional for both levels. CP and NSPs may also agree to include 511 additional option information in accounting messages of either level. 513 The level of account report messaging between the NSP and CP may be 514 either configured statically or can be dynamically requested by the 515 CP in its response to the Access-Request relayed by the NSP to the 516 CP. The determination of the actual level of report messaging is 517 configured by the NSP at the NAS. 519 In case of very fast channel changes, the amount of items logged by 520 the NSP could become high. In order to reduce the number of report 521 messages sent to the CP, the NSP can consolidate multiple sets of 522 accounting information inside a single accounting report message. 524 4.4. Access Control and CP selection by NSP 526 When a NSP receives an access request from a user, the NSP determines 527 to which CP the request is to be directed. The NSP may select a CP 528 based on CP-assigned userID with CP domain name or channel identifier 529 (S,G). The user should include in the request sufficient information 530 for CP selection. 532 4.5. Admission Control Information by NSP 534 After authorizing a user request, the NSP may have further conditions 535 for determining its admission control decision. 537 The NSP receives parameters (such as QoS class, required bandwidth, 538 burst-size, etc.) of multicast traffic. Such parameters serve as 539 information to be considered in the admission control decision. The 540 traffic parameters can be communicated as follows: 542 A CP may notify a mapping between the channel identifier (S,G) and 543 traffic parameters in the Response message when the CP authorizes 544 an access request. Such parameters may include required 545 bandwidth, burst-size, QoS class downgrade policy, etc. 547 A user may indicate in the Request willingness to accept QoS class 548 downgrade to best-effort streaming. 550 The NSP may maintain a mapping between channel identifier (S,G) 551 and traffic parameters in advance, for example pre-configured by 552 agreement between the CP and NSP on a per channel (S,G) basis. 554 The ultimate admission decision is made by the NSP based on required 555 traffic parameters of the requested, and available resources. In a 556 case that it cannot guarantee the required network resources for the 557 requested multicast traffic, streaming the requested multicast 558 traffic as best-effort is optional. The user may indicate in his/her 559 Access Request whether he/she will accept best-effort grade streaming 560 if guaranteed class is not available. The CP's preference for 561 accepting downgrading to best-effort streaming may be either 562 configured statically or can be dynamically requested by the CP in 563 its response to the Access-Request relayed by the NSP to the CP. In 564 the case that it cannot be offered a guaranteed QoS stream, the NSP 565 may decide either to decline admission or to stream the requested 566 multicast traffic as best-effort. The NSP should not stream best- 567 effort traffic if either the user or CP has indicated against best- 568 effort provision. 570 A NSP's admission control may manage integrated network resources for 571 unicast usage, such as VoIP or unicast streaming, and multicast 572 usage. Alternatively, it may manage network resources separately for 573 unicast and multicast usage. In either ease, AAA and admission 574 control framework for multicast usage is independent of unicast 575 admission control. 577 Such QoS measurement and policy mechanisms themselves depend on NSP 578 policies and are out of the scope of this memo. 580 4.6. Access Control and Distinguishing of Users by CP 582 The user ID and authentication information are forwarded 583 transparently by the NSP so that the CP can distinguish the user, as 584 well as authenticate and authorize the request. 586 4.7. AAA proxy in NSP 588 A NSP may act as AAA proxy of a CP based upon an agreement between 589 the NSP and the CP. The AAA proxy would store information about 590 permissions of a specific user to receive multicast data from 591 specified channel(s) up to specified expiration date(s) and time(s). 593 If such proxying is implemented, the NSP may receive authorization 594 conditions from a CP in advance and statically hold them, or a CP may 595 send them dynamically in the Response message. In either case, the 596 user has permission to receive multicast traffic and therefore the 597 NSP starts the multicasting without querying the CP. 599 The CP may send unsolicited requests to the NSP to refresh or change 600 the permissions for a user for specific group(s) or channel(s). 602 When a user is receiving multicast traffic while the permission is 603 about to expire, the NSP may send a notification to the user client 604 that his session is about to expire, and that he will need to re- 605 authenticate. In such a case, the user will have to send the Access- 606 Request. In the case that the user still has permission to the 607 content, they should be able to continue to receive the multicast 608 traffic without interruption. 610 When re-authentication fails, the NSP should stop the multicast 611 traffic and record accounting stop. 613 5. Network Connection Model and Functional Components 615 Section 3.1 introduced the high-level AAA framework for multicasting. 616 This section provides more detail on the network connection model and 617 constituent functional components. 619 5.1. Basic Connection Model 621 +------------------------------+ 622 | receiver | 623 | | 624 +------------------------------+ 625 | ^ Response 626 | Request | 627 V | 628 +------------------------------+ 629 | NSP's network | 630 | | 631 +------------------------------+ 632 | ^ Response 633 | Request | (Success) 634 v | 635 +------------------------------+ 636 | CP's network | 637 | | 638 +------------------------------+ 640 Figure 2: Basic Connection Model 642 Figure 2 644 In the simple case represented in Figure 1 the NSP is the sole entity 645 providing network resources including network access to the multicast 646 receiver. First a receiver sends a request for multicast (e.g. an 647 IGMP Report message) to an NSP which may then forward a mAAA request 648 towards the appropriate CP for authentication and authorization 649 purposes. The receiver gets information about a given multicast 650 group (*,G) or channel (S,G) corresponding to the content beforehand 651 for generating the request. The CP responds with either "success" or 652 "failure". If "success", the NSP grants access to the receiver and 653 forwards multicast traffic accordingly. 655 In this model the receiver selects the NSP to which the Join request 656 will be sent. Based on this request the NSP selects an appropriate 657 CP to which it forwards the corresponding mAAA request. The CP 658 responds to the NSP's m AAA request: it may not respond to another 659 NSP in regards to the request. 661 In this model, as described in section 4.1, the relationship between 662 NSP and CP can be one-to-one, one-to- many or many-to-many. 663 Receivers may connect to multiple networks. 665 5.2. Constituent Logical Functional Components of the fully enabled AAA 666 Framework 668 Requirements for "fully AAA and QoS enabled" IP multicasting networks 669 were defined in MACCNT-REQ-draft. To allow for levels of enablement, 670 this memo defines two models within the framework: "AAA enabled" 671 multicasting and "Fully enabled AAA" multicasting which means "AAA 672 enabled" with added admission control functions. 674 Section 3.1 introduces the high-level AAA framework for multicasting. 675 Below is a diagram of a AAA enabled multicasting network with AAA, 676 including the logical components within the various entities. 678 +-------------------------------+ 679 | user | 680 |+- - - - - - - - - - - - - - -+| 681 || CPE || 682 || || 683 |+- - - - - | - - - - - - - - -+| 684 +-----------|-------------------+ 685 | 686 -------|------ IFa 687 | 688 +-----------|-------------------+ 689 | NSP | | 690 |+- - - - - |- -_+ | 691 ||TS | | | 692 | +------|-+ | 693 || | AN | | | 694 | | |---------+ | 695 || +------|-+ | | | 696 | | IFb | | 697 || +------|-+ | | +---------+| 698 | | |----|-|mAAA || 699 || | NAS | | | |(MACF *) || * optional 700 | +--------+ +---------+| 701 ||+- - - - - - - + | | 702 +-----------------------|--------+ 703 | 704 -------|------ IFc 705 | 706 +-----------------------|-------+ 707 | CP +---------+ | 708 | | CP-AAA | | 709 | +---------+ | 710 +-------------------------------+ 712 Figure 3: AAA enabled framework (basic model) 714 Figure 3 716 The user entity includes the CPE (Customer Premise Equipment) which 717 connects the receiver (s). 719 The NSP (Network Service Provider) in the basic model includes the 720 transport system and a logical element for multicast AAA 721 functionality. The TS (transport system) is comprised of the access 722 node and NAS (Network Access Server) An AN (Access Node) may be 723 connected directly to mAAA or a NAS relays AAA information between an 724 AN and a mAAA. Descriptions of AN and its interfaces are out of the 725 scope for this memo. The multicast AAA function may be provided by a 726 mAAA which may include the function that downloads Join access 727 control lists to the NAS (this function is referred to conditional 728 access policy control function.) 730 Interface between mAAA and NAS 732 The interface between mAAA and the NAS is labeled IFb in Figure 2. 733 Over IFb the NAS sends an access request to the NSP-mAAA and the mAAA 734 replies. The mAAA may push conditional access policy to the NAS. 736 CP-AAA 738 The content provider may have its own AAA server which has the 739 authority over access policy for its contents. 741 Interface between user and NSP 743 The interface between the user and the NSP is labeled IFa in Figure 744 3. Over IFa the user makes a multicasting request to the NSP. The 745 NSP may in return forward multicast traffic depending on the NSP and 746 CP's policy decisions. 748 Interface between NSP and CP 750 The interface between the NSP and CP is labeled IFc. Over IFc the 751 NSP requests to the CP-AAA for access to contents and the CP replies. 752 CP may also send conditional access policy over this interface for 753 AAA-proxying. 755 +-------------------------------+ 756 | user | 757 |+- - - - - - - - - - - - - - -+| 758 || CPE || 759 || || 760 |+- - - - - | - - - - - - - - -+| 761 +-----------|-------------------+ 762 | 763 -------|------ IFa 764 | 765 +-----------|-----------------------+ 766 |+- - - - - |- - _+ + - - - - - + | 767 || | | | | | | 768 | +------|-+ | +--------+ | 769 || | AN | | | | | MACF || | 770 | | | | | | | 771 || +------|-+ | | | +---|----+| | 772 | | | | | | 773 | | | | IFd----- | | 774 | | | IFb | | | 775 || +------|---+ | | | +---|----+| | 776 | | |---|---| mAAA | | 777 || | NAS | | | | |(MACF *)|| | * optional 778 | +----------+ | +--------+ | 779 ||+- - - - - - - -+ - - |- - - - -+ | 780 +-----------------------|-----------+ 781 | 782 -------|------ IFc 783 | 784 +-----------------------|-------+ 785 | CP +---------+ | 786 | | CP-AAA | | 787 | +---------+ | 788 +-------------------------------+ 790 Figure 4: Fully enabled framework 792 Figure 4 794 In the fully enabled model the NSP also includes a component that 795 provides network resource management (e.g. QoS management), as 796 described in section 3.4, "Network Resource Management by NSP". In 797 the fully enabled model (Figure 3) resource management and admission 798 control is provided by MACF (Multicast Admission Control Function). 799 This means that, before replying to the user's multicast request, the 800 mAAA queries the MACF for a network resource access decision over the 801 interface IFd. The MACF is responsible for allocating network 802 resources for forwarding multicast traffic. MACF also receives Leave 803 information from NAS so that MACF releases corresponding reserved 804 resources. 806 5.3. Modularity of the framework 808 In the interest of flexibility, this framework is modular so that it 809 is possible that partially enabled versions of the models are 810 supported. A AAA-enabled version provides AAA functionality without 811 Network Resource management. A Network-Resource-Management-enabled 812 (QoS-enabled) version provides Network Resource management without 813 AAA functionality. Similarly, the possibility of one or more layers 814 of transit provision between an NSP and CP is in the interest of 815 modularity and extendibility. 817 6. IANA Considerations 819 This memo does not raise any IANA consideration issues. 821 7. Security Considerations 823 The user information related to authentication with the CP and the 824 information related to user accounting shared between the NSP and the 825 CP must be protected in some way. Otherwise, this memo does not 826 raise any new security issues which are not already addressed by the 827 original protocols. Enhancement of multicast access control 828 capabilities should enhance security performance. 830 8. Conclusion 832 This memo provides a generalized framework for solution standards to 833 meet the requirements. Further work should be done to specify the 834 interfaces between the user and NSP, NAS and mAAA, mAAA and MACF and 835 NSP-mAAA and CP-AAA (presented in 5.2.) 837 9. Normative References 839 [I-D.ietf-ancp-framework] 840 Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. 841 Wadhwa, "Framework and Requirements for an Access Node 842 Control Mechanism in Broadband Multi-Service Networks", 843 draft-ietf-ancp-framework-11 (work in progress), 844 July 2009. 846 [I-D.ietf-mboned-maccnt-req] 847 Hayashi, T., He, H., Satou, H., Ohta, H., and S. Vaidya, 848 "Requirements for Multicast AAA coordinated between 849 Content Provider(s) and Network Service Provider(s)", 850 draft-ietf-mboned-maccnt-req-08 (work in progress), 851 July 2009. 853 Authors' Addresses 855 Tsunemasa Hayashi 856 NTT Network Innovation Laboratories 857 1-1 Hikarino'oka 858 Yokosuka-shi, Kanagawa 239-0847 859 Japan 861 Phone: +81 46 859 8790 862 Email: hayashi.tsunemasa@lab.ntt.co.jp 864 Haixiang He 865 Nortel 866 600 Technology Park Drive 867 Billerica, MA 01801 868 USA 870 Phone: +1 978 288 7482 871 Email: haixiang@nortel.com 873 Hiroaki Satou 874 NTT Network Service Systems Laboratories 875 3-9-11 Midoricho 876 Musashino-shi, Tokyo 180-8585 877 Japan 879 Phone: +81 422 59 4683 880 Email: satou.hiroaki@lab.ntt.co.jp 881 Hiroshi Ohta 882 NTT Network Service Systems Laboratories 883 3-9-11 Midoricho 884 Musashino-shi, Tokyo 180-8585 885 Japan 887 Phone: +81 422 59 3617 888 Email: ohta.hiroshi@lab.ntt.co.jp 890 Christian Jacquenet 891 France Telecom 892 3, avenue Francois Chateau 893 CS 36901, Rennes Cedex 95134 894 France 896 Phone: +33 2 99 87 61 92 897 Email: christian.jacquenet@orange-ftgroup.com