[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12

   Internet Draft     AAA Framework for Multicasting       April 2006



                                                     Hiroaki Satou, NTT
   Internet Draft                                     Hiroshi Ohta, NTT
   Expires: October 6, 2006                      Tsunemasa Hayashi, NTT
                                           Haixiang He, Nortel Networks



                                                          April 4, 2006


                      AAA Framework for Multicasting
               <draft-ietf-mboned-multiaaa-framework-00.txt>


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.


   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.



   Satou, Ohta, Hayashi, He                                   [Page 1]


   Internet Draft     AAA Framework for Multicasting       April 2006




   This Internet-Draft will expire on October 6, 2006.


Copyright Notice


   Copyright (C) The Internet Society (2006)


Abstract
   This memo provides a generalized framework for solution standards to
   meet the requirements presented in draft-ietf-mboned-maccnt-req-
   04.txt, "Requirements for Accounting, Authentication and
   Authorization in Well Managed IP Multicasting Services". In this
   framework a user sends a request for multicast data to a network
   service provider.  The network service provider selects the
   appropriate content provider to send the user's request.  The
   request is sent by the network service provider to the content
   provider transparently in a way so that the network service provider
   and content provider do not need to know the corresponding user id
   for the same user in the other provider's domain.  The content
   provider then responds with an indication of "success" or "failure"
   to the network provider and in the case of "success", the network
   provider may delivery the requested data to the user.  The network
   service may base its decision to deliver such data to the user based
   on its bandwidth management policy.  The framework is designed to be
   flexible and extendible, so it will be possible to implement
   partially enabled versions as well as fully enabled versions of the
   model.  Also an additional entity may provide transit of requests
   between network service providers and content providers, either
   through relaying or tunneling.


1. Introduction

1.1 Purpose and Background

   IP multicasting is designed to serve cases where a single source of
   data content is to be concurrently streamed to multiple recipients.



   Satou, Ohta, Hayashi, He                                   [Page 2]


   Internet Draft     AAA Framework for Multicasting       April 2006


   In these types of cases, multicasting provides resource efficiencies
   (both for the overall network and the content server) relative to
   unicasting.  These efficiencies are possible because of the
   avoidance of unnecessary duplication of streams, video/audio
   processing, etc. Multicasting also provides resource efficiencies
   relative to IP broadcasting in that content data is only delivered
   to end hosts which request it.

   There are many real-life situations where IP multicasting is
   selected as the technology used for concurrent content delivery of
   identical content data to multiple end-hosts.   "Requirements for
   Accounting, Authentication and Authorization in Well Managed IP
   Multicasting Services", (draft-ietf-mboned-maccnt-req-04.txt,
   hereafter MACCNT-REQ-draft) describes the requirements in CDN
   services using IP multicast[1]. "Issues Related to Receiver Access
   Control in the Current Multicast Protocols" (draft-ietf-mboned-rac-
   issues-02.txt, hereafter RAC-ISSUES-draft) discusses the
   requirements and existing support for commercial, large-scale
   content delivery[2].  The requirements are derived from:
        - need for user tracking and billing capabilities
        - need for network access control and/or content access control
   to satisfy the requirements of the 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
   solution standards to meet these requirements. This framework is to
   provide a basis for defining protocols, but definition of the actual
   protocols is outside of the scope of this memo.


2. Definitions and Abbreviations

2.1 Definitions

   For the purposes of this memo the following definitions apply:

   Accounting: actions for grasping each user's behavior, when she/he
   starts/stops to receive a channel, which channel she/he receives,
   etc.




   Satou, Ohta, Hayashi, He                                   [Page 3]


   Internet Draft     AAA Framework for Multicasting       April 2006


   Authentication: action for identifying a user as a genuine one.

   Authorization: action for giving permission to access the content or
   network to a user.

   Receiver: an end-host or end-client which receives content.  A
   receiver may be distinguishable by a network ID such as MAC address
   or IP address.

   User: a human with a user account.  A user may possibly use multiple
   reception devices.  Multiple users may use the same reception device.

   Note: The definition of a receiver (device) and a user (human)
   should not be confused.


2.2 Abbreviations

   For the purposes of this draft the following abbreviations apply:

   ACL: Access Control List

   CDN: Content Delivery Network

   CDS: Content Delivery Services

   CP: Content Provider

   NSP: Network Service Provider

   TP: Transit Provider


3. Issues in multicasting related to commercial and large-scale
   implementations

   This section lists issues related to receiver access control in
   current multicasting protocols which are especially important to
   commercial, large-scale multicasting.  More details concerning the
   requirements related to these issues are provided in MACCNT-REQ-
   draft. References to that memo are provided as applicable below.




   Satou, Ohta, Hayashi, He                                   [Page 4]


   Internet Draft     AAA Framework for Multicasting       April 2006



