--- 1/draft-ietf-mboned-multiaaa-framework-04.txt 2007-11-19 22:15:26.000000000 +0100 +++ 2/draft-ietf-mboned-multiaaa-framework-05.txt 2007-11-19 22:15:26.000000000 +0100 @@ -1,82 +1,125 @@ - Internet Draft AAA Framework for Multicasting + Internet Draft AAA Framework for Multicasting November + 2007 + Hiroaki Satou, NTT Internet Draft Hiroshi Ohta, NTT - Expires: Jan 10, 2008 Christian Jacquenet, France Telecom - Intended status: Informational Tsunemasa Hayashi, NTT + Expires: May 17, Christian Jacquenet, France Telecom + 2008 + Tsunemasa Hayashi, NTT Haixiang He, Nortel Networks - July 9, 2007 + November 19, 2007 AAA Framework for Multicasting - + Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 - of BCP 79. + aware will be disclosed, in accordance with Section + 6 of BCP 79. - Internet-Drafts are working documents of the Internet - Engineering Task Force (IETF), its areas, and its - working groups. Note that other groups may also - distribute working documents as Internet-Drafts. + Internet-Drafts are working documents of the + Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may + also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. - Internet Draft AAA Framework for Multicasting + Internet Draft AAA Framework for Multicasting November + 2007 + The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on January 10, 2008. + This Internet-Draft will expire on May 17, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth - therein, the authors retain all their rights. + contained in BCP 78, and except as set forth therein, + the authors retain all their rights. Abstract IP multicast-based services, such as TV broadcasting or videoconferencing raise the issue of making sure - that potential customers are fully entitled to access - the corresponding contents. There is indeed a need - for service and content providers to identify (if not - authenticate, especially within the context of - enforcing electronic payment schemes) and to invoice - such customers in a reliable and efficient manner. - This memo describes the framework for specifying the - Authorization, Authentication and Accounting (AAA) - capabilities that could be activated within the - context of the deployment and the operation of IP - multicast-based services. This framework addresses - the requirements presented in draft-ietf-mboned- - maccnt-req-04.txt, "Requirements for Accounting, - Authentication and Authorization in Well Managed IP - Multicasting Services". The memo provides a basic AAA - enabled model as well as an extended fully enabled - model with resource and admission control - coordination. + that potential customers are fully entitled to + access the corresponding contents. There is indeed a + need for service and content providers to identify + (if not authenticate, especially within the context + of enforcing electronic payment schemes) and to + invoice such customers in a reliable and efficient + manner. This memo describes the framework for + specifying the Authorization, Authentication and + Accounting (AAA) capabilities that could be + activated within the context of the deployment and + the operation of IP multicast-based services. This + framework addresses the requirements presented in + draft-ietf-mboned-maccnt-req-04.txt, "Requirements + for Accounting, Authentication and Authorization in + Well Managed IP Multicasting Services". The memo + provides a basic AAA enabled model as well as an + extended fully enabled model with resource and + admission control coordination. + STATUS OF THIS MEMO 1 + COPYRIGHT NOTICE 2 + ABSTRACT 2 + 1. INTRODUCTION 5 + 1.1 PURPOSE AND BACKGROUND 5 + 2. DEFINITIONS AND ABBREVIATIONS 6 + 2.1 DEFINITIONS 6 + 2.2 ABBREVIATIONS 7 + 3. COMMON USE MODELS AND NETWORK ARCHITECTURE IMPLICATIONS 7 + 4. FRAMEWORK AND ROLES OF ENTITIES 8 + 4.1 FRAMEWORK FOR MULTICAST AAA 8 + 4.1.1 MULTIPLE CPS ARE CONNECTED TO MULTIPLE NSPS 9 + 4.1.2 MULTIPLE CPS ARE CONNECTED TO A SINGLE NSP 10 + 4.1.3 A SINGLE CP IS CONNECTED TO MULTIPLE NSPS 11 + 4.1.4 A SINGLE CP IS CONNECTED TO SINGLE NSP 11 + 4.2 USER ID 11 + 4.2.1 CP-ASSIGNED USER ID 12 + 4.2.2 NSP-ASSIGNED USER ID 12 + 4.3 ACCOUNTING 12 + 4.4 ACCESS CONTROL AND CP SELECTION BY NSP 13 + 4.5 ADMISSION CONTROL INFORMATION BY NSP 13 + 4.6 ACCESS CONTROL AND DISTINGUISHING OF USERS BY CP 14 + 4.7 AAA PROXY IN NSP 14 + 5.1 BASIC CONNECTION MODEL 14 + 5.2 CONSTITUENT LOGICAL FUNCTIONAL COMPONENTS OF THE FULLY + ENABLED AAA FRAMEWORK 15 + 5.3 MODULARITY OF THE FRAMEWORK 19 + 6. IANA CONSIDERATIONS 19 + 7. SECURITY CONSIDERATIONS 19 + 8. CONCLUSION 19 + NORMATIVE REFERENCES 19 + AUTHORS' ADDRESSES 20 + COMMENTS 20 + FULL COPYRIGHT STATEMENT 21 + COPYRIGHT (C) THE IETF TRUST (2007). 21 + INTELLECTUAL PROPERTY 21 + EXPIRATION 21 + ACKNOWLEDGEMENT 22 1. Introduction 1.1 Purpose and Background IP multicasting is designed to serve cases of group communication schemes of any kind, such as 1-to-n (case of TV broadcasting services for example) or n-to-p (case of videoconferencing services, for example). In these environments, IP multicast provides a better resource optimization than using a unicast transmission scheme, where data need to be replicated as many times as @@ -101,45 +144,46 @@ This memo describes a framework for specifying the Authorization, Authentication and Accounting (AAA) capabilities that could be activated within the context of the deployment and the operation of IP multicast-based services. This memo also describes a framework to realize high-quality multicast transport using a Resource and Admission Control System (RACS) with multicast Authorization. Specifically, this framework addresses the requirements - presented in draft-ietf-mboned-maccnt-req-04.txt, - "Requirements for Accounting, Authentication and - Authorization in Well Managed IP Multicasting Services" - MACCNT-REQ-draft describes the requirements in CDN services - using IP multicast[1]. The requirements are derived from: + presented in draft-ietf-mboned-maccnt-req-05.txt, + "Requirements for Multicast AAA coordinated between Content + Provider(s) and Network Service Provider(s)" MACCNT-REQ- + draft describes the requirements in CDN services using IP + multicast[1]. The requirements are derived from: - need for user tracking and billing capabilities - need for network access control to satisfy the requirements of the Network Service Provider (NSP) and/or content access control to satisfy the requirements of the Content Provider (CP) - methods for sharing information between the network service provider and content provider to make it possible to fulfill the above two requirements. Detailed requirements are presented in MACCNT-REQ-draft. These requirements include mechanisms for recording end- user requests and provider responses for content-delivery, sharing user information (possibly anonymously depending on the trust model) between content provider and network service provider, and protecting resources through the prevention of network and content access by unauthorized users, as well as other AAA related requirements. - The purpose of this memo is to provide a generalized framework - for specifying multicast-inferred AAA capabilities that can + The purpose of this memo is to provide a generalized + framework for + specifying multicast-inferred AAA capabilities that can meet these requirements. This framework is to provide a basis for future work of investigating the applicability of existing AAA protocols to provide these AAA capabilities in IP multicast specific context and/or if deemed necessary, the refining or defining of protocols to provide these capabilities. 2. Definitions and Abbreviations 2.1 Definitions @@ -192,21 +236,21 @@ CAPCF: Conditional Access Policy Control Function CDN: Content Delivery Network CDS: Content Delivery Services CP: Content Provider CPE: Customer Premise Equipment - mRACF: Multicast Resource and Admission Control Function + MACF: Multicast Admission Control Function NSP: Network Service Provider TS: Transport System 3. Common use models and network architecture implications In some cases a single entity may design and be responsible for a system that covers the various common high-level requirements of a multicasting system such as 1) content @@ -245,245 +289,314 @@ -Methods for sharing information between the NSP and CP to make the above two possible When the NSP and CP are the same single entity the general requirements are as follows. -Need for user tracking and user-billing capabilities -Need for access control and/or content protection at level the entity deems appropriate -4. Framework and Roles of Entities - -4.1 Framework for multicast AAA + 4. Framework and Roles of Entities4.1 Framework for multicast + AAA A general high-level framework can be represented as follows. +------------------------------+ | user | | | +------------------------------+ | Access ^ Response - | Request | & Multicast Data + | Request | V | +------------------------------+ | NSP | | | +------------------------------+ | Access ^ Response | Request | (Success) v | +------------------------------+ | CP | | | +------------------------------+ Figure 1 For the sake of simplicity, the above diagram portrays a case where there is a single NSP entity and a single CP - entity, but multiple CPs can be connected to the same NSP. - It is also possible for the same CP to be connected to - multiple NSP networks (e.g. network selection). In other - words the relationship of NSP:CP can be described as 1:1, - 1:N or M:N. Furthermore it is possible that the NSP and CP - could be the same entity. + entity, but multiple CPs can be connected to a single NSP + (e.g. NSP may provide connections to multiple CPs to + provide a wide selection of content categories.) It is also + possible for a single CP to be connected to multiple NSP + networks (e.g. network selection). Furthermore it is + possible that the NSP and CP could be the same entity. A + NSP and CP authenticate and authorize each other when they + establish connectivity. Below the general case of multiple + NSPs with multiple CPs is explained. Then, the various + combinations of single and multiple CPs and NSPs are + described in relation to the general case. - Description of Roles: + 4.1.1 Multiple CPs are connected to multiple NSPs - The user (or the user's device) selects a CP and a NSP when - the user requests content. The NSP may be automatically - selected by a user terminal: e.g. a fixed line NSP for STB - or a mobile NSP for mobile phone. In some usage cases it - is possible that the NSP used by the user terminal will not - always be the same. For example a user may have contracted - with different NSPs for fixed line or mobile roaming access. + The user subscribes to multiple NSPs and multiple CPs in + this usage case. The user selects a CP and a NSP when the + user requests content. The NSP may be automatically + selected by a user terminal: e.g. a fixed line NSP by a set + top box or a mobile NSP by a mobile phone. In some usage + cases it is possible that the NSP used by a certain user + will not always be the same. For example a user may have + contracted with more than one NSP: one for fixed line + access and another for mobile roaming access. - The CP is responsible for Authentication and Authorization - of users' access to content that the CP manages. The CP - hopes to collect accounting information related to the - access of their content. The CP may choose to authenticate - and authorize NSPs which are eligible to provide users - access to its contents. When the CP cannot (e.g. error or + The content may be associated with (or managed by) a + specific CP. In this case, when the user selects content, + the CP is automatically selected. + + The user should send an Access-Request to the selected NSP + with enough information not only for authentication by the + CP but also for CP selection and admission control by the + NSP. + + When an NSP receives an Access-Request from a user, the NSP + selects the appropriate CP for the received Access-Request + and relays the content request. As the NSP is responsible + for managing its network resources, the NSP may perform + admission control.The NSP will allow access to the network + and contents conditional to both the CP's content + authorization result and the NSPs network availability. + That is, the NSP starts multicast flow only when it has + both 1) received an accept response from the CP and 2) + determined that the network resources (e.g. bandwidth) are + sufficient to serve the multicast channel. When neither of + these conditions are met, the NSP does not start the + requested multicast channel. When the NSP already knows + that network resources are insufficient or there is a + network failure, the NSP may choose to not relay the + Access-Request to the CP. The NSP is also responsible for + relaying the Response message from the CP to the user + whether the user is eligible to receive content (in + response to the corresponding Access-Request from the user + to the CP.) In cases that the NSP does not start multicast + because of its own network issues (e.g. lack of network + resources or network failure), the NSP notifies the user + with a reason for rejecting the request. + + A CP receives an Access-Request relayed by the NSP. The CP + authenticates the NSPs identity and makes an authorization + decision regarding the NSPs eligibility to provide users + access to its contents. The CP is responsible for + Authentication and Authorization of users' access to + content that the CP manages. The CP hopes to collect + accounting information related to the access of their + content. The CP responds to the NSP regarding the relayed + Access-Request. When the CP cannot (e.g. error or resource issues) or decides not (e.g. policy issues) to deliver content, the CP is responsible for notifying the NSP of the reason. It is up to the NSP how to relay or - translate the messages to the user. + translate the reasons for rejection to the user. - The NSP is responsible for managing its network resources. - The NSP may perform admission control. It is also - responsible for relaying the AAA messages from the CP - whether the user is eligible to receive content - (authentication by proxy), and the NSP's relevant AAA - server will allow access to the network and contents - conditional to both the CP AAA server's content - authorization result and the NSPs network utilization - authorization result. In certain cases the CP and NSP may - have a contractual relationship in which the NSP is - authorized to make the content authorization decision based - on mutually predetermined criteria: in such cases the NSP- - AAA may also make the content authorization decision - without querying the CP-AAA. When the NSP cannot or - decides not to multicast to users, the NSP may notify the - users of the reason. It is recommended that the NSP notify - eligible users of the reason for not multicasting content - when it is due network or content unavailability, for - example. The NSP may choose not to notify ineligible users - of the reason for any case. + 4.1.2 Multiple CPs are connected to a single NSP -4.2 Multiple User IDs + The user subscribes to a single NSP which provides + multicasting of channels from multiple CPs in this usage + case. In this case the user does not select an NSP. The + user selects a CP when the user requests content. The + content may be associated with (or managed by) the specific + CP, when the user selects content, the CP is automatically + selected. + + The user should send an Access-Request to the specific NSP + with enough information not only for authentication by the + CP but also for CP selection and admission control by the + NSP. + + The role of the NSP is the same as that described in 4.1.1. + + The role of a CP is the same as that described in 4.1.1. + + 4.1.3 A single CP is connected to multiple NSPs + + A user subscribes to multiple NSPs but a single CP in this + usage case. A user selects the NSP when the user requests + content but the CP is fixed. The user should send an + Access-Request to the selected NSP with enough information + not only for authentication by the CP but also for + admission control by the NSP. + + The role of the NSP is similar to the description in 4.1.1, + with the exception that when a NSP receives an Access- + Request from a user, NSP relays it to the CP without CP + selection. + + The role of the CP is the same as that described in 4.1.1. + + 4.1.4 A single CP is connected to single NSP + + In this case, a user subscribes to only one NSP and one + CP. The user does not select NSP and CP in this scenario. + The user should send an Access-Request to the NSP with + enough information not only for authentication by the CP + but also for admission control by the NSP. + + The role for the NSP is the same as 4.1.3 + The role of the CP is the same as the description in 4.1.1. + + The NSP and CP could be the same entity. In this case, the + roles of the NSP and CP may be combined. + + 4.2 User ID Users may hold multiple user IDs: IDs which have been separately assigned for each subscription they may have for - various NSPs and CPs. The NSPs and CPs control the user - IDs for their respective domains. The user IDs are only - meaningful in the context of each domain. + various NSPs and CPs. The NSPs and CPs manage the user IDs + for their respective domains. A CP identifies a user by a + user ID assigned by CP itself. A NSP identifies a user by a + user ID assigned by NSP itself. The user IDs are only + meaningful in the context of each domain. Users may hold + multiple user IDs which have been separately assigned for + each subscription they may have for various NSPs and CPs. - When the user wants to access content, the user registers - the corresponding user ID (including its CP domain - information) with a request for content, etc: web - authentication is one possible method. + 4.2.1 CP-assigned user ID - Each CP may identify users by the user IDs that it has - issued to them. + CPs assign user IDs to their users. The user may have more + than one CP-assigned user ID per a specific CP. A user + sends an Access-Request to a NSP, the CP-assigned user ID + should be indicated so that the CP can identify the user + requesting content access. A NSP should relay the CP- + assigned user ID from the user to the CP. A NSP should not + send a CP-assigned user ID to any CP except the one which + assigned it and should not relay it all if there is no + appropriate CP that assigned the user ID. - Terminal portability can be realized if the NSP - authenticates a user using a NSP-assigned user ID. A NSP- - assigned user ID is an access-line independent unique ID - assigned to users which allows user identification from any - access point within the network and possibly roaming to - other networks. This allows the user to access the content - from various network access points. + 4.2.2 NSP-assigned user ID - The NSP and CP do not need to know the corresponding user - id for the same user in the other provider's domain, and it - is not necessary that there is a one to one relationship. - It is quite possible for one person to hold multiple user - ids for the same provider. + NSPs assign user IDs to their users. A user may have more + than one NSP-assigned user ID per a specific NSP. A user + sends an Access-Request to a NSP, the NSP-assigned user ID + may be indicated in it so that the NSP can identify the + user. The NSP should not relay the NSP-assigned user ID to + the CP for security reasons. The NSP may identify the + multicast-access user by other methods than the NSP- + assigned userID, e.g. by the access port. - The actual mapping rules for NSPs and CPs to map user IDs - with the IDs in other provider domains is a matter for the - providers. A solution should provide an API between the - providers to flexibly support various mapping methods. + The actual mapping rules for NSP-assigned user IDs with CP- + user assigned IDs in account logs is a matter for the + providers and out of the scope of this framework. 4.3 Accounting - MACCNT-REQ-draft defines requirements for Accounting and - Billing. These include the requirement for the NSP to log - user behavior such as the join action and the leave action, - as well as the result of the access-control decision. - (MACCNT-REQ-draft, 4.5) MACCNT-REQ-draft also specifies - that there should be a standardized way to sharing with the - CP the user behavior and content reception information - which the NSP is logging.(MACCNT-REQ-draft, 4.5.1) - Standardization of the logs or messages to share content - usage information is important to support a single NSP - sharing accounting information with multiple CPs or a - single CP receiving from multiple NSPs. - - In order to provide the granularity of user-behavior and - actual content reception information as specified in - MACCNT-REQ-draft, the NSP should not manage multicast - states on a subnet basis, but on a user basis (see in - MACCNT-REQ-draft, 4.1 "User identification") because the - NSP needs to be able to notify the CP of a user's start and - stop times for accounting purposes. This means that the NSP - sends to the CP AAA an indication for Join and Leave on a - user basis. User-based multicast state management is - equivalent to explicit membership tracking in RFC3376 and - per-host tracking in RFC3810. + There are some specific accounting issues for multicasting. + A (S,G) should be recorded as a channel identifier. The + last hop devices, such as a IGMP or MLD router and a IGMP + or MLD proxy, notify a (S,G) to AAA function in the NSP. + The (S,G) information should be notified to the CP as part + of the accounting log. - This framework specifies an accounting API provided by the - NSP and accessed by the CP to allow for sharing user- - behavior and content-reception information between the NSP - AAA and CP AAA. This accounting API should be configurable - to allow the CP to request only the logging information it - actually requires. Such an API would allow for realtime - accounting information sharing by the NSP to the CP. When - logging information is shared through the accounting API, - it is important that the CP be able to match the user as - described in the database operated by the NSP to the user - as described in the database operated by the CP. + A NSP records accounting start corresponding to only the + first Join for a specific user access session. A NSP should + not treat a Query-responded Join as the accounting start. - The NSP requires the capability to log both user and host - information for each join and leave, indicating the - corresponding multicast source for each action. When either - a CP source stops sending, or the NSP stops multicasting, - in an unsolicited manner, there is also a need to notify - the AAA servers accordingly about the users who are - impacted by this event. + A NSP records accounting stop triggered by not only user + requested Leave but also timeout of a multicast state or + re-authentication failure. A NSP may also record an + accounting stop due to network availability reasons such as + failure. The NSP logs the reason for each accounting stop. Also, intermittent logs between the join and leave would allow for finer diagnostics and therefore could serve - useful in billing discrepancies, and provide for a better - estimation of the time span that content was multicasted in - the even that users disconnect without sending leave + useful in billing discrepancies, and provide for a finer + estimation of the time spent for delivering the content in + the event that users disconnect without sending leave messages. 4.4 Access Control and CP selection by NSP - When a NSP receives an access request from a user, it is - necessary for the NSP to determine to which CP the request - is to be directed. It is necessary for the NSP to ensure - that it is not spoofed by an inappropriate CP or user. + When a NSP receives an access request from a user, the NSP + determines to which CP the request is to be directed. The + NSP may select a CP based on CP-assigned userID with CP + domain name or channel identifier (S,G). The user should + include in the request sufficient information for CP + selection. -4.5 API for Admission Control Information by NSP + 4.5 Admission Control Information by NSP After authorizing a user request, the NSP may have further conditions for determining its admission control decision. - MACCNT-REQ-draft defines requirements for providing the - network capability to conduct admission control based on - the network bandwidth usage status and bandwidth management - policy. (MACCNT-REQ-draft, 4.2.2, 4.2.3 & 4.9) Such QoS - measurement and policy mechanisms themselves are out of the - scope of this memo. However the NSP's AAA Server should be - provided with an Admission control API that allows for - interfacing so that additional conditions can be added to - the admission control decision. + + The NSP needs to know traffic parameters of a multicast + channel for admission control. The traffic parameter + information may be either indicated by the user or CP + within the access request and responses, or otherwise + shared between the NSP and CP outside the access-request + message mechanism: + - A user may declare traffic parameters for each + Access-Request. + - A CP may notify a mapping between the channel + identifier (S,G) and traffic parameters in the Response + message when the CP authorizes an access request. + - The NSP may maintain a mapping between channel + identifier (S,G) and traffic parameters in advance, for + example pre-configured by agreement between the CP and NSP + on a per channel basis. + + A NSPs admission control may manage integrated network + resources for unicast usage, such as VoIP or unicast + streaming, and multicast usage. Alternatively, it may + manage network resources separately for unicast and + multicast usage. In either case, AAA and admission control + framework for multicast usage is independent of unicast + admission control. + + Such QoS measurement and policy mechanisms themselves + depend on NSP policies and are out of the scope of this + memo. 4.6 Access Control and Distinguishing of Users by CP The user ID and authentication information are forwarded transparently by the NSP so that the CP can distinguish the user, as well as authenticate and authorize the request. -4.7 Caching of AAA results + 4.7 AAA proxy in NSP - An NSP should be able to cache AAA results based upon an - agreement between the NSP and a CP. The AAA cache would - store information about permissions of a specific user to - receive multicast data from specified channel(s) up to - specified expiration date(s) and time(s). - If such caching is implemented, a method must exist for the - CP to communicate this permission information to the NSP. - The NSP refers to the AAA cache and if the cache indicates - that the user has permission to receive multicast data from - a specific channel at that time, the NSP may forward the - data without querying the CP. + A NSP may act as AAA proxy of a CP based upon an agreement + between the NSP and the CP. The AAA proxy would store + information about permissions of a specific user to receive + multicast data from specified channel(s) up to specified + expiration date(s) and time(s). + If such proxying is implemented, the NSP may receive + authorization conditions from a CP in advance and + statically hold them, or a CP may send them dynamically in + the Response message. The user has permission to receive + multicast channel at that time. The NSP starts the + multicasting without querying the CP. - It should be possible for a CP to send unsolicited requests - to the NSP to refresh or change the permissions for a user - for specific channel(s). + The CP may send unsolicited requests to the NSP to refresh + or change the permissions for a user for specific + channel(s). When a user is receiving multicast content and the permission is about to expire, the NSP may send a notification to the user client that his session is about - to expire, and that he will need to re-connect. The user - will have to reestablish a connection. In the case that - the user still has permission to the content, they should - be able to continue to receive the content without - interruption. + to expire, and that he will need to reauthenticate. In such + a case, the user will have to send the Access-Request. In + the case that the user still has permission to the content, + they should be able to continue to receive the content + without interruption. + When re-authentication fails, the NSP should stop the + multicast channel and record accounting stop. 5. Network Connection Model and Functional Components Section 3.1 introduces the high-level AAA framework for - multicasting. This section provides more detail on the + multicasting. This section provides more details on the network connection model and constituent functional components. 5.1 Basic Connection Model In the simple case represented in Figure 1 the NSP is the sole entity providing network resources including network access to the User. First a user that requests content sends an Access request to an NSP which then forwards it on to the appropriate CP for Authentication and Authorization @@ -492,31 +605,32 @@ response and stream multicast data to the user. In this model the user selects the NSP to which to send its content request. Based on this request the NSP selects an appropriate CP to which it forwards the request. The CP responds to the NSP's request: it may not respond to another NSP in regards to the request. In this model, as described in section 3.1, the relationship between NSP and CP can be 1:1, 1:N or M:N. - Users may connect to multiple networks, and networks have multiple users. 5.2 Constituent Logical Functional Components of the fully enabled AAA Framework - MACCNT-REQ-draft defined requirements for "well managed" - multicasting which this memo calls "AAA enabled" - multicasting. "Fully enabled AAA" multicasting in this memo - means "AAA enabled" with added QoS functions. + Requirements for "fully AAA and QoS enabled" IP + multicasting networks were defined in MACCNT-REQ-draft. To + allow for levels of enablement, this memo defines two + models within the framework: "AAA enabled" multicasting and + "Fully enabled AAA" multicasting which means "AAA enabled" + with added admission control functions. Section 3.1 introduces the high-level AAA framework for multicasting. Below is a diagram of a AAA enabled multicasting network with AAA, including the logical components within the various entities. AAA enabled framework (basic model) +-------------------------------+ | user | |+- - - - - - - - - - - - - - -+| @@ -531,21 +645,21 @@ | NSP | | |+- - - - - |- -_+ | ||TS | | | | +------|-+ | || | AN | | | | | | | || +------|-+ | | | | IFb | || +------|-+ | | +---------+| | | |----|-|mAAA || - || | NAS | | | | (CAPCF*)|| * optional + || | NAS | | | |(MACF *) || * optional | +--------+ +---------+| ||+- - - - - - - + | | +-----------------------|--------+ | -------|------ IFc | +-----------------------|-------+ | CP +---------+ | | | CP-AAA | | | +---------+ | @@ -544,108 +658,111 @@ +-----------------------|--------+ | -------|------ IFc | +-----------------------|-------+ | CP +---------+ | | | CP-AAA | | | +---------+ | +-------------------------------+ Figure 2 + The user entity includes the CPE (Customer Premise Equipment) which includes the user host(s) and optionally a multicast proxy (not shown in the Figure 2.) The NSP (Network Service Provider) in the basic model includes the transport system and a logical element for multicast AAA functionality. The transport system is comprised of the access node and NAS (network access - server.) Descriptions of AN and its interfaces are out of - scope for this memo. The multicast AAA function may be - provided by a multicast AAA server (mAAA) which may include - a function by which the access policy is downloaded to the - NAS (conditional access policy control function.) The - interface between mAAA and NAS is labeled IFb in Figure 2. - Over IFb the NAS makes an access request to the NSP-mAAA - and the mAAA replies. The mAAA may push conditional access - policy to the NAS. + server) An AN may be connected directly to mAAA or a NAS + relays AAA information between an AN and a mAAA + Descriptions of AN and its interfaces are out of scope for + this memo. The multicast AAA function may be provided by a + multicast AAA server (mAAA) which may include the function + by which the access policy is downloaded to the NAS + (Multicast access control function.) The interface between + mAAA and the NAS is labeled IFb in Figure 2. Over IFb the + NAS makes an access request to the NSP-mAAA and the mAAA + replies. The mAAA may push conditional access policy to the + NAS. The content provider may have its own AAA server which has the authority over access policy for its contents. The interface between the user and the NSP is labeled IFa in Figure 2. Over IFa the user makes a multicasting request to the NSP. The NSP may in reply send multicast - traffic depending on the NSP and CP's policy decisions. + traffic depending on the NSP and CPs policy decisions. The interface between the NSP and CP is labeled IFc. Over IFc the NSP requests to the CP-AAA for access to contents and the CP replies. CP may also send conditional access - policy over this interface for AAA-caching. + policy over this interface within the context of proxying + multicast AAA messagescaching. - Fully enabled framework (c) + Fully enabled framework +-------------------------------+ | user | |+- - - - - - - - - - - - - - -+| || CPE || || || |+- - - - - | - - - - - - - - -+| +-----------|-------------------+ | -------|------ IFa | +-----------|-----------------------+ |+- - - - - |- - _+ + - - - - - + | ||TS | | | | | | | +------|-+ | +--------+ | - || | AN | | | | | mRACF || | + || | AN | | | | | MACF || | | | | | | | | || +------|-+ | | | +---|----+| | | | | | | | | | | | IFd----- | | | | | IFb | | | || +------|---+ | | | +---|----+| | | | |---|---| mAAA | | - || | NAS | | | | |(CAPCF*)|| | * optional + || | NAS | | | | |(MACF *)|| | * optional | +----------+ | +--------+ | ||+- - - - - - - -+ - - |- - - - -+ | +-----------------------|-----------+ | -------|------ IFc | +-----------------------|-------+ | CP +---------+ | | | CP-AAA | | | +---------+ | +-------------------------------+ Figure 3 In the fully enabled model the NSP also includes a component that provides network resource management (e.g. QoS management), as described in section 3.4, "Network Resource Management by NSP". In the fully enabled model (Figure 3) resource management and admission control is - provided by mRACF (multicast resource and admission control - function.) This means that mRACF and Authorization portion - of mAAA comprise RACS. Before replying to the user's - multicast request the mAAA queries the mRACF for a network - resource access decision over the interface IFd. The mRACF - is responsible for allocating network resources for multicast - traffic. So that mRACF has the necessary network resource - availability information, NAS notifies mRACF via mAAA of the - stopping of multicast traffic. + provided by MACF (multicast admission control function). + Before replying to the user's multicast request the mAAA + queries the MACF for a network resource access decision + over the interface IFd. The MACF is responsible for + allocating network resources for multicast traffic. To + provide MACF with the relevant network resource + availability information, NAS notifies MACF via mAAA that + sending multicast traffic has ceased. 5.3 Modularity of the framework In the interest of flexibility, this framework is modular so that it is possible that partially enabled versions of - the models are supported. A AAA-enabled version provides + the models are supported. An AAA-enabled version provides AAA functionality without Network Resource management. A Network-Resource-Management-enabled (QoS-enabled) version provides Network Resource management without AAA functionality. Similarly, the possibility of one or more layers of transit provision between an NSP and CP is in the interest of modularity and extendibility. 6. IANA considerations This memo does not raise any IANA consideration issues. @@ -655,31 +772,31 @@ Refer to section 3.3. Also the user information related to authentication with the CP must be protected in some way. Otherwise, this memo does not raise any new security issues which are not already addressed by the original protocols. Enhancement of multicast access control capabilities should enhance security performance. 8. Conclusion This memo provides a generalized framework for solution - standards to meet the requirements presented in MACCNT-REQ- - draft. Further work should be done to specify the - interfaces between the user and NSP, NAS and mAAA, mAAA and - mRACF and NSP-mAAA and CP-AAA (presented in 5.2.) + standards to meet the requirements. Further work should be + done to specify the interfaces between the user and NSP, + NAS and mAAA, mAAA and MACF and NSP-mAAA and CP-AAA + (presented in 5.2.) Normative References - [1] Hayashi, et. al., "Accounting, Authentication and - Authorization Issues in Well Managed IP Multicasting - Services", draft-ietf-mboned-maccnt-req-04.txt, - February 2006, Work in Progress. + [1] Hayashi, et. al., Requirements for Multicast AAA + coordinated between Content Provider(s) and Network + Service Provider(s)", draft-ietf-mboned-maccnt-req- + 05.txt, September 2007, Work in Progress. [2] RFC-3810, Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", June 2004. [3] RFC-3376, Cain B., et.al., "Internet Group Management Protocol, Version 3", October 2002. Authors' Addresses Hiroaki Satou @@ -690,25 +807,26 @@ Email : satou.hiroaki@lab.ntt.co.jp Hiroshi Ohta NTT Network Service Systems Laboratories 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan Phone : +81 422 59 3617 Email: ohta.hiroshi@lab.ntt.co.jp Christian Jacquenet - France Telecom - 3, avenue Francois Chateau - CS 36901, 35069 Rennes Cedex, France - Phone: +33 2 99 87 63 31 - Email: christian.jacquenet@francetelecom.com + France Telecom R&D + 4, rue du Clos Courtel - + - BP 91226 + 35512 Cesson-SvignECedex, France + Phone: +33 2 99 12 49 40 + Email: christian.jacquenet@orange-ftgroup.com Tsunemasa Hayashi NTT Network Innovation Laboratories 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 Japan Phone: +81 46 859 8790 Email: tsunemasa@gmail.com Haixiang He Nortel @@ -762,16 +880,16 @@ http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Expiration - This Internet-Draft will expire on January 10, 2008. + This Internet-Draft will expire on May 17, 2008. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.