Tsunemasa Hayashi, NTT
     Internet Draft                                 Haixiang He, Nortel
     Document:draft-ietf-mboned-maccnt-req-07.txt    Hiroaki Satou,
mboned                                                        T. Hayashi
Internet-Draft                                    NTT Network Innovation
Intended Status: status: Informational                   Hiroshi Ohta, NTT                              Laboratories
Expires: July 16, 2009              Susheela Vaidya, Cisco Systems January 12, 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) <draft-ietf-mboned-
                             maccnt-req-07.txt>
                    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 July 16, 2009. 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. 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 where Authentication, Accounting and Authorization
   (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
   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.
   listed and the constituent logical functional components are
   presented.

   This memo assumes that these the capabilities can be realized by functions implemented
   integrating AAA functionalities with a multicast CDS system, with
   IGMP/MLD at edges the edge of a network based
     on IGMP the network.

1.  Introduction

   Broadband access networks such as ADSL (Asymmetric Digital Subscriber
   Line) or MLD.  Finally, cases for FTTH (Fiber to the Home) have been deployed widely in recent
   years.  Content Delivery Services Service (CDS) are described as is expected to be a major
   application examples which could benefit
     from multicasting accounting and provided through broadband access control capabilities networks.  Because many
   services such as
     described in this memo.

     This memo defines requirements related to AAA issues 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 multi- CDS.

   A single entity provider models 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 network service 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 provider cooperate consumption.
   Furthermore it is possible to provide CDS and various related AAA
     functions for purposes such as protecting and accounting for the tie access to the network and QoS based
   on a user's contract status.  Therefore current technologies support
   the single entity case.

   Often, however, the content provision and network resources.  The requirements provision roles are
     generally not relevant to cases in which there is not a reason to
     share AAA functions
   split between separate entities.

                              Table of Contents

     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  Commonly, Content Delivery Service (CDS): CP Providers (CP) do
   not build 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 maintain their own multicast network infrastructure as
   this is not their primary business area.  Instead, CPs often purchase
   transport 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

  1. Introduction management services from network service providers.
   This memo presents general functional lists the requirements related to
     accounting, access control and admission control issues of a business model in IP
     multicasting networks. A multicast network which fulfills all of
     these requirements the NSP
   provides CDS using multicast as one such contractible service.

   The direct revenue source for the multiple entity provider is called a "fully AAA and QoS enabled" IP
     multicasting network here. Fulfillment of all or some
   defining aspect of the business model which often has implications on
   requirements will make possible more robust management of IP
     multicasting networks.

     IP multicasting is becoming widely used as a method to save
     network resources for the technologies that support the system.  There are
   cases such as bandwidth or CPU processing power of the
     sender's server for cases the advertising-based model where a large volume of information
     needs to be distributed to a very large number billing end-users
   is not done and therefore accounting of receivers at a
     given data speed.  This trend content consumption can be observed both in enterprise
     use and
   anonymous and/or 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. aggegrate.  In these examples, sources generate high-bit rate (e.g., 6Mbit/s)
     streaming information.  When cases the number requirements of receivers becomes large,
     such systems do not scale well without multicasting.

     On
   the other hand, business model for accounting for billing purposes are already
   supported by existing technologies.  However, the NSP can not
   guarantee high quality transmission on a content delivery service (CDS) per-content basis with
   existing technologies.

   There is an example also the business model in which the individual user of a broadband service provided by network operators/service
     providers.  Distribution
   multicasted contents is the source of movies revenue for both consumed
   content and other video programs network resources.  In this model the NSP wants to
     each user is a typical service.  Each channel requires large
     bandwidth (e.g., 6Mbit/s)
   receive the appropriate fees for multicast services 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 NSP
   undertakes collecting bills as a few
     thousands).  A system to provide this proxy for the CPs.  The NSP may
   provide high quality service does not scale well
     without multicasting.

     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 by admission control.  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
   do 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.

     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 fully support this model and maintenance.

     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.

     This this memo first describes problems on accounting issues in
     multicasting.  Then will list 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. need to be supported.