3.1 Framework for multicast AAA allowing bandwidth Management

   A general high-level framework can be represented as follows.

            +------------------------------+
            |    user                      |
            |                              |
            +------------------------------+
                | Access       ^ Response
                | Request      | & Multicast Data
                V              |
            +------------------------------+
            |    NSP                       |
            |                              |
            +------------------------------+
                | Access         ^ Response
                | Request        | (Success)
                v                |
            +------------------------------+
            |    CP                        |
            |                              |
            +------------------------------+

   For the sake of simplicity, the above diagram portrays a case where
   there is a single NSP entity and a single CP entity.  Under the
   framework it is possible for there to be multiple CPs 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.

   Description of Roles:

   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 for STB or a mobile NSP for mobile phone.

   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 NSP is responsible for managing its network resources.  The NSP
   may perform admission control to protect bandwidth resource and
   needs authorized information regarding user access for bandwidth
   management. It is also responsible for confirming (authentication by
   proxy) with the CP whether the user is eligible to receive content.




   Satou, Ohta, Hayashi, He                                   [Page 5]


   Internet Draft     AAA Framework for Multicasting       April 2006


   In addition to the three basic entities of user, NSP and CP, this
   AAA framework for multicasting supports transit provision which
   transfers multicast streams from the CP to the NSP.


3.2 Multiple User IDs

   Users may be assigned separate user IDs for each subscription for
   various NSPs and CPs.  When the user wants to access content or
   otherwise use the network, the user registers the corresponding user
   ID with a request for content, etc: web authentication is one
   possible method.

   Terminal portability can be realized if the NSP authenticates a user
   using a user ID. This allows the user to access the content from
   various network access points.

   Each CP may identify users by the user IDs that it has issued to
   them.

   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.


3.3 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 directed. It is
   necessary for the NSP to ensure that it is not spoofed by an
   inappropriate CP.


3.4 Network Resource Management by NSP

   After authorizing a user request, the NSP may conduct admission
   control based on its bandwidth management policy. For example, if
   the NSP manages the shared bandwidth of access lines, the NSP might
   calculate available bandwidth and necessary bandwidth, and based on
   these calculations determine to accept or reject a user request.


3.5 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.





   Satou, Ohta, Hayashi, He                                   [Page 6]


   Internet Draft     AAA Framework for Multicasting       April 2006


3.6 Multicast Session Management for Accounting

   The NSP should not manage multicast states on a subnet basis, but on
   a user basis because the NSP needs to notify start and stop times
   for accounting purposes. This means that the NSP sends an indication
   for Join and Leave on a user basis.


4. Network Connection Model and Functional Components

   Section 3.1 introduces the high-level AAA framework for multicasting.
   This section provides more detail on the network connection model
   and constituent functional components.



   Satou, Ohta, Hayashi, He                                   [Page 7]


   Internet Draft     AAA Framework for Multicasting       April 2006


4.1 Basic Connection Model

                  +-------------+
                  |     user    |
                  |             |
                  +-------------+
                          ^ Access & Resource
                          | Request
                          v
                  +-------------+
                  |     NSP     |
                  |             |
                  +-------------+
                          ^ Access
                          | Request
                          v
                  +-------------+
                  |     CP      |
                  |             |
                  +-------------+

   First a user desiring authorization sends an Access request to an
   NSP which then forwards it on to the appropriate CP for
   Authentication and Authorization. The CP responds with either
   "success" of "failure".  If "success", the NSP may forward a success
   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.




   Satou, Ohta, Hayashi, He                                   [Page 8]


   Internet Draft     AAA Framework for Multicasting       April 2006


4.2 Transit Provision

   The diagram below shows that a Transit Provider(hereafter, TP)  may
   relay requests between NSPs and CPs.

                  +-------------+
                  |     user    |
                  |             |
                  +-------------+
                          ^ Access & Resource
                          | Request
                          v
                  +-------------+
                  |     NSP     |
                  |             |
                  +-------------+
                          ^ Access & Resource
                          | Request
                          v
                  +-------------+
                  |     TP      |
                  |             |
                  +-------------+
                          ^ Access
                          | Request
                          v
                  +-------------+
                  |     CP      |
                  |             |
                  +-------------+

   For the sake of simplification the above diagram shows a 1-1
   relationship between an NSP and a TP.  However it is also possible
   for a single NSP to connect to multiple TPs, and a single TP to
   multiple NSPs.

   A single TP may connect to one or more CPs. Similarly just as a
   single CP may connect to multiple NSPs (as described in the general
   high-level framework, section 3.1), a single CP may connect to one
   or more TPs.

   A solution will include a mechanism through which the NSPs know
   which TP(s) are to be used to communicate with which CP(s), and CPs
   know which TP(s) to use for which NSP(s).  When a TP receives an
   access or resource request from an NSP or CP, it must relay the
   request to the correct CP or NSP, respectively.  Minimally, this
   means that it must reconstruct the request with translated address
   information.  In this model therefore a TP must understand the
   format and meaning of the requests.




   Satou, Ohta, Hayashi, He                                   [Page 9]


   Internet Draft     AAA Framework for Multicasting       April 2006


   There may be multiple TPs between a NSP and CP so that a TP is
   actually receiving from and/or sending requests to another TP and
   not directly from/to a NSP or CP.

