--- 1/draft-ietf-mboned-maccnt-req-07.txt 2009-07-13 08:12:14.000000000 +0200 +++ 2/draft-ietf-mboned-maccnt-req-08.txt 2009-07-13 08:12:14.000000000 +0200 @@ -1,181 +1,152 @@ - Tsunemasa Hayashi, NTT - Internet Draft Haixiang He, Nortel - Document:draft-ietf-mboned-maccnt-req-07.txt Hiroaki Satou, NTT - Intended Status: Informational Hiroshi Ohta, NTT - Expires: July 16, 2009 Susheela Vaidya, Cisco Systems - - January 12, 2009 +mboned T. Hayashi +Internet-Draft NTT Network Innovation +Intended status: Informational Laboratories +Expires: January 14, 2010 H. He + Nortel + H. Satou + H. Ohta + NTT Network Service Systems + Laboratories + S. Vaidya + Cisco Systems, Inc. + July 13, 2009 - Requirements for Multicast AAA coordinated between Content - Provider(s) and Network Service Provider(s) + Requirements for Multicast AAA coordinated between Content Provider(s) + and Network Service Provider(s) + draft-ietf-mboned-maccnt-req-08 Status of this Memo - This Internet-Draft is submitted to IETF in full conformance with - the provisions of BCP 78 and BCP 79. + + This Internet-Draft is submitted to IETF in full conformance with the + provisions of BCP 78 and BCP 79. This document may contain material + from IETF Documents or IETF Contributions published or made publicly + available before November 10, 2008. The person(s) controlling the + copyright in some of this material may not have granted the IETF + Trust the right to allow modifications of such material outside the + IETF Standards Process. Without obtaining an adequate license from + the person(s) controlling the copyright in such materials, this + document may not be modified outside the IETF Standards Process, and + derivative works of it may not be created outside the IETF Standards + Process, except to format it for publication as an RFC or to + translate it into languages other than English. 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." + 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. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on July 16, 2009. + This Internet-Draft will expire on January 14, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with - respect to this document. + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. Abstract - This memo presents requirements in the area of accounting and - access control for IP multicasting. The scope of the - requirements is limited to cases that Authentication, - Accounting and Authorization (AAA) functions are coordinated - between Content Provider(s) and Network Service Provider(s). - General requirements for accounting and admission control - capabilities including quality-of-service (QoS) related issues - are listed. This memo assumes that these capabilities can be - realized by functions implemented at edges of a network based - on IGMP or MLD. Finally, cases for Content Delivery Services - (CDS) are described as application examples which could benefit - from multicasting accounting and access control capabilities as - described in this memo. + This memo presents requirements in the area of accounting and access + control for IP multicasting. The scope of the requirements is + limited to cases where Authentication, Accounting and Authorization + (AAA) functions are coordinated between Content Provider(s) and + Network Service Provider(s). - This memo defines requirements related to AAA issues for multi- - entity provider models in which the network service provider and - content provider cooperate to provide CDS and various related AAA - functions for purposes such as protecting and accounting for the - access to content and network resources. The requirements are - generally not relevant to cases in which there is not a reason to - share AAA functions between separate entities. + In order to describe the new requirements of a multi-entity Content + Deliver System(CDS) using multicast, the memo presents three basic + business models: 1) the Content Provider and the Network Provider are + the same entity, 2) the Content Provider(s) and the Network + Provider(s) are separate entities and users are not directly billed, + and 3) the Content Provider(s) and the Network Provider(s) are + separate entities and users are billed based on content consumption + or subscriptions. The requirements of these three models are listed + and evaluated as to which aspects are already supported by existing + technologies and which aspects are not. - Table of Contents + General requirements for accounting and admission control + capabilities including quality-of-service (QoS) related issues are + listed and the constituent logical functional components are + presented. - 1. Introduction..................................................3 - 2. Definitions and Abbreviations.................................5 - 2.1 Definitions..................................................5 - 2.2 Abbreviations................................................6 - 3. Problem Statement.............................................6 - 3.1 Accounting Issues...........................................6 - 3.2 Relationship with Secure Multicasting (MSEC)................8 - 3.3 Regarding Access Media and User Separation..................8 - 4. General AAA-related Functional Requirements for IP Multicasting - .................................................................9 - 5. Application Example and its Specific Requirements............14 - 5.1 IP Multicast-based Content Delivery Service (CDS): CP and NSP - are different entities (companies)..............................14 - 5.1.1 Network Model for Multicast Content Delivery Service......15 - 5.1.2 Content Delivery Service Requirements.....................17 - 5.1.2.1 Accounting Requirements.................................17 - 5.1.2.2 Authorization Requirements..............................18 - 5.1.2.3 Authentication Requirements.............................19 - 5.2 IP Multicast-based Content Delivery Service (CDS): CP and NSP - are the same entities (companies)...............................19 - 6. Acknowledgments..............................................21 - 7. IANA Considerations..........................................21 - 8. Security Considerations......................................21 - 9. Privacy considerations.......................................21 - 10. Conclusion..................................................21 - Normative References............................................22 - Authors' Addresses..............................................23 + This memo assumes that the capabilities can be realized by + integrating AAA functionalities with a multicast CDS system, with + IGMP/MLD at the edge of the network. 1. Introduction - This memo presents general functional requirements related to - accounting, access control and admission control issues in IP - multicasting networks. A multicast network which fulfills all of - these requirements is called a "fully AAA and QoS enabled" IP - multicasting network here. Fulfillment of all or some of the - requirements will make possible more robust management of IP - multicasting networks. - - IP multicasting is becoming widely used as a method to save - network resources such as bandwidth or CPU processing power of the - sender's server for cases where a large volume of information - needs to be distributed to a very large number of receivers at a - given data speed. This trend can be observed both in enterprise - use and in broadband services provided by network operator/service - providers. - - Distance learning within a university and in-house (in-company) - sharing of multimedia information are examples of enterprise use. - In these examples, sources generate high-bit rate (e.g., 6Mbit/s) - streaming information. When the number of receivers becomes large, - such systems do not scale well without multicasting. - - On the other hand, a content delivery service (CDS) is an example - of a broadband service provided by network operators/service - providers. Distribution of movies and other video programs to - each user is a typical service. Each channel requires large - bandwidth (e.g., 6Mbit/s) and operator/service providers need to - provide many channels to make their service attractive. In - addition, the number of receivers is large (e.g., more than a few - thousands). A system to provide this service does not scale well - without multicasting. + Broadband access networks such as ADSL (Asymmetric Digital Subscriber + Line) or FTTH (Fiber to the Home) have been deployed widely in recent + years. Content Delivery Service (CDS) is expected to be a major + application provided through broadband access networks. Because many + services such as television broadcasting require huge bandwidth + (e.g., 6Mbit/s) and processing power at the content server(s), IP + multicast is used as an efficient delivery mechanism for CDS. - As such, multicasting can be useful to make a network more - scalable when a large volume of information needs to be - distributed to a large number of receivers. However, multicasting - according to current standards (e.g., IGMPv3[1] and MLDv2[2]) has - drawbacks compared to unicasting when one applies it to commercial - services. Accounting of each user's actions is not possible with - multicasting as it is with unicasting. Accounting consists of - grasping each user's behavior, when she/he starts/stops to receive - a channel, which channel she/he receives, etc. + A single entity may design and be responsible for a system that + covers the various common high-level requirements of a multicasting + CDS such as 1) content serving, 2) the infrastructure to multicast + it, 3) network and content access control mechanisms. For cases in + which the business model includes the direct billing of users, the + single provider of both content and network services has sufficient + data in its control to bill users based on their content consumption. + Furthermore it is possible to tie access to the network and QoS based + on a user's contract status. Therefore current technologies support + the single entity case. - There are limitations to the application of multicasting in usage - models where user-based accounting is necessary, such as is the - case with many commercial applications. These limitations have - prevented the widespread deployment of multicasting. Development - and use of proprietary solutions to address such issues is an - alternative to providing standardized solutions. However, non- - standard solutions have drawbacks in terms of interoperability or - cost of development and maintenance. + Often, however, the content provision and network provision roles are + split between separate entities. Commonly, Content Providers (CP) do + not build and maintain their own multicast network infrastructure as + this is not their primary business area. Instead, CPs often purchase + transport and management services from network service providers. + This memo lists the requirements of a business model in which the NSP + provides CDS using multicast as one such contractible service. - Without accounting capability in multicasting, information - providers desiring accounting capability are forced to use - unicasting even when multicasting would otherwise be desirable - from a bandwidth/server resource perspective. If multicasting - could be used with user-based accounting capabilities, its - applicability would be greatly widened. + The direct revenue source for the multiple entity provider is a + defining aspect of the business model which often has implications on + requirements for the technologies that support the system. There are + cases such as the the advertising-based model where billing end-users + is not done and therefore accounting of content consumption can be + anonymous and/or in aggegrate. In these cases the requirements of + the business model for accounting for billing purposes are already + supported by existing technologies. However, the NSP can not + guarantee high quality transmission on a per-content basis with + existing technologies. - This memo first describes problems on accounting issues in - multicasting. Then the general requirements for this capability - including QoS related issues are listed. Finally, application - examples which could benefit from multicasting with accounting - capabilities are shown. + There is also the business model in which the individual user of + multicasted contents is the source of revenue for both consumed + content and network resources. In this model the NSP wants to + receive the appropriate fees for multicast services and the NSP + undertakes collecting bills as a proxy for the CPs. The NSP may + provide high quality service by admission control. Current standards + do not fully support this model and this memo will list the + requirements which need to be supported. 2. Definitions and Abbreviations - 2.1 Definitions +2.1. Definitions Authentication: action for identifying a user as a genuine one. Authorization: action for giving permission for a user to access content or the network. Eligible user: Users may be eligible (permitted) to access resources because of the attributes they have (e.g., delivery may require possession of the correct password or digital certificate), their equipment has (e.g., content may only be @@ -188,640 +159,558 @@ countries), and, of course, a mix of attributes may be required for eligibility or ineligibility. User: In this document user refers to a requester and a recipient of multicast data, termed a viewer in CDS. User-based accounting: actions for grasping each user's behavior, when she/he starts/stops to receive a channel, which channel she/he receives, etc. - 2.2 Abbreviations +2.2. Abbreviations AAA: Authentication, Accounting and Authorization ASM: Any-Source Multicast CDS: Content Delivery Service CP: Content Provider IGMP: Internet Group Management Protocol MLD: Multicast Listener Discovery NSP: Network Service Provider SSM: Source Specific Multicast QoS: Quality of Service - 3. Problem Statement - - 3.1 Accounting Issues - - In unicast communications, the server (information source) can - identify the client (information receiver) and only permits - connection by an eligible client when this type of access control - is necessary. In addition, when necessary, the server can grasp - what the client is doing (e.g., connecting to the server, starting - reception, what information the client is receiving, terminating - reception, disconnecting from the server). - - On the other hand, in multicast communication with current - standards (e.g., IGMPv3[1] or MLDv2[2]) the server just feeds its - information to the multicast router [as in Fig.1]. Then, the - multicast router replicates the data to any link which has at - least one client requesting the information. In this process, - no eligibility check is conducted. Any client can receive - information just by requesting it. - - It is envisioned that there are many large-scale content - distribution applications transferred over IP-based networks that - can leverage multicasting technologies to meet their scalability - requirements for clients and data volume, and that some of these - applications require user-based accounting capabilities similar to - available with unicast networks. For example, accounting is needed - if one wants to charge for distributed information on a non-flat- - fee basis. The current standards do not provide multicasting with - authorization or access control capabilities sufficient to meet - the requirements of accounting. - - |--- user ----|------------NSP------------------|-----CP---| +3. Current Business Models - +--------+ - | user |\ - +--------+ \ - \+------+ +------+ +------+ +------+ - +--------+ |Multi-| |Multi-| |Multi-| | | - | user |---|cast |----|cast |----|cast |----|Server| - +--------+ |router| |router| |router| | | - /+------+ +------+ +------+ +------+ - +--------+ / - | user |/ - +--------+ +3.1. Single entity model where CP and NSP are the same entity - Fig.1 Example network for multicast communication + One existing business model is that of a single entity responsible + for both content and network service provision which bills its users + based on content provision. (See figure below.) - As such, the same level of user-based accounting capabilities as - provided in unicast networks should be provided in multicast - networks. + +-----------------------------------------------------+ + | +---------+ | + | | Content | | + | | Server | | + | +----+----+ | + | | | + | CP+NSP +-------+-------+ | + | | Provider Edge | | + | +-------+-------+ | + | | | + | | | + | +-------------+ | + | | User Edge | | + | +--+---+---+--+ | + | / | \ | + +----------- / --- | --- \ ---------------------------+ + / | \ + / | \ <- user/network interface + / | \ + +---------++ +-----+----+ ++---------+ + |Client #A | |Client #B | |Client #C | + +----------+ +----------+ +----------+ + User A User B User C - 3.2 Relationship with Secure Multicasting (MSEC) + Example of CDS network configuration - In many cases, content encryption (e.g. MSEC) is an effective - method for preventing unauthorized access to original content (in - other words, the ability to decode data to return it to its - generally usable form.) This memo presents requirements for - multicasting networks in the areas of 1) access control to prevent - unauthorized usage of network resources (link bandwidth, router's - processing power, etc.) , and 2) accounting to grasp user activity - in a NSP. The functional requirements do not require content - encryption although it might solve some of the content related - problems. At this point, it is not yet clear whether encryption - would be part of a solution and if so, what other components (if - any) would also be required. Multicast streams generally consume - large amounts of bandwidth for extended periods of time. - Additionally, some multicast streams may have high-priority - depending on a NSP's policy. NSP does not want to let ineligible - users waste large amounts of bandwidth: for example encryption - protects against content viewing but NSP desires protection - against DoS attacks of ineligible users wasting network resources, - even if it is encrypted. Content encryption and multicast access - control should both be able to coexist for more robust security. + Figure 1 - 3.3 Regarding Access Media and User Separation + In this model the network can query a content-policy-enabled AAA + server within its own domain at the time a user requests content. + The network can provide the AAA server with information such as user + identity, device identity, the requested content (channel), + geographic information, method of network connection, etc. that might + be required for the content provision authorization decision. It is + therefore possible to configure a network to deny network access + based on the content policy decision. - The requirements defined in this memo apply to solutions that - provide user separation either through physical separation - provided by dedicated access media between the user and multicast - router (see Fig. 1) or else through logical separation in cases - of shared physical access media (e.g. using VLAN). However, IP - multicast solutions with shared Layer 2 access media between the - user and multicast router and no logical user separation (e.g. - Ethernet with shared links and no VLAN) are out of scope of this - memo. Nevertheless, some of the requirements in this memo defined - for multicasting may also be relevant to multicasting over links - without either physical or logical user separation. Therefore in - the interest of modularity and flexibility, solutions addressing - the requirements of this memo may also take into account - application to multicasting without such user separation. + In this model there are no issues of mapping user identities between + different entity domains. The provider has access to the information + on which user accessed from which point on what device. Furthermore + as network provider they can record not only when a user joined or + left a certain channel, but also if packets were actually delivered. + Moreover, there are no inter-entity security and privacy concerns + between the CP and NSP. - 4. General AAA-related Functional Requirements for IP Multicasting + The single entity network service and content provider also knows the + content schedules for various channels. This is important not only + for time and content-sensitive authorization decisions but also for + providing meaningful billing details to end users. - In consideration of the issues presented in section 3, the - following requirements have been derived: +3.2. Multiple entity model without direct content-based billing - (1) User identification + An additional model for delivering contents over a CDS is the + advertising-based model where billing end-users is not done. In this + model the four different roles may be filled by separate entities: + Content Provider (CP), Network Service Provider (NSP), user clients, + and advertising sponsors. In the general case of this business + model, insofar as the advertiser does not require user-based metrics + the accounting of content consumption can be anonymous and/or in + aggregrate and can be off-line from the multicast-with-AAA CDS system + itself. Therefore this model does not require any new standards to + provide user-based accounting for a multi-entity CDS using multicast + with AAA. (Providing this data in near real-time and inline would + entail further requirements which can be dealt with in a separate + memo if necessary.) - The network should be able to identify each user when they attempt - to access the service so that necessary access controlling actions - can be applied. Also, it is necessary to identify the user's - receiver (e.g. IP address) of each request (e.g., join/leave) for - per host tracking purposes. + A more complex version of this business model is conceivable in which + a CP may require a user to enter into a subscription contract, even + when the user does not get billed for content consumption. For + example, a CP may value individual data because it allows it to + supply the advertisers with rich, user-segmented data and charge a + higher premium. In that case the requirements of the next section + "CDS with direct billing of the end user" are generally applicable + because of the need to link the user data which the CP has to the + actual viewing (or stream downloading) data that the NSP has. - With current protocols (IGMP/MLD), the sender cannot distinguish - which receivers (end hosts) are actually receiving the information. - The sender must rely on the information from the multicasting - routers. This can be complicated if the sender and routers are - maintained by different entities. +4. Proposed Model: Multity-entity CDS with direct billing of the end + user - (2) Issue of Network Resource Protection + In this model the networks for CDS contain three different types of + entities: Content Provider (CP), Network Service Provider (NSP), and + user clients. An NSP owns the network resources (infrastructure). + It accommodates content providers on one side and accommodates user + clients on the other side. NSP provides the network for CDS to two + entities (i.e., CPs and user clients). A CP provides content to each + user through the network of NSPs and charges users for content. NSPs + are responsible for delivering the content to user clients, and for + controlling the network resources. A NSP charges a user or a CP for + network usage. A NSP may charge users for content as a proxy of the + CP. - In order to guarantee certain QoS it is important for network - providers to be able to protect their network resources from being - wasted, (either maliciously or accidentally). + +-------------+ +-------------+ +-------------+ + | CP | | CP | | CP | + | #1 | | #2 | | #3 | + | +---------+ | | +---------+ | | +---------+ | + | | Content | | | | Content | | | | Content | | + | | Server | | | | Server | | | | Server | | + | +-------+-+ | | +----+----+ | | +-+-------+ | + +----------\--+ +------|------+ +--/----------+ + \ | / + \ | / <- network/network + \ | / interface + +------------- \ ------ | ------ / ----+ + | \ | / | + | NSP +-+-----+-----+-+ | + | | Provider Edge | | + | +-------+-------+ | + | | | + | | | + | +--+------+---+ | + | | User Edge | | + | +--+---+---+--+ | + | / | \ | + +------------- / --- | --- \ ----------+ + / | \ + / | \ <- user/network interface + / | \ + +---------++ +-----+----+ ++---------+ + |Client #A | |Client #B | |client #C | + +----------+ +----------+ +----------+ + User A User B User C - For comparisons sake, for unicast this issue can be resolved e.g. - by using RSVP in some cases. + Example of CDS network configuration - (2.1) Access control + Figure 2 - The network should be able to apply necessary access controlling - actions when an eligible user requests an action (such as a join - or a leave.) The network should be able to reject any action - requested from an ineligible user. + The CP provides detailed channel information (e.g., Time table of + each channel) to the information server which is either managed by + the NSP or CP. An end-user client gets the information from the + information server. In this model, multicasting is used in the NSP's + CDS network, and there are two different contracts. One is the + contract between the NSP and the user which permits the user to + access the basic network resources of the NSP. Another contract is + between the CP and user to permit the user to subscribe to multicast + content. Because the CP and NSP are different entities, and the NSP + generally does not allow a CP to control (operate) the network + resources of the NSP, user authorization needs to be done by the CP + and NSP independently. Since there is no direct connection to the + user/network interface, the CP cannot control the user/network + interface. A user may want to move to another place, or may want to + change her/his device (client) any time without interrupting her/his + reception of services. - (2.2) Control mechanism to support bandwidth of multicast stream - from a physical port of edge router or switch - The network may need to control the combined bandwidth for all - channels at the physical port of the edge router or switch so that - these given physical entities are not overflowed with traffic. +4.1. Information Required by Entities to Support the Proposed Business + Model - (2.3) Control mechanism of number of channels delivered from a - physical port of edge router and switch + User identification and Authentication: - If an NSP desires to guarantee a certain level of QoS to CP and - the receivers, it is necessary that the NSP be able to control the - number of channels delivered from a physical port of an edge - router and a switch in cases that there is a limit to the number - of packet copies and/or number of channels that can be handled by - multicast routers. + The network should be able to identify and authenticate each user + when they attempt to access the service requesting content. This + user identification is required for: - For comparisons sake, for unicast this issue can be resolved e.g. - by using RSVP in some cases. + authorization for content consumption eligibility - (3) User Authentication + user tracking for billing based on actual content consumption + and network resource usage - The network should be able to authenticate a user. + With current protocols (IGMP/MLD), the sender cannot distinguish + which receivers (end hosts) are actually receiving the + information. The sender must rely on the information from the + multicasting routers. This can be complicated if the sender and + routers are maintained by different entities. Furthermore, the + current user associated with receiver must be identified. - (4) User Authorization + User Authorization: The network, at its option, should be able to authorize a user's access to content or a multicast group, so as to meet any demands - by a CP to prevent content access by ineligible users. In the - case that the NSP may wish to provide a service based on - guaranteed delivery, the NSP would not want to waste its network - resources on ineligible users. - - (5) Accounting and Billing + by a CP to prevent content access by ineligible users. - In many commercial multicast situations, NSPs would like to be - able to precisely grasp network resource consumption and CPs would - like to be able to precisely grasp the content consumption by - users. Such information might be used for identifying highly - viewed content for advertising revenue, ratings calculations, - programming decisions, etc., as well as billing and auditing - purposes. Also content and network providers may wish to provide - users with access to their usage history. + Sharing Programming data: - To assemble such an understanding of user behavior, it is - necessary to precisely log information such as who (host/user) is - accessing what content at what time (join action) until what time - (leave action). The result of the access-control decision (e.g. - results of authorization) would also be valuable information. The - desired degree of logging precisions would depend on the - application used. + NSP needs a mechanism to receive channel programming data from the + CP in order to provide the information to the user at channel + selection time and also for somehow logging or recording what + programming content has been streamed to the user. In some cases + the CP may contract the NSP to bill the user as a proxy for the + CP. In this case there needs to be a mechanism for supplying the + user-based viewing history with human-meaningful channel data to + the end-user. - (5.1) How to share user information + Content usage information by user: - For commercial multicast applications it is important for NSP and - CP to be able to share information regarding user's behaviour (as - described in (5) in standardized ways. + For billing and auditing purposes the CP needs the NSP to provide + it with detailed per-user usage behavior indicating what content + was consumed from when to when. There needs to be a mechanism to + supply the user-based viewing history from the NSP to the CP. If + the CP is selling on an on-demand model, or tiered subscription + basis or supplies some sort of online account statement this + history needs to be fed back to the CP in near real-time. To + assemble such data on user behavior, it is necessary to precisely + log information such as who (host/user) is accessing what content + at what time (join action) until what time (leave action). The + result of the access-control decision (e.g. results of + authorization) would also be valuable information. The desired + degree of logging precisions would depend on the application used. - (6) Notification to Users of the Result of the Join Request + Notification to Users of the Result of the Join Request: It should be possible to provide information to the user about the - status of his/her join request(granted/denied/other). + status of his/her join request(granted/denied/other). Such + information can be used to give meaningful feedback to the user. - (7) Service and Terminal Portability +5. Admission Control for Multicasting - Depending on the service, networks should allow for a user to - receive a service from different places and/or with a different - terminal device. + In order to guarantee certain QoS it is important for network + providers (at their option) to be able to protect their network + resources from being wasted, (either maliciously or accidentally). + The NSP should be able to apply appropriate access controlling + actions based on user eligibility status: - (8) Support of ASM and SSM + The network should be able to apply necessary access controlling + actions when an eligible user requests an action (such as a join + or a leave.) - Both ASM (G), and SSM (S,G) should be supported as multicast - models. + The network should be able to reject any action requested from an + ineligible user. - (9) Admission Control for Join Action - In order to maintain a predefined QoS level, depending on the - NSP's policy, a user edge should be able to control the number of - streams it serves to a user, and total bandwidth consumed to that - user. For example if the number of streams being served to a - certain user has reached the limit defined by the NSP's policy, - then the user edge should not accept a subsequent "join" until one - of the existing streams is terminated. Similarly, if the NSP is - controlling by per-user bandwidth consumption, then a subsequent - "join" should not be accepted if delivery of the requested stream - would push the consumed bandwidth over the NSP policy-defined - limit. + In order to maintain a predefined QoS level, depending on the NSP's + policy, a user edge should be able to control the number of streams + it serves to a user, and total bandwidth consumed to that user. For + example if the number of streams being served to a certain user has + reached the limit defined by the NSP's policy, then the user edge + should not accept a subsequent "join" until one of the existing + streams is terminated. Similarly, if the NSP is controlling by per- + user bandwidth consumption, then a subsequent "join" should not be + accepted if delivery of the requested stream would push the consumed + bandwidth over the NSP policy-defined limit. - (10) Channel Join Latency and Leave Latency + The network may need to control the combined bandwidth for all + channels at the physical port of the edge router or switch so that + these given physical entities are not overflowed with traffic. This + entails being able to control the number of channels delivered, the + bandwidth for each channel and the combined bandwidth for all + channels. + +6. Performance requirements + + Channel Join Latency and Leave Latency Commercial implementations of IP multicasting are likely to have - strict requirements in terms of user experience. Join latency is - the time between when a user sends a "join" request and when the + strict requirements in terms of user experience. Join latency is the + time between when a user sends a "join" request and when the requested data streaming first reaches the user. Leave latency is the time between when a user sends a "leave" signal and when the - network stops streaming to the user. - - Leave and Join latencies impact the acceptable user experience for - fast channel surfing. In an IP-TV application, users are not going - to be receptive to a slow response time when changing channels. - If there are policies for controlling the number of simultaneous - streams a user may access then channel surfing will be determined - by the join and leave latencies. - - Furthermore, leave affects resource consumption: with a low - "leave latency" network providers could minimize streaming content - when there are no audiences. + network stops streaming to the user. Leave and Join latencies impact + the acceptable user experience for fast channel surfing. In an IP-TV + application, users are not going to be receptive to a slow response + time when changing channels. If there are policies for controlling + the number of simultaneous streams a user may access then channel + surfing will be determined by the join and leave latencies. + Furthermore, leave affects resource consumption: with a low "leave + latency" network providers could minimize streaming content when + there are no audiences. It is important that any overhead for + authentication, authorization, and access-control be minimized at the + times of joining and leaving multicast channels so as to achieve join + and leave latencies acceptable in terms of user experience. For + example this is important in an IP-TV application, because users are + not going to be receptive to a slow response time when changing + channels. - It is important that any overhead for authentication, - authorization, and access-control be minimized at the times of - joining and leaving multicast channels so as to achieve join and - leave latencies acceptable in terms of user experience. For - example this is important in an IP-TV application, because users - are not going to be receptive to a slow response time when - changing channels. +7. Concomitant requirements - (11) Scalability + Scalability Solutions that are used for AAA and QoS enabled IP multicasting should scale enough to support the needs of content providers and - network operators. NSP's multicast access and QoS policies should - be manageable for large scale users. (e.g. millions of users, - thousands of edge-routers) - - (12) Small Impact on the Existing Products - - Impact on the existing products (e.g., protocols, software, etc.) - should be as minimal as possible. + network operators. NSP's multicast access and QoS policies should be + manageable for large scale users. (e.g. millions of users, thousands + of edge-routers) - Ideally the NSP should be able to use the same infrastructure - (such as access control) to support commercial multicast services - for the so called "triple play" services: voice (VoIP), video, and - broadband Internet access services. + Service and Terminal Portability: - When a CP requires the NSP to provide a level of QoS surpassing - "best effort" delivery or to provide special services (e.g., to - limited users with specific attributes), certain parameters of the - CDS may be defined by a contractual relation between the NSP and - the CP. However, just as for best-effort unicast, multicast - allows for content sourced by CPs without a contractual relation - with the NSP. Therefore, solutions addressing the requirements - defined in this memo should not make obsolete multicasting that - does not include AAA features. NSPs may offer tiered services, - with higher QOS, accounting, authentication, etc., depending on - contractual relation with the CPs. It is therefore important that - Multicast AAA and QoS functions be as modular and flexible as - possible. + Depending on the service, networks should allow for a user to receive + a service from different places and/or with a different terminal + device. - (13) Deployable as Alternative to Unicast + Deployable as Alternative to Unicast IP Multicasting would ideally be available as an alternative to IP - unicasting when the "on-demand" nature of unicasting is not - required. Therefore interfaces to multicasting should allow for - easy integration into CDS systems that support unicasting. - - Especially equivalent interfaces for authorization, access control - and accounting capabilities should be provided. - - (14) Multicast Replication - - The above requirements should also apply if multicast replication - is being done on an access-node (e.g. DSLAMs or OLTs). - - Specific functional requirements for each application can be - derived from the above general requirements. An example is shown - in the section 5. - - 5. Application Example and its Specific Requirements - - This section shows an application example which could benefit from - multicasting. Then, specific functional requirements related to - user-based accounting capabilities are derived. - - 5.1 IP Multicast-based Content Delivery Service (CDS): CP and NSP are - different entities (companies) - - Broadband access networks such as ADSL (Asymmetric Digital - Subscriber Line) or FTTH (Fiber to the Home) have been deployed - widely in recent years. Content Delivery Service (CDS) is expected - to be a major application provided through broadband access - networks. Because many services such as television broadcasting - require huge bandwidth (e.g., 6Mbit/s) and processing power at - content server, IP multicast is used as an efficient delivery - mechanism for CDS. - - One way to provide high quality CDS is to use closed networks - ("walled-garden" model). - - This subsection shows an example where CP and NSP are different - entities (companies). - - 5.1.1 Network Model for Multicast Content Delivery Service - - As shown in Fig.2, networks for CDS contain three different types - of entities: Content Provider (CP), Network Service Provider (NSP), - and user clients. An NSP owns the network resources - (infrastructure). It accommodates content providers on one side - and accommodates user clients on the other side. NSP provides the - network for CDS to two other entities (i.e., CPs and user clients). - A CP provides content to each user through the network of NSPs. - NSPs are responsible for delivering the content to user clients, - and for controlling the network resources. - - +-------------+ +-------------+ +-------------+ - | CP | | CP | | CP | - | #1 | | #2 | | #3 | - | +---------+ | | +---------+ | | +---------+ | - | | content | | | | content | | | | content | | - | | server | | | | server | | | | server | | - | +-------+-+ | | +----+----+ | | +-+-------+ | - +----------\--+ +------|------+ +--/----------+ - \ | / - \ | / <- network/network - \ | / interface - +------------- \ ------ | ------ / ----+ - | \ | / | - | NSP +-+-----+-----+-+ | - | | Provider Edge | | - | +-------+-------+ | +-----------------+ - | | |---| Information | - | | | | server | - | +--+------+---+ | +-----------------+ - | | User Edge | | - | +--+---+---+--+ | - | / | \ | - +------------- / --- | --- \ ----------+ - / | \ - / | \ <- user/network interface - / | \ - +---------++ +-----+----+ ++---------+ - |client #a | |client #b | |client #c | - +----------+ +----------+ +----------+ - User A User B User C + unicasting when the "on-demand" nature of unicasting is not required. + Therefore interfaces to multicasting should allow for easy + integration into CDS systems that support unicasting. Especially + equivalent interfaces for authorization, access control and + accounting capabilities should be provided. - Fig.2 Example of CDS network configuration + Support of ASM and SSM - The NSP provides the information server for all multicast channels, - and a CP gives detailed channel information (e.g., Time table of - each channel) to the information server. An end-user client gets - the information from the information server. In this model, - multicasting is used in the NSP's CDS network, and there are two - different contracts. One is the contract between the NSP and the - user which permits the user to access the basic network resources - of the NSP. Another contract is between the CP and user to permit - the user to subscribe to multicast content. Because the CP and NSP - are different entities, and the NSP generally does not allow a CP - to control (operate) the network resources of the NSP, user - authorization needs to be done by the CP and NSP independently. - Since there is no direct connection to the user/network interface, - the CP cannot control the user/network interface. A user may want - to move to another place, or may want to change her/his device - (client) any time without interrupting her/his reception of - services. As such, IP Multicast network should support - portability capabilities. + Both ASM (G), and SSM (S,G) should be supported as multicast models. - 5.1.2 Content Delivery Service Requirements + Small Impact on the Existing Products - Below are listed specific requirements to support common business - cases/ contractual arrangements for the IP Multicast-based Content - Delivery Service. + Impact on the existing products (e.g., protocols, software, etc.) + should be as minimal as possible. Ideally the NSP should be able to + use the same infrastructure (such as access control) to support + commercial multicast services for the so called "triple play" + services: voice (VoIP), video, and broadband Internet access + services. When a CP requires the NSP to provide a level of QoS + surpassing "best effort" delivery or to provide special services + (e.g., to limited users with specific attributes), certain parameters + of the CDS may be defined by a contractual relation between the NSP + and the CP. However, just as for best-effort unicast, multicast + allows for content sourced by CPs without a contractual relation with + the NSP. Therefore, solutions addressing the requirements defined in + this memo should not make obsolete multicasting that does not include + AAA features. NSPs may offer tiered services, with higher QOS, + accounting, authentication, etc., depending on contractual relation + with the CPs. It is therefore important that Multicast AAA and QoS + functions be as modular and flexible as possible. - 5.1.2.1 Accounting Requirements + Multicast Replication - An NSP may have different contractual agreements with various CPs - or various legal obligations in different locations. One possible - business relationship between a CP and NSP is that of a revenue - sharing which could be on a per content/usage-base. A solution - should support varied billing and charging methods to satisfy both - common legal and business/financial requirements to deploy - multicasting services: this requires accurate and near real-time - accounting information about the user clients' activity accessing - the content services. - The user accessing particular content is represented by the user's - activities of joining or leaving the corresponding multicast - group/channel (<(*,g)> or (s,g)). In multicast networks, only NSPs - can collect joining or leaving activities in real-time through - their user edges. The NSPs can transfer the accounting information - to related CPs for them to generate user billing information. - Existing standard AAA technology may be used to transfer the - accounting information. + The above requirements should also apply if multicast replication is + being done on an access-node (e.g. DSLAMs or OLTs). - To match the accounting information with a particular user, the - user has to be authenticated. Usually the account information of a - user for content access is maintained by the CP. A user may have - different user accounts for different CPs.(e.g. user_a@cp#1 and - user_b@cp#2) The account is usually in the format of (username, - password) so an user can access the content services from anywhere. - For example, an user can access the CP from different NSPs.(e.g. a - fixed line NSP and a mobile NSP). It should be noted that the user - account used for content access can be different from the one used - for network access maintained by NSPs. +8. Constituent Logical Functional Components - The NSP-CP model represents a multi-domain AAA environment. There - are plural cases of the model depending on the trust relationship - between the NSP and CP, and additional service requirements such - as a certain QoS level guarantee or service/terminal portability. + Below is a diagram of a AAA enabled multicasting network, including + the logical components within the various entities. - A mechanism is necessary to allow a CP and NSP to grasp each - user's behavior independently. + +-------------------------------+ + | user | + |+- - - - - - - - - - - - - - -+| + || CPE || + || || + |+- - - - - | - - - - - - - - -+| + +-----------|-------------------+ + | + -------|------ IFa + | + +-----------|-----------------------+ + | NSP | | + | | | + |+- - - - - |- - _+ + - - - - - + | + || | | | | | | + | +------|-+ | +--------+ | + || | AN | | | | | MACF || | + | | | | | | | + || +------|-+ | | | +---|----+| | + | | | | | | + | | | | IFd----- | | + | | | IFb | | | + || +------|---+ | | | +---|----+| | + | | |---|---| mAAA | | + || | NAS | | | | |(MACF *)|| | * optional + | +----------+ | +--------+ | + ||+- - - - - - - -+ - - |- - - - -+ | + +-----------------------|-----------+ + | + -------|------ IFc + | + +-----------------------|-------+ + | CP +---------+ | + | | CP-AAA | | + | +---------+ | + +-------------------------------+ - Another requirement related to accounting is the ability to notify - a user when accounting really starts. When a "free preview" - capability is supported, accounting may not start at the same time - as the user's joining of the stream. + AAA enabled multicasting network with admission control - Any solution addressing the requirements of this memo should - consider the Interdomain accounting issues presented in RFC-2975 - [3]. It is especially important to consider that the CP and NSP - as separate administrative entities can not be assumed to trust - one another. The solution should be robust enough to handle - packet loss between entity domains and assure for data integrity. - In addition any solution should take into consideration common - legal or financial requirements requiring confidential archiving - of usage data. + Figure 3 - 5.1.2.2 Authorization Requirements + The user entity includes the CPE (Customer Premise Equipment) which + connects the receiver (s). - The NSPs are responsible for delivering content and are generally - required to meet certain QoS levels or SLA (service level - agreements). For example, video quality is very sensitive to packet - loss. So if an NSP --due to limited network resources -- cannot - meet quality requirements if it accepts an additional user request, - the NSP should reject that user's access request to avoid charging - the existing (i.e., already-joined) user for bad services. For - example, if an access line is shared by several users, an - additional user's join may cause performance degradation for other - users. If the incoming user is the first user on a user edge, this - will initiate the transmission of data between the provider edge - and the user edge and this extra network traffic may cause - performance degradation. There may also be policies that do not - necessarily give highest priority to the "first-come" users, and - these should also be considered. + The NSP (Network Service Provider) includes the transport system and + a logical element for multicast AAA functionality. The TS (transport + system) is comprised of the access node and NAS (Network Access + Server) An AN (Access Node) 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 the scope for this memo. The + multicast AAA function may be provided by a mAAA which may include + the function that downloads Join access control lists to the NAS + (this function is referred to as the conditional access policy + control function.) - In order to protect network resources against misuse/malicious - access and maintain a QoS level, appropriate admission control - function for traffic policing purposes is necessary so that the NSP - can accept or reject the request without degrading the QoS beyond - the specified level. + Interface between mAAA and NAS - 5.1.2.3 Authentication Requirements + The interface between mAAA and the NAS is labeled IFb in Figure 3. + Over IFb the NAS sends an access request to the NSP-mAAA and the mAAA + replies. The mAAA may push conditional access policy to the NAS. - There are two different aims of authentication. One is - authentication for network access, and another one is for content - access. For the first case of authentication, NSP has a AAA server, - and for the second case, each CP has a AAA server. In some cases, - CPs delegate (outsource) the operation of user authentication to - NSPs. + CP-AAA - As such, in addition to network access, multicast access by a user - also needs to be authenticated. Content authentication should - support the models where: - - authentication for multicast content is outsourced to the - NSP. - - authentication for multicast content access is operated by - the CP + The content provider may have its own AAA server which has the + authority over access policy for its contents. - 5.2 IP Multicast-based Content Delivery Service (CDS): CP and NSP are - the same entities (companies) + Interface between user and NSP - Another application example is the case where the content provider - (CP) and network service provider (NSP) are the same entity - (company) as shown in Fig. 3. In the case that the CP and NSP are - the same entity, some of the requirements indicated in 4.1 are not - required. + The interface between the user and the NSP is labeled IFa in Figure + 3. Over IFa the user makes a multicasting request to the NSP. The + NSP may in return forward multicast traffic depending on the NSP and + CP's policy decisions. - This model does not require the following items: + Interface between NSP and CP - - Communication method between sender (content server) and - user. Since they belong to the same company, they can use - all the available information. + 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-proxying. - - Methods to share user-related information between NSPs and - CPs. - +-----------------------------------------------------+ - | +---------+ | - | | content | | - | | server | | - | +----+----+ | - | | | - | CP+NSP +-------+-------+ | - | | Provider Edge | | - | +-------+-------+ +--------------------+ | - | | | Information server | | - | | +--------------------+ | - | +-------------+ | - | | User Edge | | - | +--+---+---+--+ | - | / | \ | - +----------- / --- | --- \ ---------------------------+ - / | \ - / | \ <- user/network interface - / | \ - +---------++ +-----+----+ ++---------+ - |Client #a | |client #b | |client #c | - +----------+ +----------+ +----------+ - User A User B User C + The NSP may also include a component that provides network resource + management (e.g. QoS management), as described in section 5, + "Admission Control for Multicasting". Resource management and + admission control is provided by MACF (Multicast Admission Control + Function). This means that, 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 forwarding multicast traffic. MACF + also receives Leave information from NAS so that MACF releases + corresponding reserved resources. - Fig.3 Example of CDS network configuration - 6. Acknowledgments +9. Acknowledgments - The authors of this draft would like to express their appreciation - to Pekka Savola of Netcore Ltd., Daniel Alvarez, and Toerless - Eckert of Cisco Systems, Sam Sambasivan of AT&T, Sanjay Wadhwa of - Juniper, Tom Anschutz and Steven Wright of BellSouth, Nicolai - Leymann of T-Systems, Carlos Garcia Braschi of Telefonica Empresas, - Marshall Eubanks of Multicast Techno, Stephen Rife of NTT and - David Meyer in his role as mboned WG chair, as well as their - thanks to the participants of the MBONED WG in general. + The authors of this draft would like to express their appreciation to + Christian Jacquenet of France Telecom whose contributions to the "AAA + Framework for Multicasting" [draft-ietf-mboned-multiaaa-framework] + largely influenced this draft, Pekka Savola of Netcore Ltd., Daniel + Alvarez, and Toerless Eckert of Cisco Systems, Sam Sambasivan of + AT&T, Sanjay Wadhwa, Greg Shepherd, and Leonard Giuliano of Juniper, + Tom Anschutz and Steven Wright of BellSouth, Nicolai Leymann of + T-Systems, Bill Atwood of Concordia University, Carlos Garcia Braschi + of Telefonica Empresas, Marshall Eubanks in his role as mboned WG + chair, Ron Bonica in his role as Director as the Operations and + Management Area, Stephen Rife of NTT and David Meyer in his former + role as mboned WG chair, as well as their thanks to the participants + of the MBONED WG in general. Funding for the RFC Editor function is currently provided by the Internet Society. - 7. IANA Considerations +10. IANA Considerations This memo does not raise any IANA consideration issues. - 8. Security Considerations +11. Security Considerations Accounting capabilities can be used to enhance the security of - multicast networks by excluding ineligible clients from the - networks. + multicast networks by excluding ineligible clients from the networks. - These requirements are not meant to address encryption issues. - Any solution meeting these requirements should allow for the + These requirements are not meant to address encryption issues. Any + solution meeting these requirements should allow for the implementation of encryption such as MSEC on the multicast data. - 9. Privacy considerations +12. Privacy considerations - Any solution which meets these requirements should weigh the - benefits of user-based accounting with the privacy considerations - of the user. For example solutions are encouraged when applicable - to consider encryption of the content data between the content - provider and the user in such a way that the Network Provider does - not know the contents of the channel. + Any solution which meets these requirements should weigh the benefits + of user-based accounting with the privacy considerations of the user. + For example solutions are encouraged when applicable to consider + encryption of the content data between the content provider and the + user in such a way that the Network Provider does not know the + contents of the channel. + +13. Conclusion - 10. Conclusion This memo describes general requirements for providing AAA and QoS - enabled IP multicasting services. It lists issues related to - accounting, authentication, authorization and admission control - for multicast content delivery. Content Delivery Services with - different business models are cited as the type of application - which could benefit from the capabilities of AAA and QoS enabled - IP multicasting described in this document. + enabled IP multicasting services in multi-entity models. A few + models are evaluated with regard to their support by current + technologies. The "multi-entity CDS with direct billing of the end + user" model is presented and requirements for information sharing + between entities and requirements for admission control to enable + guaranteeing of QoS are derived. Performance requirements and + concomitant requirements are also presented. - Normative References +14. Normative References - [1] B. Cain, et. al., "Internet Group Management Protocol, Version - 3", RFC3376, October 2002. + [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to + Accounting Management", RFC 2975, October 2000. - [2] R. Vida, et. al., "Multicast Listener Discovery Version 2 - (MLDv2) for IPv6", RFC3810, June 2004. + [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. + Thyagarajan, "Internet Group Management Protocol, Version + 3", RFC 3376, October 2002. - [3] Aboba B , et. al., "Introduction to Accounting Management", - RFC 2975, October 2000. + [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery + Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Authors' Addresses Tsunemasa Hayashi NTT Network Innovation Laboratories - 1-1 Hikarino'oka, Yokosuka-shi, Kanagawa, 239-0847 Japan + 1-1 Hikarino'oka + Yokosuka-shi, Kanagawa 239-0847 + Japan + Phone: +81 46 859 8790 Email: hayashi.tsunemasa@lab.ntt.co.jp Haixiang He Nortel - 600 Technology Park Drive Billerica, MA 01801, USA + 600 Technology Park Drive + Billerica, MA 01801 + USA + Phone: +1 978 288 7482 Email: haixiang@nortel.com - Hiroaki Satou NTT Network Service Systems Laboratories - 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan + 3-9-11 Midoricho + Musashino-shi, Tokyo 180-8585 + Japan + Phone: +81 422 59 4683 Email: satou.hiroaki@lab.ntt.co.jp Hiroshi Ohta NTT Network Service Systems Laboratories - 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan + 3-9-11 Midoricho + Musashino-shi, Tokyo 180-8585 + Japan + Phone: +81 422 59 3617 Email: ohta.hiroshi@lab.ntt.co.jp Susheela Vaidya Cisco Systems, Inc. - 170 W. Tasman Drive San Jose, CA 95134 + 170 W. Tasman Drive + San Jose, CA 95134 + USA + Phone: +1 408 525 1952 Email: svaidya@cisco.com