2.  Definitions and Abbreviations

  2.1

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
      eligible to players that can decode H.264 or 3GPP streams), their
      access network has (e.g., HDTV content may only be eligible to
      users with 10 Mbps or faster access line), or because of where
      they are in network topology (e.g., HDTV content may not be
      eligible for users across congested links) or in actual geography
      (e.g., content may only be licensed for distribution to certain
      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

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)  Current Business Models

3.1.  Single entity model where CP 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 NSP are the client same entity

   One existing business model 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]) that of a single entity responsible
   for both content and network service provision which bills its users
   based on content provision.  (See figure below.)

          +-----------------------------------------------------+
          |              +---------+                            |
          |              | Content |                            |
          |              | Server  |                            |
          |              +----+----+                            |
          |                   |                                 |
          | CP+NSP    +-------+-------+                         |
          |           | Provider Edge |                         |
          |           +-------+-------+                         |
          |                   |                                 |
          |                   |                                 |
          |           +-------------+                           |
          |           | User Edge   |                           |
          |           +--+---+---+--+                           |
          |             /    |    \                             |
          +----------- / --- | --- \ ---------------------------+
                      /      |      \
                     /       |       \ <- user/network interface
                    /        |        \
         +---------++  +-----+----+   ++---------+
         |Client #A |  |Client #B |   |Client #C |
         +----------+  +----------+   +----------+
           User A       User B         User C

                   Example of CDS network configuration

                                 Figure 1

   In this model the network can query a content-policy-enabled AAA
   server just feeds within its
     information to the multicast router [as in Fig.1].  Then, the
     multicast router replicates the data to any link which has own domain at
     least one client requesting the information.    In this process,
     no eligibility check is conducted.  Any client time a user requests content.
   The network can receive provide the AAA server with information just by requesting it.

     It is envisioned that there are many large-scale such as user
   identity, device identity, the requested content
     distribution applications transferred over IP-based networks (channel),
   geographic information, method of network connection, etc. that
     can leverage multicasting technologies to meet their scalability
     requirements might
   be required 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 the content provision authorization decision.  It is needed
     if one wants
   therefore possible to charge for distributed information on configure a non-flat-
     fee basis. The current standards do not provide multicasting with
     authorization or access control capabilities sufficient network to meet deny network access
   based on the requirements content policy decision.

   In this model there are no issues of accounting.

     |--- mapping user ----|------------NSP------------------|-----CP---|

       +--------+
       | user   |\
       +--------+ \
                   \+------+    +------+    +------+    +------+
       +--------+   |Multi-|    |Multi-|    |Multi-|    |      |
       | user   |---|cast  |----|cast  |----|cast  |----|Server|
       +--------+   |router|    |router|    |router|    |      |
                   /+------+    +------+    +------+    +------+
       +--------+ /
       | user   |/
       +--------+

              Fig.1 Example network for multicast communication

     As such, the same level of user-based accounting capabilities as
     provided in unicast networks should be provided in multicast
     networks.

  3.2  Relationship with Secure Multicasting (MSEC)

     In many cases, content encryption (e.g. MSEC) is an effective
     method for preventing unauthorized identities between
   different entity domains.  The provider has 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 information
   on which user accessed from which point on what device.  Furthermore
   as network resources (link bandwidth, router's
     processing power, etc.) , and 2) accounting to grasp provider they can record not only when a user activity
     in 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.

   The functional requirements do not require single entity network service and content
     encryption although it might solve some of provider also knows the
   content related
     problems.  At this point, it schedules for various channels.  This is important not yet clear whether encryption
     would be part of a solution only
   for time and if so, what other components (if
     any) would content-sensitive authorization decisions but 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
   providing meaningful billing details to let ineligible
     users waste large amounts of bandwidth: end users.