4.3 Transit with Tunnels

   In addition to the above model of request relaying, a TP may
   communicate requests through tunneling based on the contract between
   the TP and the NSP and/or between the TP and the CP.  So in this
   case the TP will not directly need to process the contents of the
   access and resource request (such as, header information), but
   instead pass the request directly to the correct NSP or CP, using a
   separate protocol to wrap the original requests.

   Below is a diagram, representing how a TP can provider tunneling
   between NSP(s) and CP(s).

                  +-----------------+
                  |     user        |
                  |                 |
                  +-----------------+
                          ^ Access & Resource
                          | Request
                          v
                  +------------------+
                  |       NSP        |
                  |                  |
                  +------------------+
                    |^|
                    |:|
                    |:|
                  +-|:|--------------+
                  | |:|   TP         |
                  | |:|              |
                  +-|:|--------------+
                    |:|
                    |:| Tunnel
                    |:|
                    |V|
                  +------------------+
                  |       CP         |
                  |                  |
                  +------------------+

   In this model too, the relationship between NSP and TP and between
   transit provider and CP can be 1:1, 1:N or M:N.




   Satou, Ohta, Hayashi, He                                  [Page 10]


   Internet Draft     AAA Framework for Multicasting       April 2006


4.4 Constituent Logical Functional Components of the fully enabled AAA
Framework

   Section 3.1 introduces the high-level AAA framework for multicasting.
   Below is a diagram of a fully enabled multicasting network with AAA,
   including the logical components within the various entities.


            +-------------------------------+
            |            user               |
            |                               |
            +-------------------------------+
                          ^
                          | Access & resource request
                          v
            +-------------------------------+
            |            NSP                |
            |                               |
            |+--------------+    +---------+|
            ||NR Management |<-->|AAA Proxy||    (NR= network resource)
            |+--------------+ RR +---------+|    (RR= resource request)
            +-------------------------------+
                          ^
                          | Access request
                          v
            +------------------------------+
            |             CP               |
            |                              |
            |         +---------+          |
            |         |   AAA   |          |
            |         +---------+          |
            +------------------------------+

   In the fully enabled model the NSP provides proxying of
   authentication and authorization between the NSP and CP, as well as
   user-based accounting.  The AAA proxy server of the NSP communicates
   with the CP's AAA server.  Although not show in the above diagram
   for the sake of simplicity, in addition to direct proxying between a
   NSP and CP, this proxying may be done through a TP.  This means that
   the transit provider too is able to support AAA proxying.

   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".
   When a transit provider is used it may also provide Network Resource
   management of its own resources.

4.5 Modularity of the framework




   Satou, Ohta, Hayashi, He                                  [Page 11]


   Internet Draft     AAA Framework for Multicasting       April 2006


   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 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.


5. IANA considerations

   This memo does not raise any IANA consideration issues.


6. Security considerations

   Refer to section 3.3.  Also the user information related to
   authentication with the CP should be protected in some way.
   Otherwise, this memo does not raise any new security issues which
   are not already existing in the original protocols.  Enhancement of
   multicast access control capabilities may enhance security
   performance.


7. 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 break down the content provider and network
   service provider entities into their functional objects such as edge
   devices, AAA servers, etc.


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.
   [2] Hayashi, et. al., "Issues Related to Receiver Access Control in
       the Current Multicast Protocols", draft-ietf-mboned-rac-issues-
       02.txt, March 2006, Work in Progress.


Authors' Addresses

           Hiroaki Satou
           NTT Network Service Systems Laboratories
           3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan
           Phone : +81 422 59 4683



   Satou, Ohta, Hayashi, He                                  [Page 12]


   Internet Draft     AAA Framework for Multicasting       April 2006


           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

           Tsunemasa Hayashi
           NTT Network Innovation Laboratories
           1-1 Hikari-no-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


Comments

   Comments are solicited and should be addressed to the mboned working
   group's mailing list at mboned@lists.uoregon.edu_and/or the authors.



   Satou, Ohta, Hayashi, He                                  [Page 13]


   Internet Draft     AAA Framework for Multicasting       April 2006



Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   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.

   This document and the information contained herein are provided on
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology described
   in this document or the extent to which any license under such
   rights might or might not be available; nor does it represent that
   it has made any independent effort to identify any such rights.
   Information on the procedures with respect to rights in RFC
   documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository
   at 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 October 6, 2006.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



   Satou, Ohta, Hayashi, He                                  [Page 14]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/