--- 1/draft-ietf-mboned-maccnt-req-08.txt 2010-03-05 09:11:09.000000000 +0100 +++ 2/draft-ietf-mboned-maccnt-req-09.txt 2010-03-05 09:11:09.000000000 +0100 @@ -1,100 +1,75 @@ -mboned T. Hayashi -Internet-Draft NTT Network Innovation -Intended status: Informational Laboratories -Expires: January 14, 2010 H. He +mboned T. Hayashi, +Internet-Draft H. Satou, +Intended status: Informational H. Ohta +Expires: September 6, 2010 NTT + H.He Nortel - H. Satou - H. Ohta - NTT Network Service Systems - Laboratories S. Vaidya Cisco Systems, Inc. - July 13, 2009 + March 5, 2010 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 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." - - 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 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 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. + draft-ietf-mboned-maccnt-req-09 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 where Authentication, Accounting and Authorization + limited to cases where Authentication, Authorization and Accounting (AAA) functions are coordinated between Content Provider(s) and Network Service Provider(s). In order to describe the new requirements of a multi-entity Content - Deliver System(CDS) using multicast, the memo presents three basic + Delivery Service(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. 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. 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. +Status of this Memo + This Internet-Draft is submitted to IETF in full conformance with the + provisions of BCP 78 and 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 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 September 6, 2010. + 1. Introduction 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. @@ -160,21 +136,21 @@ 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 - AAA: Authentication, Accounting and Authorization + AAA: Authentication, Authorization and Accounting ASM: Any-Source Multicast CDS: Content Delivery Service CP: Content Provider IGMP: Internet Group Management Protocol MLD: Multicast Listener Discovery @@ -262,22 +237,21 @@ 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. -4. Proposed Model: Multity-entity CDS with direct billing of the end - user +4. Proposed Model: Multity-entity CDS 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 @@ -422,21 +396,43 @@ accepted if delivery of the requested stream would push the consumed bandwidth over the NSP policy-defined limit. 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 +6. Reauthorization and deauthorization requirements + + A mechanism for periodic reauthorization of users who have already + joined a channel stream should be supported. The reauthorization + could be an authorization check based on the NSP's eligibility + requirements and/or could involve the NSP querying the CP for + reauthorization of a user. + + A mechanism for deauthorization should be supported for cases in + which a user is deemed ineligible by the NSP and/or CP at the time of + a reauthorization check. If a NSP revokes authorization for the + network for a user it should force a leave, and record details of the + leave (including the time and reason for the forced leave.) If a CP + revokes authorization to content for a user the CP signals to the NSP + to cease streaming to that user. An example usage case for + deauthorizing a user is one where a user has a subscription or has + paid for a certain amount of content and has reached that limit. In + some models, it is conceivable that a CP could communicate the + parameters for de-authorization to the NSP at the time of the + original join's authorization so as to make NSP to CP reauthorization + requests unnecessary. + +7. 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 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 @@ -447,21 +443,21 @@ 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. -7. Concomitant requirements +8. Concomitant requirements 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) Service and Terminal Portability: @@ -476,20 +472,26 @@ 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. Support of ASM and SSM Both ASM (G), and SSM (S,G) should be supported as multicast models. + Support for Tunneled Multicast + + The AAA requirements specified in this document should apply to both + end-to-end native multicast and to tunnel-enabled multicast, such as + AMT multicast: [I-D.ietf-mboned-auto-multicast] + Small Impact on the Existing Products 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 @@ -501,21 +503,21 @@ 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. Multicast Replication The above requirements should also apply if multicast replication is being done on an access-node (e.g. DSLAMs or OLTs). -8. Constituent Logical Functional Components +9. Constituent Logical Functional Components Below is a diagram of a AAA enabled multicasting network, including the logical components within the various entities. +-------------------------------+ | user | |+- - - - - - - - - - - - - - -+| || CPE || || || |+- - - - - | - - - - - - - - -+| @@ -597,119 +599,157 @@ 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. -9. Acknowledgments +10. Acknowledgments 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. + 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; Mark Altom, Andy Huang, Tom Imburgia, Han + Nguyen, Doug Nortz of ATT Labs; 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 Digital Garage 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. -10. IANA Considerations +11. IANA Considerations This memo does not raise any IANA consideration issues. -11. Security Considerations +12. Security Considerations Accounting capabilities can be used to enhance the security of 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 implementation of encryption such as MSEC on the multicast data. -12. Privacy considerations +13. 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. -13. Conclusion +14. Conclusion This memo describes general requirements for providing AAA and QoS 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. -14. Normative References +15. References + +15.1. Normative References [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to Accounting Management", RFC 2975, October 2000. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. +15.2. Informative References + + [I-D.ietf-mboned-auto-multicast] + Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T. + Pusateri, "Automatic IP Multicast Without Explicit Tunnels + (AMT)", draft-ietf-mboned-auto-multicast-09 (work in + progress), June 2008. + Authors' Addresses Tsunemasa Hayashi - NTT Network Innovation Laboratories + Nippon Telegraph and Telephone Corporation 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 - - Phone: +1 978 288 7482 - Email: haixiang@nortel.com Hiroaki Satou - NTT Network Service Systems Laboratories + Nippon Telegraph and Telephone Corporation 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 + Nippon Telegraph and Telephone Corporation 3-9-11 Midoricho Musashino-shi, Tokyo 180-8585 Japan Phone: +81 422 59 3617 Email: ohta.hiroshi@lab.ntt.co.jp + Haixiang He + Nortel + 600 Technology Park Drive + Billerica, MA 01801 + USA + + Phone: +1 978 288 7482 + Email: haixiang@nortel.com + Susheela Vaidya Cisco Systems, Inc. 170 W. Tasman Drive San Jose, CA 95134 USA Phone: +1 408 525 1952 Email: svaidya@cisco.com + +Copyright and License Notice + + Copyright (c) 2010 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. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + 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.