3.2.  Multiple entity model without direct content-based billing

   An additional model for example encryption
     protects against content viewing but NSP desires protection
     against DoS attacks of ineligible users wasting network resources,
     even if it delivering contents over a CDS is the
   advertising-based model where billing end-users is encrypted. not done.  In this
   model the four different roles may be filled by separate entities:
   Content encryption Provider (CP), Network Service Provider (NSP), user clients,
   and multicast access
     control should both be able to coexist for more robust security.

  3.3  Regarding Access Media and User Separation

     The requirements defined 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 memo apply model does not require any new standards 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. user-based accounting for a multi-entity CDS using VLAN). However, IP multicast solutions
   with shared Layer 2 access media between the
     user and multicast router AAA.  (Providing this data in near real-time and no logical user separation (e.g.
     Ethernet inline would
   entail further requirements which can be dealt with shared links and no VLAN) are out of scope in a separate
   memo if necessary.)

   A more complex version of this
     memo. Nevertheless, some of the requirements business model is conceivable in this memo defined
     for multicasting which
   a CP may also be relevant require a user to multicasting over links
     without either physical or logical enter into a subscription contract, even
   when the user separation.  Therefore in does not get billed for content consumption.  For
   example, a CP may value individual data because it allows it to
   supply the interest of modularity advertisers with rich, user-segmented data and flexibility, solutions addressing charge a
   higher premium.  In that case the requirements of this memo may also take into account
     application to multicasting without such user separation.

  4. General AAA-related Functional Requirements for IP Multicasting

     In consideration of the issues presented in next section 3,
   "CDS with direct billing of the
     following requirements have been derived:

     (1) User identification

     The network should be able end user" are generally applicable
   because of the need to identify each link the user when they attempt data which the CP has to access the service so
   actual viewing (or stream downloading) data that necessary access controlling actions
     can be applied.  Also, it is necessary to identify the user's
     receiver (e.g. IP address) NSP has.

