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