idnits 2.17.1 draft-ietf-mboned-multiaaa-framework-07.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 24. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1023. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1035. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1043. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1049. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.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 Copyright Line does not match the current year == Unrecognized Status in '', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 1, 2008) is 5329 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-10) exists of draft-ietf-mboned-maccnt-req-06 ** Downref: Normative reference to an Informational draft: draft-ietf-mboned-maccnt-req (ref. 'I-D.mboned-maccnt-req') -- No information found for draft-ancp-framework - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.ancp-framework' Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft AAA and Admission Control Framework for 3 Multicasting July, 2008 5 Internet Draft Hiroaki Satou, NTT 6 Intended Status: Hiroshi Ohta, NTT 7 Informational 8 Expires: January Christian Jacquenet, France Telecom 9 3, 2009 10 Tsunemasa Hayashi, NTT 11 Haixiang He, Nortel Networks 13 July 1, 2008 15 AAA and Admission Control Framework for Multicasting 16 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents 21 that any applicable patent or other IPR claims of which he 22 or she is aware have been or will be disclosed, and any of 23 which he or she becomes aware will be disclosed, in 24 accordance with Section 6 of BCP 79. 26 Internet-Drafts are working documents of the Internet 27 Engineering Task Force (IETF), its areas, and its working 28 groups. Note that other groups may also distribute working 29 documents as Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of 32 six months and may be updated, replaced, or obsoleted by 33 other documents at any time. It is inappropriate to use 34 Internet-Drafts as reference material or to cite them other 35 than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be 41 accessed at http://www.ietf.org/shadow.html. 43 Internet Draft AAA and Admission Control Framework for 44 Multicasting July, 2008 46 This Internet-Draft will expire on January 3, 2009. 48 Copyright Notice 50 Copyright (C) The IETF Trust (2008). This document is 51 subject to the rights, licenses and restrictions contained 52 in BCP 78, and except as set forth therein, the authors 53 retain all their rights. 55 Abstract 57 IP multicast-based services, such as TV broadcasting or 58 videoconferencing raise the issue of making sure that 59 potential customers are fully entitled to access the 60 corresponding contents. There is indeed a need for service 61 and content providers to identify users (if not 62 authenticate, especially within the context of enforcing 63 electronic payment schemes) and to retrieve statistical 64 information for accounting purposes, as far as content and 65 network usage are concerned. This memo describes the 66 framework for specifying the Authorization, Authentication 67 and Accounting (AAA) capabilities that could be activated 68 within the context of the deployment and the operation of 69 IP multicast-based services. This framework addresses the 70 requirements presented in "Requirements for Accounting, 71 Authentication and Authorization in Well Managed IP 72 Multicasting Services" [I-D.mboned-maccnt-req]. The memo 73 provides a basic AAA enabled model as well as an extended 74 fully enabled model with resource and admission control 75 coordination. 77 Table of Contents 78 1. INTRODUCTION 4 79 1.1 PURPOSE AND BACKGROUND 4 80 2. DEFINITIONS AND ABBREVIATIONS 5 81 2.1 DEFINITIONS 5 82 2.2 ABBREVIATIONS 6 83 3. COMMON USE MODELS AND NETWORK ARCHITECTURE IMPLICATIONS 7 84 4. FRAMEWORK AND ROLES OF ENTITIES 9 85 4.1 "AAA FRAMEWORK IN MULTICAST-ENABLED ENVIRONMENTS 9 86 4.1.1 MULTIPLE CPS ARE CONNECTED TO MULTIPLE NSPS 9 87 4.1.2 MULTIPLE CPS ARE CONNECTED TO A SINGLE NSP 11 88 4.1.3 A SINGLE CP IS CONNECTED TO MULTIPLE NSPS 11 89 4.1.4 A SINGLE CP IS CONNECTED TO SINGLE NSP 11 90 4.2 USER ID 12 91 4.2.1 CP-ASSIGNED USER ID 12 92 4.2.2 NSP-ASSIGNED USER ID 12 93 4.3 ACCOUNTING 13 94 4.4 ACCESS CONTROL AND CP SELECTION BY NSP 14 95 4.5 ADMISSION CONTROL INFORMATION BY NSP 14 96 4.6 ACCESS CONTROL AND DISTINGUISHING OF USERS BY CP 15 97 Internet Draft AAA and Admission Control Framework for 98 Multicasting July, 2008 100 4.7 AAA PROXY IN NSP 15 101 5.1 BASIC CONNECTION MODEL 16 102 5.2 CONSTITUENT LOGICAL FUNCTIONAL COMPONENTS OF THE FULLY 103 ENABLED AAA FRAMEWORK 17 104 5.3 MODULARITY OF THE FRAMEWORK 21 105 6. IANA CONSIDERATIONS 21 106 7. SECURITY CONSIDERATIONS 21 107 8. CONCLUSION 21 109 1. Introduction 111 1.1 Purpose and Background 113 IP multicasting is designed to serve cases of group 114 communication schemes of any kind, such as one-to-many 115 (case of TV broadcasting services for example) or many-to- 116 many (case of videoconferencing services, for example). 118 In these environments, IP multicast provides a better 119 resource optimization than using a unicast transmission 120 scheme, where data need to be replicated as many times as 121 there are receivers. Activation of IP multicast 122 capabilities in networks yields the establishment and the 123 maintenance of multicast distribution trees that are 124 receiver-initiated by nature: multicast-formatted data are 125 forwarded to receivers who explicitly request them. 126 IP multicast-based services, such as TV broadcasting or 127 videoconferencing raise the issue of making sure that 128 potential customers are fully entitled to access the 129 corresponding contents. There is indeed a need for service 130 and content providers to identify (if not authenticate, 131 especially within the context of enforcing electronic 132 payment schemes) and to invoice such customers in a 133 reliable and efficient manner. Solutions should consider a 134 wide range of possible content delivery applications: 135 content delivered over the multicast network may include 136 video, audio, images, games, software and information such 137 as financial data, etc. 139 Internet Draft AAA and Admission Control Framework for 140 Multicasting July, 2008 142 This memo describes a framework for specifying the 143 Authorization, Authentication and Accounting (AAA) 144 capabilities that could be activated within the context of 145 the deployment and the operation of IP multicast-based 146 services. This memo also describes a framework to realize 147 high-quality multicast transport using a Multicast 148 Admission Control Function (MACF) with multicast 149 Authorization. 151 Specifically, this framework addresses the requirements 152 presented in "Requirements for Multicast AAA coordinated 153 between Content Provider(s) and Network Service 154 Provider(s)" which describes the requirements in CDN 155 services using IP multicast. The requirements are derived 156 from: 157 - need for user tracking and billing capabilities 158 - need for network access control to satisfy the 159 requirements of the Network Service Provider (NSP) and/or 160 content access control to satisfy the requirements of the 161 Content Provider (CP) 162 - methods for sharing information between the network 163 service provider and content provider to make it possible 164 to fulfill the above two requirements. [I-D.mboned-maccnt- 165 req] 167 Detailed requirements are presented in "Requirements for 168 Accounting, Authentication and Authorization in Well 169 Managed IP Multicasting Services" [I-D.mboned-maccnt-req]. 170 These requirements include mechanisms for recording end- 171 user requests and provider responses for content-delivery, 172 sharing user information (possibly anonymously depending on 173 the trust model) between content provider and network 174 service provider, and protecting resources through the 175 prevention of network and content access by unauthorized 176 users, as well as other AAA related requirements. 178 The purpose of this memo is to provide a generalized 179 framework for specifying multicast-inferred AAA 180 capabilities that can meet these requirements. This 181 framework is to provide a basis for future work of 182 investigating the applicability of existing AAA protocols 183 to provide these AAA capabilities in IP multicast specific 184 context and/or if deemed necessary, the refining or 185 defining of protocols to provide these capabilities. 187 2. Definitions and Abbreviations 189 2.1 Definitions 190 Internet Draft AAA and Admission Control Framework for 191 Multicasting July, 2008 193 For the purpose of this memo the following definitions 194 apply: 196 Accounting: The set of capabilities that allow the 197 retrieval of a set of statistical data that can be defined 198 on a per customer and/or a per service basis, within the 199 context of the deployment of multicast-based services. Such 200 data are retrieved for billing purposes, and can be 201 retrieved on a regular basis or upon unsolicited requests. 202 Such data include (but are not necessarily limited to) the 203 volume of multicast-formatted data that have been forwarded 204 to the receiver over a given period of time, the volume of 205 multicast-formatted data that have been exchanged between a 206 receiver (or set of) and a given source over a given period 207 of time (e.g. the duration of a multicast session), etc. 209 Authentication: action for identifying a user as a genuine 210 one. 212 Authorization: The set of capabilities that need to be 213 activated to make sure an authenticated user is fully 214 entitled to access a set of services. 216 Join: Signaling mechanism used by receivers to indicate 217 they want to access a multicast group and receive the 218 corresponding traffic. 220 Leave: Signaling mechanism used by receivers to indicate 221 they want to leave a multicast group and not receive the 222 corresponding traffic anymore. 224 Receiver: an end-host or end-client which receives content. 225 A receiver may be identified by a network ID such as MAC 226 address or IP address. 228 User: a human with a user account. A user may possibly use 229 multiple reception devices. Multiple users may use the 230 same reception device. (Note: The definition of a receiver 231 (device) and a user (human) should not be confused.) 233 2.2 Abbreviations 235 For the purpose of this draft the following abbreviations 236 apply: 238 AAA: Authentication.Authorization.and Accounting 240 ACL: Access Control List 242 Internet Draft AAA and Admission Control Framework for 243 Multicasting July, 2008 245 AN: Access Node 247 CDN: Content Delivery Network 249 CDS: Content Delivery Services 251 CP: Content Provider 253 CP-AAA: Authentication, Authorization, and Accounting 254 functions used by a Content Provider 256 CPE: Customer Premise Equipment 258 ID: Identifier 260 IF: network interface 262 mAAA: Authentication, Authorization, and Accounting 263 functions activated in multicast-enabled environments 265 MACF: Multicast Admission Control Function 267 NAS: Network Access Server (RFC2881) 269 NSP: Network Service Provider 271 NSP-mAAA: Authentication, Authorization, and Accounting 272 functions used by a Network Service provider 274 QoS: Quality of Service 276 3. Common use models and network architecture implications 278 In some cases a single entity may design and be responsible 279 for a system that covers the various common high-level 280 requirements of a multicasting system such as 1) content 281 serving, 2) the infrastructure to multicast it, 3) network 282 and content access control mechanisms. 284 In many cases however the content provision and network 285 provision roles are divided between separate entities. 286 Commonly, Content Providers (CP) do not build and maintain 287 their own multicast network infrastructure as this is not 288 their primary business area. CP often purchase transport 289 and management services from network service providers 290 instead. Similarly Network Service Providers (NSP) may not 291 make their business in providing content. [I-D.mboned- 292 maccnt-req] provides more detail of the multiple versus 294 Internet Draft AAA and Admission Control Framework for 295 Multicasting July, 2008 297 single-entity Content Delivery Service (CDS) network 298 models. 300 In the usage model where a single NSP provides multicast 301 services to multiple CPs, the following general 302 requirements from [I-D.mboned-maccnt-req] apply: 304 -Need for user tracking and billing capabilities 305 -Need for QoS control such as resource management and 306 admission control 307 -Need for conditional multicast access control 308 satisfactory to the requirements of the CP 309 -Methods for sharing information between the NSP and 310 CP to make the above two possible 312 When the NSP and CP are the same single entity then the 313 general requirements are as follows. 315 -Need for user tracking and user-billing capabilities 316 -Need for access control and/or content protection at 317 level the entity deems appropriate 319 Internet Draft AAA and Admission Control Framework for 320 Multicasting July, 2008 322 4. Framework and Roles of Entities 324 4.1 AAA Framework in Multicast-Enabled Environments 326 A general high-level framework is depicted in Figure 1. 328 +------------------------------+ 329 | user | 330 | | 331 +------------------------------+ 332 | 333 | 334 | 335 +------------------------------+ 336 | NSP | 337 | | 338 +------------------------------+ 339 | 340 | 341 | 342 +------------------------------+ 343 | CP | 344 | | 345 +------------------------------+ 347 Figure 1: High-level AAA framework in Multicast-Enabled 348 Environments 350 For the sake of simplicity, the above diagram portrays a 351 case where there is a single NSP entity and a single CP 352 entity (one-to-one model), but multiple CPs can be 353 connected to a single NSP (e.g. NSP may provide connections 354 to multiple CPs to provide a wide selection of content 355 categories: one-to-many model) It is also possible for a 356 single CP to be connected to multiple NSP networks (e.g. 357 network selection). Furthermore it is possible that the NSP 358 and CP could be the same entity. A NSP and CP authenticate 359 and authorize each other when they establish connectivity. 360 Below the general case of multiple NSPs with multiple CPs 361 is explained. Then, the various combinations of single and 362 multiple CPs and NSPs are described in relation to the 363 general case. 365 4.1.1 Multiple CPs are connected to multiple NSPs 367 The user subscribes to multiple NSPs and multiple CPs in 368 this usage case. The user selects a CP and a NSP when the 369 user requests content. The NSP may be automatically 370 selected by a user terminal: e.g. a fixed line NSP by a set 371 top box or a mobile NSP by a mobile phone. In some usage 373 Internet Draft AAA and Admission Control Framework for 374 Multicasting July, 2008 376 cases it is possible that the NSP used by a certain user 377 will not always be the same. For example a user may have 378 contracted with more than one NSP: one for fixed line 379 access and another for mobile roaming access. 381 The content may be associated with (or managed by) a 382 specific CP. In this case, when the user selects content, 383 the CP is automatically selected. 385 Requests for multicast sent by the user to a selected NSP 386 should include enough information not only for 387 authentication by the CP but also for CP selection and 388 admission control by the NSP. 390 When an NSP receives a request for multicast from a user, 391 the NSP requests the appropriate CP to make sure that the 392 user is entitled to access the corresponding content As 393 the NSP is responsible for managing its network resources, 394 the NSP may perform admission control.The NSP will allow 395 access to the multicast service, depending on both the 396 response sent by the CP and the availability of resources 397 operated by the NSP. That is, the NSP will forward 398 multicast traffic towards the user only when the NSP has 1) 399 made sure the user is entitled to access the network 400 resources operated by the NSP, 2) received a confirmation 401 from the CP that the user is entitled to access the content 402 and (possibly) 3) determined that the network resources 403 (e.g. bandwidth) are sufficient to deliver the multicast 404 traffic to the user with the relevant level of quality. 405 When neither of the first two conditions are met, the NSP 406 will not forward multicast traffic to the user. Condition 407 #3 may also be a showstopper. When the NSP already knows 408 that network resources are insufficient or there is a 409 network failure, the NSP may choose to not request the CP 410 about the user's ability to retrieve content. The NSP is 411 also responsible for notifiying the user whether he/she is 412 eligible to receive content depending on the response sent 413 by the CP. In cases where the NSP does not start 414 multicasting because of its own network issues (e.g. lack 415 of network resources or network failure), the NSP notifies 416 the user with a reason for rejecting the request. 418 A CP receives an inquiry from the NSP. The CP authenticates 419 the NSP's identity and makes an authorization decision 420 regarding the user's eligibility to access the requested 421 contents. The CP is responsible for the authentication 422 and authorization of users so that they can access the 423 content managed by the CP. The CP notifies the NSP 424 accordingly. When the CP cannot (e.g. error or resource 425 issues) or decides not (e.g. policy issues) to deliver 427 Internet Draft AAA and Admission Control Framework for 428 Multicasting July, 2008 430 content, the CP is responsible for notifying the NSP about 431 the reason. It is up to the NSP to relay or translate the 432 reasons for rejection to the user. 434 A CP may delegate AAA responsibility to a NSP. 'AAA proxy 435 in NSP' is described in 4.7 for this case. 437 As defined in [I-D.mboned-maccnt-req], the CP may require 438 the retrieval of accounting information related to the 439 access of its content. 441 4.1.2 Multiple CPs are connected to a single NSP 443 The user subscribes to a single NSP which provides 444 multicasting from multiple CPs in this usage case. In this 445 case the user does not select an NSP. The user selects a 446 CP when the user requests content. The content may be 447 associated with (or managed by) the specific CP, so that 448 when the user selects content, the CP is automatically 449 selected. 451 The user should send a request for multicast to the 452 specific NSP with enough information not only for 453 authentication by the CP but also for CP selection and 454 admission control by the NSP. 456 The role of the NSP is the same as that described in 4.1.1. 458 The role of a CP is the same as that described in 4.1.1. 460 4.1.3 A single CP is connected to multiple NSPs 462 In this usage case, a user subscribes to multiple NSPs but 463 only a single CP. A user selects the NSP when the user 464 requests multicast but the CP is fixed. The user should 465 send a request for multicast to the selected NSP with 466 enough information not only for authentication by the CP 467 but also for admission control by the NSP. 469 The role of the NSP is similar to the description in 4.1.1, 470 with the exception that when a NSP receives a request from 471 a user, NSP makes an inquiry to the CP without CP selection. 473 The role of the CP is the same as that described in 4.1.1. 475 4.1.4 A single CP is connected to single NSP 477 In this case, a user subscribes to only one NSP and one CP. 478 The user does not select a NSP and CP in this scenario. 479 Requests for multicast sent by the user to a selected NSP 481 Internet Draft AAA and Admission Control Framework for 482 Multicasting July, 2008 484 should include enough information not only for 485 authentication by the CP but also for admission control by 486 the NSP. 488 The role for the NSP is the same as 4.1.3 489 The role of the CP is the same as the description in 4.1.1. 491 The NSP and CP could be the same entity. In this case, the 492 roles of the NSP and CP may be combined. 494 4.2 User ID 496 Users may hold multiple user IDs: IDs which have been 497 separately assigned for each subscription to various NSPs 498 and CPs. The NSPs and CPs manage the user IDs for their 499 respective domains. A CP identifies a user by a user ID 500 assigned by the CP itself. A NSP identifies a user by a 501 user ID assigned by the NSP itself. The user IDs are only 502 meaningful within the context of each domain. Users may 503 hold multiple user IDs which have been separately assigned 504 for each subscription they may have for various NSPs and 505 CPs. 507 4.2.1 CP-assigned user ID 509 CPs assign user IDs to their users. The user may have more 510 than one CP-assigned user ID per specific CP. A user 511 requests multicast to a NSP, the CP-assigned user ID should 512 be indicated so that the CP can identify the user 513 requesting content access. A NSP should notify the CP- 514 assigned user ID to the CP. A NSP should not share a CP- 515 assigned user ID with any CP except the one which assigned 516 it and should not relay it at all if there is no 517 appropriate CP that assigned the user ID. 519 4.2.2 NSP-assigned user ID 521 NSPs assign user IDs to their users. A user may have more 522 than one NSP-assigned user ID per a specific NSP. A user 523 requests for multicast to a NSP, the NSP-assigned user ID 524 may be indicated in the request so that the NSP can 525 identify the user. The NSP should not inform the NSP- 526 assigned user ID to the CP for security reasons. The NSP 527 may identify the multicast-access user by other methods 528 than the NSP-assigned userID, e.g. by the access port. 530 Internet Draft AAA and Admission Control Framework for 531 Multicasting July, 2008 533 The actual mapping rules for NSP-assigned user IDs with CP- 534 user assigned IDs in account logs is a matter for the 535 providers and out of the scope of this framework. 537 4.3 Accounting 539 There are some accounting issues specific to multicasting. 540 An (S,G) should be recorded as a channel identifier. The 541 last hop device, such as an IGMP or MLD router or an IGMP 542 or MLD proxy, notifies the NSP's mAAA function of the (S,G) 543 channel identifier. The NSP should notify the CP of the 544 (S,G) information in the accounting report messages. 546 A NSP records an accounting start corresponding to only the 547 first Join for a specific user-access session. A NSP should 548 not treat a "Join" response to a Query as the accounting 549 start. 551 A NSP records an accounting stop triggered by any of the 552 following: 1) a user requested Leave, 2) a timeout of a 553 multicast state or 3) a re-authentication failure. A NSP 554 may also record an accounting stop due to network 555 availability reasons such as failure. The NSP logs the 556 reason for each accounting stop. 558 Intermittent logs between the join and leave would allow 559 for finer diagnostics and therefore could serve useful in 560 billing discrepancies, and provide for a better estimation 561 of the time-span that content was multicast, in the event 562 that users disconnect without sending leave messages. 564 There are two levels of accounting report messaging. 565 Messages in Accounting level 1 include a channel identifier, 566 a user identifier, and the accounting start and stop time 567 information. Accounting level 2 includes all information of 568 Level 1, plus traffic volume information. 570 QoS class is an optional item for each accounting level. 571 Whether to send, and at what interval to send intermittent 572 log information is optional for both levels. CP and NSPs 573 may also agree to include additional option information in 574 accounting messages of either level. 576 The level of account report messaging between the NSP and 577 CP may be either configured statically or can be 578 dynamically requested by the CP in its response to the 579 Access-Request relayed by the NSP to the CP. The 580 determination of the actual level of report messaging is 581 configured by the NSP at the NAS. 583 Internet Draft AAA and Admission Control Framework for 584 Multicasting July, 2008 586 In case of very fast channel changes, the amount of items 587 logged by the NSP could become high. In order to reduce 588 the number of report messages sent to the CP, the NSP can 589 consolidate multiple sets of accounting information inside 590 a single accounting report message. [I-D.ancp-framework] 592 4.4 Access Control and CP selection by NSP 594 When a NSP receives an access request from a user, the NSP 595 determines to which CP the request is to be directed. The 596 NSP may select a CP based on CP-assigned userID with CP 597 domain name or channel identifier (S,G). The user should 598 include in the request sufficient information for CP 599 selection. 601 4.5 Admission Control Information by NSP 603 After authorizing a user request, the NSP may have further 604 conditions for determining its admission control decision. 606 The NSP receives parameters (such as QoS class, required 607 bandwidth, burst-size, etc.) of multicast traffic. Such 608 parameters serve as information to be considered in the 609 admission control decision. The traffic parameters can be 610 communicated as follows: 611 - A CP may notify a mapping between the channel 612 identifier (S,G) and traffic parameters in the Response 613 message when the CP authorizes an access request. Such 614 parameters may include required bandwidth, burst-size, QoS 615 class downgrade policy, etc. 616 - A user may indicate in the Request willingness to 617 accept QoS class downgrade to best-effort streaming. 618 - The NSP may maintain a mapping between channel 619 identifier (S,G) and traffic parameters in advance, for 620 example pre-configured by agreement between the CP and NSP 621 on a per channel (S,G) basis. 623 The ultimate admission decision is made by the NSP based on 624 required traffic parameters of the requested, and available 625 resources. In a case that it cannot guarantee the required 626 network resources for the requested multicast traffic, 627 streaming the requested multicast traffic as best-effort is 628 optional. The user may indicate in his/her Access 629 Request whether he/she will accept best-effort grade 630 streaming if guaranteed class is not available. The CP's 631 preference for accepting downgrading to best-effort 632 streaming may be either configured statically or can be 633 dynamically requested by the CP in its response to the 635 Internet Draft AAA and Admission Control Framework for 636 Multicasting July, 2008 638 Access-Request relayed by the NSP to the CP. In the case 639 that it cannot be offered a guaranteed QoS stream, the NSP 640 may decide either to decline admission or to stream the 641 requested multicast traffic as best-effort. The NSP should 642 not stream best-effort traffic if either the user or CP has 643 indicated against best-effort provision. 645 A NSP's admission control may manage integrated network 646 resources for unicast usage, such as VoIP or unicast 647 streaming, and multicast usage. Alternatively, it may 648 manage network resources separately for unicast and 649 multicast usage. In either ease, AAA and admission control 650 framework for multicast usage is independent of unicast 651 admission control. 653 Such QoS measurement and policy mechanisms themselves 654 depend on NSP policies and are out of the scope of this 655 memo. 657 4.6 Access Control and Distinguishing of Users by CP 659 The user ID and authentication information are forwarded 660 transparently by the NSP so that the CP can distinguish the 661 user, as well as authenticate and authorize the request. 663 4.7 AAA proxy in NSP 665 A NSP may act as AAA proxy of a CP based upon an agreement 666 between the NSP and the CP. The AAA proxy would store 667 information about permissions of a specific user to receive 668 multicast data from specified channel(s) up to specified 669 expiration date(s) and time(s). 671 If such proxying is implemented, the NSP may receive 672 authorization conditions from a CP in advance and 673 statically hold them, or a CP may send them dynamically in 674 the Response message. In either case, the user has 675 permission to receive multicast traffic and therefore the 676 NSP starts the multicasting without querying the CP. 678 The CP may send unsolicited requests to the NSP to refresh 679 or change the permissions for a user for specific group(s) 680 or channel(s). 682 When a user is receiving multicast traffic while the 683 permission is about to expire, the NSP may send a 684 notification to the user client that his session is about 685 to expire, and that he will need to re-authenticate. In 686 such a case, the user will have to send the Access-Request. 687 In the case that the user still has permission to the 689 Internet Draft AAA and Admission Control Framework for 690 Multicasting July, 2008 692 content, they should be able to continue to receive the 693 multicast traffic without interruption. 695 When re-authentication fails, the NSP should stop the 696 multicast traffic and record accounting stop. 698 5. Network Connection Model and Functional Components 700 Section 3.1 introduced the high-level AAA framework for 701 multicasting. This section provides more detail on the 702 network connection model and constituent functional 703 components. 705 5.1 Basic Connection Model 707 +------------------------------+ 708 | receiver | 709 | | 710 +------------------------------+ 711 | ^ Response 712 | Request | 713 V | 714 +------------------------------+ 715 | NSP's network | 716 | | 717 +------------------------------+ 718 | ^ Response 719 | Request | (Success) 720 v | 721 +------------------------------+ 722 | CP's network | 723 | | 724 +------------------------------+ 726 Figure 2: Basic Connection Model 728 In the simple case represented in Figure 1 the NSP is the 729 sole entity providing network resources including network 730 access to the multicast receiver. First a receiver sends a 731 request for multicast (e.g. an IGMP Report message) to an 732 NSP which may then forward a mAAA request towards the 733 appropriate CP for authentication and authorization 734 purposes. The receiver gets information about a given 735 multicast group (*,G) or channel (S,G) corresponding to the 736 content beforehand for generating the request. The CP 737 responds with either "success" or "failure". If "success", 738 the NSP grants access to the receiver and forwards 739 multicast traffic accordingly. 741 Internet Draft AAA and Admission Control Framework for 742 Multicasting July, 2008 744 In this model the receiver selects the NSP to which the 745 Join request will be sent. Based on this request the NSP 746 selects an appropriate CP to which it forwards the 747 corresponding mAAA request. The CP responds to the NSP's m 748 AAA request: it may not respond to another NSP in regards 749 to the request. 751 In this model, as described in section 4.1, the 752 relationship between NSP and CP can be one-to-one, one-to- 753 many or many-to-many. Receivers may connect to multiple 754 networks. 756 5.2 Constituent Logical Functional Components of the fully 757 enabled AAA Framework 759 Requirements for "fully AAA and QoS enabled" IP 760 multicasting networks were defined in MACCNT-REQ-draft. To 761 allow for levels of enablement, this memo defines two 762 models within the framework: "AAA enabled" multicasting and 763 "Fully enabled AAA" multicasting which means "AAA enabled" 764 with added admission control functions. 766 Section 3.1 introduces the high-level AAA framework for 767 multicasting. Below is a diagram of a AAA enabled 768 multicasting network with AAA, including the logical 769 components within the various entities. 771 Internet Draft AAA and Admission Control Framework for 772 Multicasting July, 2008 774 +-------------------------------+ 775 | user | 776 |+- - - - - - - - - - - - - - -+| 777 || CPE || 778 || || 779 |+- - - - - | - - - - - - - - -+| 780 +-----------|-------------------+ 781 | 782 -------|------ IFa 783 | 784 +-----------|-------------------+ 785 | NSP | | 786 |+- - - - - |- -_+ | 787 ||TS | | | 788 | +------|-+ | 789 || | AN | | | 790 | | |---------+ | 791 || +------|-+ | | | 792 | | IFb | | 793 || +------|-+ | | +---------+| 794 | | |----|-|mAAA || 795 || | NAS | | | |(MACF *) || * optional 796 | +--------+ +---------+| 797 ||+- - - - - - - + | | 798 +-----------------------|--------+ 799 | 800 -------|------ IFc 801 | 802 +-----------------------|-------+ 803 | CP +---------+ | 804 | | CP-AAA | | 805 | +---------+ | 806 +-------------------------------+ 807 Figure 3: AAA enabled framework (basic model) 809 The user entity includes the CPE (Customer Premise 810 Equipment) which connects the receiver (s). 812 The NSP (Network Service Provider) in the basic model 813 includes the transport system and a logical element for 814 multicast AAA functionality. The TS (transport system) is 815 comprised of the access node and NAS (Network Access 816 Server) An AN (Access Node) may be connected directly to 817 mAAA or a NAS relays AAA information between an AN and a 818 mAAA. Descriptions of AN and its interfaces are out of the 819 scope for this memo. The multicast AAA function may be 820 provided by a mAAA which may include the function that 822 Internet Draft AAA and Admission Control Framework for 823 Multicasting July, 2008 825 downloads Join access control lists to the NAS (this 826 function is referred to conditional access policy control 827 function.) 829 Interface between mAAA and NAS 831 The interface between mAAA and the NAS is labeled IFb in 832 Figure 2. Over IFb the NAS sends an access request to the 833 NSP-mAAA and the mAAA replies. The mAAA may push 834 conditional access policy to the NAS. 836 CP-AAA 837 The content provider may have its own AAA server which has 838 the authority over access policy for its contents. 840 Interface between user and NSP 841 The interface between the user and the NSP is labeled IFa 842 in Figure 3. Over IFa the user makes a multicasting 843 request to the NSP. The NSP may in return forward 844 multicast traffic depending on the NSP and CP's policy 845 decisions. 847 Interface between NSP and CP 848 The interface between the NSP and CP is labeled IFc. Over 849 IFc the NSP requests to the CP-AAA for access to contents 850 and the CP replies. CP may also send conditional access 851 policy over this interface for AAA-proxying. 853 Internet Draft AAA and Admission Control Framework for 854 Multicasting July, 2008 856 +-------------------------------+ 857 | user | 858 |+- - - - - - - - - - - - - - -+| 859 || CPE || 860 || || 861 |+- - - - - | - - - - - - - - -+| 862 +-----------|-------------------+ 863 | 864 -------|------ IFa 865 | 866 +-----------|-----------------------+ 867 |+- - - - - |- - _+ + - - - - - + | 868 || | | | | | | 869 | +------|-+ | +--------+ | 870 || | AN | | | | | MACF || | 871 | | | | | | | 872 || +------|-+ | | | +---|----+| | 873 | | | | | | 874 | | | | IFd----- | | 875 | | | IFb | | | 876 || +------|---+ | | | +---|----+| | 877 | | |---|---| mAAA | | 878 || | NAS | | | | |(MACF *)|| | * optional 879 | +----------+ | +--------+ | 880 ||+- - - - - - - -+ - - |- - - - -+ | 881 +-----------------------|-----------+ 882 | 883 -------|------ IFc 884 | 885 +-----------------------|-------+ 886 | CP +---------+ | 887 | | CP-AAA | | 888 | +---------+ | 889 +-------------------------------+ 891 Figure 4: Fully enabled framework 893 In the fully enabled model the NSP also includes a 894 component that provides network resource management (e.g. 895 QoS management), as described in section 3.4, "Network 896 Resource Management by NSP". In the fully enabled model 897 (Figure 3) resource management and admission control is 898 provided by MACF (Multicast Admission Control Function). 899 This means that, before replying to the user's multicast 900 request, the mAAA queries the MACF for a network resource 901 access decision over the interface IFd. The MACF is 902 responsible for allocating network resources for forwarding 903 multicast traffic. MACF also receives Leave information 904 from NAS so that MACF releases corresponding reserved 905 resources. 907 Internet Draft AAA and Admission Control Framework for 908 Multicasting July, 2008 910 5.3 Modularity of the framework 912 In the interest of flexibility, this framework is modular 913 so that it is possible that partially enabled versions of 914 the models are supported. A AAA-enabled version provides 915 AAA functionality without Network Resource management. A 916 Network-Resource-Management-enabled (QoS-enabled) version 917 provides Network Resource management without AAA 918 functionality. Similarly, the possibility of one or more 919 layers of transit provision between an NSP and CP is in the 920 interest of modularity and extendibility. 922 6. IANA considerations 924 This memo does not raise any IANA consideration issues. 926 7. Security considerations 928 The user information related to authentication with the CP 929 and the information related to user accounting shared 930 between the NSP and the CP must be protected in some way. 931 Otherwise, this memo does not raise any new security issues 932 which are not already addressed by the original protocols. 933 Enhancement of multicast access control capabilities should 934 enhance security performance. 936 8. Conclusion 938 This memo provides a generalized framework for solution 939 standards to meet the requirements. Further work should be 940 done to specify the interfaces between the user and NSP, 941 NAS and mAAA, mAAA and MACF and NSP-mAAA and CP-AAA 942 (presented in 5.2.) 944 Normative References 946 [I-D.mboned-maccnt-req] 947 Hayashi, et. al., "Requirements for Multicast AAA 948 coordinated between Content Provider(s) and Network 949 Service Provider(s)", draft-ietf-mboned-maccnt-req- 950 06.txt, June 2008, Work in Progress. 952 [I-D.ancp-framework] 953 Ooghe, et. al, "Framework and Requirements for an 954 Access Node Control Mechanism in Broadband Multi- 956 Internet Draft AAA and Admission Control Framework for 957 Multicasting July, 2008 959 Service Networks", draft-ietf-ancp-framework-04.txt, 960 November 2007, Work in Progress. 962 Authors' Addresses 964 Hiroaki Satou 965 NTT Network Service Systems Laboratories 966 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 967 Japan 968 Phone : +81 422 59 4683 969 Email : satou.hiroaki@lab.ntt.co.jp 971 Hiroshi Ohta 972 NTT Network Service Systems Laboratories 973 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 974 Japan 975 Phone : +81 422 59 3617 976 Email: ohta.hiroshi@lab.ntt.co.jp 978 Christian Jacquenet 979 France Telecom 980 3, avenue Francois Chateau 981 CS 36901, 35069 Rennes Cedex, France 982 Phone: +33 2 99 87 61 92 983 Email: christian.jacquenet@orange-ftgroup.com 985 Tsunemasa Hayashi 986 NTT Network Innovation Laboratories 987 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 988 Japan 989 Phone: +81 46 859 8790 990 Email: tsunemasa@gmail.com 992 Haixiang He 993 Nortel 994 600 Technology Park Drive 995 Billerica, MA 01801, USA 996 Phone: +1 978 288 7482 997 Email: haixiang@nortel.com 999 Comments 1000 Comments are solicited and should be addressed to the 1001 mboned working group's mailing list at 1002 mboned@lists.uoregon.edu_and/or the authors. 1004 Internet Draft AAA and Admission Control Framework for 1005 Multicasting July, 2008 1007 Full Copyright Statement 1009 Copyright (C) The IETF Trust (2008). 1011 This document is subject to the rights, licenses and 1012 restrictions contained in BCP 78, and except as set forth 1013 therein, the authors retain all their rights. 1015 This document and the information contained herein are 1016 provided on an "AS IS" basis and THE CONTRIBUTOR, THE 1017 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), 1018 THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET 1019 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1020 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 1021 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS 1022 OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR 1023 A PARTICULAR PURPOSE. 1025 Intellectual Property 1027 The IETF takes no position regarding the validity or scope 1028 of any Intellectual Property Rights or other rights that 1029 might be claimed to pertain to the implementation or use 1030 of the technology described in this document or the extent 1031 to which any license under such rights might or might not 1032 be available; nor does it represent that it has made any 1033 independent effort to identify any such rights. 1034 Information on the procedures with respect to rights in RFC 1035 documents can be found in BCP 78 and BCP 79. 1037 Copies of IPR disclosures made to the IETF Secretariat and 1038 any assurances of licenses to be made available, or the 1039 result of an attempt made to obtain a general license or 1040 permission for the use of such proprietary rights by 1041 implementers or users of this specification can be 1042 obtained from the IETF on-line IPR repository at 1043 http://www.ietf.org/ipr. 1045 The IETF invites any interested party to bring to its 1046 attention any copyrights, patents or patent applications, 1047 or other proprietary rights that may cover technology that 1048 may be required to implement this standard. Please 1049 address the information to the IETF at ietf-ipr@ietf.org. 1051 Expiration 1053 This Internet-Draft will expire on January 3, 2009. 1055 Acknowledgement 1057 Funding for the RFC Editor function is currently provided 1058 by the Internet Society.