4.  Proposed Model: Multity-entity CDS with direct billing of each request (e.g., join/leave) for
     per host tracking purposes.

     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 end
    user

   In this model the sender and routers are
     maintained by networks for CDS contain three different entities.

     (2) Issue types of
   entities: Content Provider (CP), Network Resource Protection

     In order to guarantee certain QoS it is important for 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 be able two
   entities (i.e., CPs and user clients).  A CP provides content to protect their each
   user through the network resources from being
     wasted, (either maliciously or accidentally).

     For comparisons sake, of NSPs and charges users for unicast this issue can be resolved e.g.
     by using RSVP in some cases.

     (2.1) Access control

     The network should be able content.  NSPs
   are responsible for delivering the content to apply necessary access controlling
     actions when an eligible user requests an action (such as a join
     or a leave.)  The clients, and for
   controlling the network should be able to reject any action
     requested from an ineligible user.

     (2.2) Control mechanism to support bandwidth of multicast stream
          from resources.  A NSP charges a physical port of edge router user or switch
     The a CP for
   network usage.  A NSP may need to control the combined bandwidth charge users for all
     channels at the physical port content as a proxy of the edge router or switch so that
     these given physical entities are not overflowed with traffic.

     (2.3) Control mechanism of number of channels delivered from a
          physical port of edge router and switch

     If an NSP desires to guarantee a certain level of QoS to
   CP.

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

     For comparisons sake, for unicast this issue can be resolved e.g.
     by using RSVP in some cases.

     (3) User Authentication

     The network should be able to authenticate a user.

     (4) 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          |  | CP          |
          |          #1 |  |          #2 |  |          #3 |
          | +---------+ |  | +---------+ |  | +---------+ |
          | | Content | |  | | Content | |  | | Content | |
          | | Server  | |  | | Server  | |  | | Server  | |
          | +-------+-+ |  | +----+----+ |  | +-+-------+ |
          +----------\--+  +------|------+  +--/----------+
                      \           |           /
                       \          |          / <- network/network
                        \         |         /     interface
          +------------- \ ------ | ------ / ----+
          |               \       |       /      |
          |   NSP would not want to waste its network
     resources on ineligible users.

     (5) Accounting and Billing

     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.

     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.

     (5.1) How to share user information

     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.

     (6) 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).

     (7) Service and Terminal Portability

     Depending on the service, networks should allow for a user to
     receive a service from different places and/or with a different
     terminal device.

     (8) Support of ASM and SSM

     Both ASM (G), and SSM (S,G) should be supported as multicast
     models.

     (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         +-+-----+-----+-+      |
          |               | Provider Edge |      |
          |               +-------+-------+      |
          |                       |              |
          |                       |              |
          |             +--+------+---+          |
          |             | User Edge   |          |
          |             +--+---+---+--+          |
          |               /    |    \            |
          +------------- / --- | --- \ ----------+
                        /      |      \
                       /       |       \ <- user/network interface
                      /        |        \
           +---------++  +-----+----+   ++---------+
           |Client #A |  |Client #B |   |client #C |
           +----------+  +----------+   +----------+
           User A        User B         User C

                   Example of
     streams it serves to a user, and total bandwidth consumed to that
     user. For example if the number CDS network configuration

                                 Figure 2

   The CP provides detailed channel information (e.g., Time table of streams being served
   each channel) 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 information server which is
     controlling either managed 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

     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 or CP.  An end-user client gets the user.

     Leave and Join latencies impact information from the acceptable user experience for
     fast channel surfing.
   information server.  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 this model, multicasting is used in the join NSP's
   CDS network, 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 two different contracts.  One 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
   contract between the NSP and
     leave latencies acceptable in terms of the user which permits the 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.

     (11)  Scalability

     Solutions that are used for AAA and QoS enabled  IP multicasting
     should scale enough to support
   access the needs of content providers and basic network operators. NSP's multicast access and QoS policies should
     be manageable for large scale users. (e.g. millions of users,
     thousands resources 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.

     Ideally NSP.  Another contract is
   between the NSP should be able CP and user to use permit the same infrastructure
     (such as access control) user to subscribe to support commercial multicast services
     for
   content.  Because the so called "triple play" services: voice (VoIP), video, and
     broadband Internet access services.

     When a CP requires and NSP are different entities, and the NSP to provide
   generally does not allow a level of QoS surpassing
     "best effort" delivery or to provide special services (e.g., CP to
     limited users with specific attributes), certain parameters control (operate) the network
   resources of the
     CDS may NSP, user authorization needs to be defined done by a contractual relation between the NSP CP
   and NSP independently.  Since there is no direct connection to the CP.  However, just as for best-effort unicast, multicast
     allows for content sourced by CPs without a contractual relation
     with
   user/network interface, the NSP.  Therefore, solutions addressing CP cannot control the requirements
     defined in this memo should not make obsolete multicasting that
     does not include AAA features. NSPs user/network
   interface.  A user may offer tiered services,
     with higher QOS, accounting, authentication, etc., depending on
     contractual relation with want to move to another place, or may want to
   change her/his device (client) any time without interrupting her/his
   reception of services.

4.1.  Information Required by Entities to Support the CPs. It is therefore important that
     Multicast AAA and QoS functions be as modular Proposed Business
      Model

      User identification and flexible as
     possible.

     (13) Deployable as Alternative to Unicast

     IP Multicasting would ideally Authentication:

      The network should be available as an alternative able to IP
     unicasting identify and authenticate each user
      when they attempt to access the "on-demand" nature of unicasting service requesting content.  This
      user identification is not
     required. Therefore interfaces to multicasting should allow required for:

         authorization for
     easy integration into CDS systems that support unicasting.

     Especially equivalent interfaces content consumption eligibility

         user tracking for authorization, access control billing based on actual content consumption
         and accounting capabilities should be provided.

     (14) Multicast Replication network resource usage

      With current protocols (IGMP/MLD), the sender cannot distinguish
      which receivers (end hosts) are actually receiving the
      information.  The above requirements should also apply if multicast replication
     is being done sender must rely 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 information from the section 5.

  5. Application Example and its Specific Requirements
      multicasting routers.  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 can be complicated if the sender and NSP
      routers are maintained by different entities (companies)

     Broadband access networks such as ADSL (Asymmetric Digital
     Subscriber Line) or FTTH (Fiber to entities.  Furthermore, the Home) have been deployed
     widely in recent years. Content Delivery Service (CDS) is expected
     to
      current user associated with receiver must be identified.

      User Authorization:

      The network, at its option, should be able to authorize a major application provided through broadband user's
      access
     networks. Because many services such as television broadcasting
     require huge bandwidth (e.g., 6Mbit/s) and processing power at to content server, IP or a multicast is used group, so 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 meet any demands
      by a 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 to prevent content access by ineligible users.

      Sharing Programming data:

      NSP owns needs a mechanism to receive channel programming data from the network resources
     (infrastructure). It accommodates content providers on one side
     and accommodates user clients on
      CP in order to provide the other side. NSP provides information to the
     network user at channel
      selection time and also for CDS somehow logging or recording what
      programming content has been streamed to two other entities (i.e., CPs and user clients).
     A the user.  In some cases
      the CP provides content may contract the NSP to each bill the user through as a proxy for the network of NSPs.
     NSPs are responsible
      CP.  In this case there needs to be a mechanism for delivering supplying the content
      user-based viewing history with human-meaningful channel data to user clients,
      the end-user.

      Content usage information by user:

      For billing and for controlling auditing purposes the network resources.

       +-------------+  +-------------+  +-------------+
       | CP          |  | CP          |  | CP          |
       |          #1 |  |          #2 |  |          #3 |
       | +---------+ |  | +---------+ |  | +---------+ |
       | | content | |  | | content | |  | | content | |
       | | server  | |  | | server  | |  | | server  | |
       | +-------+-+ |  | +----+----+ |  | +-+-------+ |
       +----------\--+  +------|------+  +--/----------+
                   \           |           /
                    \          |          / <- network/network
                     \         |         /     interface
       +------------- \ ------ | ------ / ----+
       |               \       |       /      |
       | needs the NSP         +-+-----+-----+-+      |
       |               | Provider Edge |      |
       |               +-------+-------+      |   +-----------------+
       |                       |              |---| Information     |
       |                       |              |   | server          |
       |             +--+------+---+          |   +-----------------+
       |             | User Edge   |          |
       |             +--+---+---+--+          |
       |               /    |    \            |
       +------------- / --- | --- \ ----------+
                     /      |      \
                    /       |       \ <- user/network interface
                   /        |        \
        +---------++  +-----+----+   ++---------+
        |client #a |  |client #b |   |client #c |
        +----------+  +----------+   +----------+
        User A        User B         User C

                 Fig.2 Example of CDS network configuration

     The 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 provides to the CP.  If
      the information server for all multicast channels,
     and a CP gives detailed channel information (e.g., Time table is selling on an on-demand model, or tiered subscription
      basis or supplies some sort of
     each channel) 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 server. An end-user client gets 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.

      Notification to Users of the Result of the Join Request:

      It should be possible to provide information from to the user about the
      status of his/her join request(granted/denied/other).  Such
      information server. In this model,
     multicasting is can be used in to give meaningful feedback to the NSP's CDS network, and there are two
     different contracts. One user.

5.  Admission Control for Multicasting

   In order to guarantee certain QoS it is the contract between the important for network
   providers (at their option) to be able to protect their network
   resources from being wasted, (either maliciously or accidentally).
   The NSP and the should be able to apply appropriate access controlling
   actions based on user which permits eligibility status:

      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.

   In order to maintain a predefined QoS level, depending on the NSP's
   policy, a user edge should be able to access control the basic network resources number of the NSP.  Another contract is between the CP streams
   it serves to a user, and user total bandwidth consumed to permit that user.  For
   example if the user to subscribe number of streams being served to multicast content. Because a certain user has
   reached the CP and NSP
     are different entities, and limit defined by the NSP generally does NSP's policy, then the user edge
   should not allow accept a CP
     to control (operate) the network resources subsequent "join" until one of the NSP, user
     authorization needs to be done by existing
   streams is terminated.  Similarly, if the CP and NSP independently.
     Since there is no direct connection to controlling by per-
   user bandwidth consumption, then a subsequent "join" should not be
   accepted if delivery of the user/network interface, requested stream would push the CP cannot control consumed
   bandwidth over the user/network interface. A user may want
     to move to another place, or NSP policy-defined limit.

   The network may want need to change her/his device
     (client) any time without interrupting her/his reception control the combined bandwidth for all
   channels at the physical port of
     services.  As such, IP Multicast network should support
     portability capabilities.

  5.1.2 Content Delivery Service Requirements

     Below the edge router or switch so that
   these given physical entities are listed specific requirements not overflowed with traffic.  This
   entails being able to support common business
     cases/ contractual arrangements 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 Multicast-based Content
     Delivery Service.

  5.1.2.1 Accounting Requirements

     An NSP may multicasting are likely to have different contractual agreements with various CPs
     or various legal obligations
   strict requirements in different locations.  One possible
     business relationship terms of user experience.  Join latency is the
   time between when a CP user sends a "join" request and NSP when the
   requested data streaming first reaches the user.  Leave latency is that of
   the time between when a revenue
     sharing which could be on user sends a per content/usage-base.  A solution
     should support varied billing and charging methods to satisfy both
     common legal "leave" signal and business/financial requirements when the
   network stops streaming to deploy
     multicasting services:  this requires accurate the user.  Leave and near real-time
     accounting information about Join latencies impact
   the acceptable user clients' activity accessing 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 content services.
     The number of simultaneous streams a user accessing particular 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 represented by important that any overhead for
   authentication, authorization, and access-control be minimized at the user's
     activities
   times of joining or and leaving the corresponding multicast
     group/channel (<(*,g)> or (s,g)). In multicast networks, only NSPs
     can collect joining or leaving activities channels so as to achieve join
   and leave latencies acceptable in real-time through
     their terms of user edges. The NSPs can transfer the accounting information
     to related CPs for them experience.  For
   example this is important in an IP-TV application, because users are
   not going to generate user billing information.
     Existing standard AAA technology may be used receptive to transfer the
     accounting information.

     To match the accounting information with a particular user, the
     user has slow response time when changing
   channels.

7.  Concomitant requirements

   Scalability

   Solutions that are used for AAA and QoS enabled IP multicasting
   should scale enough to be authenticated. Usually support the account information needs of a
     user for content providers and
   network operators.  NSP's multicast 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 QoS policies should be
   manageable for large scale users. (e.g. millions of (username,
     password) so an user can access users, thousands
   of edge-routers)

   Service and Terminal Portability:

   Depending on the content services from anywhere.
     For example, an service, networks should allow for a user can access the CP to receive
   a service from different NSPs.(e.g. a
     fixed line NSP and places and/or with a mobile NSP). It should different terminal
   device.

   Deployable as Alternative to Unicast

   IP Multicasting would ideally be noted that available as an alternative to IP
   unicasting when the user
     account used "on-demand" nature of unicasting is not required.
   Therefore interfaces to multicasting should allow for content access can be different from the one used easy
   integration into CDS systems that support unicasting.  Especially
   equivalent interfaces for network authorization, access maintained by NSPs.

     The NSP-CP model represents a multi-domain AAA environment. There
     are plural cases 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.

   Small Impact on the model depending Existing Products

   Impact on the trust relationship
     between existing products (e.g., protocols, software, etc.)
   should be as minimal as possible.  Ideally the NSP and CP, and additional service requirements such should be able to
   use the same infrastructure (such as a certain QoS level guarantee or service/terminal portability.

     A mechanism is necessary access control) to allow support
   commercial multicast services for the so called "triple play"
   services: voice (VoIP), video, and broadband Internet access
   services.  When a CP and requires the NSP to grasp each
     user's behavior independently.

     Another requirement related provide a level of QoS
   surpassing "best effort" delivery or to accounting is the ability provide special services
   (e.g., to notify
     a user when accounting really starts.  When a "free preview"
     capability is supported, accounting limited users with specific attributes), certain parameters
   of the CDS may not start at be defined by a contractual relation between the same time
     as NSP
   and the user's joining of CP.  However, just as for best-effort unicast, multicast
   allows for content sourced by CPs without a contractual relation with
   the stream.

     Any solution NSP.  Therefore, solutions addressing the requirements of defined in
   this memo should
     consider 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 Interdomain accounting issues presented in RFC-2975
     [3]. CPs.  It is especially therefore important to consider that the CP Multicast AAA and NSP
     as separate administrative entities can not be assumed to trust
     one another.  The solution should QoS
   functions be robust enough to handle
     packet loss between entity domains as modular and assure for data integrity.
     In addition any solution should take into consideration common
     legal or financial requirements requiring confidential archiving
     of usage data.

  5.1.2.2 Authorization Requirements flexible as possible.

   Multicast Replication

   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 above 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, also apply 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 multicast replication is the first user
   being done on an access-node (e.g.  DSLAMs or OLTs).

8.  Constituent Logical Functional Components

   Below is a user edge, this
    will initiate the transmission diagram of data between a AAA enabled multicasting network, including
   the provider edge
    and logical components within the various entities.

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

    In order to protect                          |
         |+- - - - - - - - - - - - - - -+|
         || CPE                         ||
         ||                             ||
         |+- - - - - | - - - - - - - - -+|
         +-----------|-------------------+
         |
         -------|------ IFa
         |
         +-----------|-----------------------+
         |  NSP      |                       |
         |           |                       |
         |+- - - - - |- - _+   + - - - - - + |
         ||        |   | |   |           | |
         |    +------|-+ |       +--------+  |
         ||   | AN     | | |   | | MACF  || |
         |    |        | |       |        |  |
         ||   +------|-+ | |   | +---|----+| |
         |           |   |           |    |  |
         |           |   | |     IFd----- |  |
         |           |   |  IFb      |    |  |
         ||   +------|---+ | | | +---|----+| |
         |    |          |---|---| mAAA   |  |
         ||   | NAS      | | | | |(MACF *)|| | * optional
         |    +----------+ |     +--------+  |
         ||+- - - - - - - -+ - - |- - - - -+ |
         +-----------------------|-----------+
         |
         -------|------ IFc
         |
         +-----------------------|-------+
         | CP               +---------+  |
         |                  |  CP-AAA |  |
         |                  +---------+  |
         +-------------------------------+

          AAA enabled multicasting network resources against misuse/malicious
    access and maintain a QoS level, appropriate with admission control
    function for traffic policing purposes is necessary so that the NSP
    can accept or reject

                                 Figure 3

   The user entity includes the request without degrading CPE (Customer Premise Equipment) which
   connects the QoS beyond receiver (s).

   The NSP (Network Service Provider) includes the specified level.

  5.1.2.3 Authentication Requirements

     There are two different aims of authentication.  One is
     authentication for network access, transport system and another one is
   a logical element for content
     access. For the first case multicast AAA functionality.  The TS (transport
   system) is comprised of authentication, NSP has the access node and NAS (Network Access
   Server) An AN (Access Node) may be connected directly to mAAA or a
   NAS relays AAA server, information between an AN and for the second case, each CP has a AAA server. In some cases,
     CPs delegate (outsource) the operation mAAA.  Descriptions of user authentication to
     NSPs.

     As such, in addition to network access,
   AN and its interfaces are out of the scope for this memo.  The
   multicast access AAA function may be provided by a user
     also needs mAAA which may include
   the function that downloads Join access control lists to be authenticated.  Content authentication should
     support the models where:
          - authentication for multicast content NAS
   (this function is outsourced referred to as the
            NSP.
          - authentication for multicast content conditional access is operated by
            the CP

  5.2 IP Multicast-based Content Delivery Service (CDS): CP policy
   control function.)

   Interface between mAAA and NAS

   The interface between mAAA and NSP are the same entities (companies)

     Another application example NAS is labeled IFb in Figure 3.
   Over IFb the case where NAS sends an access request to the NSP-mAAA and the mAAA
   replies.  The mAAA may push conditional access policy to the NAS.

   CP-AAA

   The content provider
     (CP) may have its own AAA server which has the
   authority over access policy for its contents.

   Interface between user and network service provider (NSP) are NSP

   The interface between the same entity
     (company) as shown user and the NSP is labeled IFa in Fig. Figure
   3.  In  Over IFa the case that 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.

   Interface between NSP and CP

   The interface between the NSP and CP is labeled IFc.  Over IFc the
   NSP are requests to the same entity, some of CP-AAA for access to contents and the requirements indicated CP replies.
   CP may also send conditional access policy over this interface for
   AAA-proxying.

   The NSP may also include a component that provides network resource
   management (e.g.  QoS management), as described in 4.1 are not
     required.

     This model does not require the following items:

          - Communication method between sender (content server) section 5,
   "Admission Control for Multicasting".  Resource management and
            user.  Since they belong
   admission control is provided by MACF (Multicast Admission Control
   Function).  This means that, before replying to the same company, they can use
            all user's multicast
   request, the mAAA queries the MACF for a network resource access
   decision over the available information.

          - 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

                 Fig.3 Example of CDS IFd.  The MACF is responsible for
   allocating network configuration
  6. resources for forwarding multicast traffic.  MACF
   also receives Leave information from NAS so that MACF releases
   corresponding reserved resources.

9.  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 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 of Multicast Techno, 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.

10.  IANA Considerations

   This memo does not raise any IANA consideration issues.

  8.

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

  9.

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.

  10.

13.  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 services in multi-entity models.  A few
   models are cited as the type evaluated with regard to their support by current
   technologies.  The "multi-entity CDS with direct billing of application
     which could benefit from the capabilities of AAA end
   user" model is presented and requirements for information sharing
   between entities and requirements for admission control to enable
   guaranteeing of QoS enabled
     IP multicasting described in this document. are derived.  Performance requirements and
   concomitant requirements are also presented.

14.  Normative References

     [1] B.

   [RFC2975]  Aboba, B., Arkko, J., and D. Harrington, "Introduction to
              Accounting Management", RFC 2975, October 2000.

   [RFC3376]  Cain, et. al., B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC3376, RFC 3376, October 2002.

     [2] R.

   [RFC3810]  Vida, et. al., R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC3810, RFC 3810, June 2004.

     [3] Aboba B , et. al., "Introduction to Accounting Management",
         RFC 2975, October 2000.

Authors' Addresses

   Tsunemasa Hayashi
   NTT Network Innovation Laboratories
   1-1 Hikarino'oka, Hikarino'oka
   Yokosuka-shi, Kanagawa, 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,  01801
   USA

   Phone: +1 978 288 7482
   Email: haixiang@nortel.com
   Hiroaki Satou
   NTT Network Service Systems Laboratories
   3-9-11 Midoricho, Midoricho
   Musashino-shi, Tokyo, 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, Midoricho
   Musashino-shi, Tokyo, 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
   USA

   Phone: +1 408 525 1952
   Email: svaidya@cisco.com