Internet Draft  AAA Framework for Multicasting  November
                      2007

                                                                    Hiroaki Satou, NTT
                         Internet Draft                              Hiroshi Ohta, NTT
                         Expires: Jan 10, 2008 May 17,          Christian Jacquenet, France Telecom
         Intended status: Informational
                         2008
                                                                Tsunemasa Hayashi, NTT
                                                          Haixiang He, Nortel Networks

                                                          July 9,

                                                                     November 19, 2007

                                    AAA Framework for Multicasting
             <draft-ietf-mboned-multiaaa-framework-04.txt>
                             <draft-ietf-mboned-multiaaa-framework-05.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.

                       Internet Draft  AAA Framework for Multicasting  November
                      2007

                         The list of Internet-Draft Shadow Directories can be
                         accessed at http://www.ietf.org/shadow.html.

                         This Internet-Draft will expire on January 10, May 17, 2008.

                      Copyright Notice

                        Copyright (C) The IETF Trust (2007).  This document
                         is subject to the rights, licenses and restrictions
                         contained in BCP 78, and except as set forth therein,
                         the authors retain all their rights.

                      Abstract
                         IP multicast-based services, such as TV broadcasting
                         or videoconferencing raise the issue of making sure
                         that potential customers are fully entitled to
                         access the corresponding contents. There is indeed a
                         need for service and content providers to identify
                         (if not authenticate, especially within the context
                         of enforcing electronic payment schemes) and to
                         invoice such customers in a reliable and efficient
                         manner. This memo describes the framework for
                         specifying the Authorization, Authentication and
                         Accounting (AAA) capabilities that could be
                         activated within the context of the deployment and
                         the operation of IP multicast-based services.  This
                         framework addresses the requirements presented in draft-ietf-mboned-
         maccnt-req-04.txt,
                         draft-ietf-mboned-maccnt-req-04.txt, "Requirements
                         for Accounting, Authentication and Authorization in
                         Well Managed IP Multicasting Services". The memo
                         provides a basic AAA enabled model as well as an
                         extended fully enabled model with resource and
                         admission control coordination.

               STATUS OF THIS MEMO                                            1
               COPYRIGHT NOTICE                                               2
               ABSTRACT                                                       2
               1. INTRODUCTION                                                5
               1.1 PURPOSE AND BACKGROUND                                     5
               2. DEFINITIONS AND ABBREVIATIONS                               6
               2.1 DEFINITIONS                                                6
               2.2 ABBREVIATIONS                                              7
               3. COMMON USE MODELS AND NETWORK ARCHITECTURE IMPLICATIONS     7
               4. FRAMEWORK AND ROLES OF ENTITIES                             8
               4.1 FRAMEWORK FOR MULTICAST AAA                                8
               4.1.1 MULTIPLE CPS ARE CONNECTED TO MULTIPLE NSPS              9
               4.1.2 MULTIPLE CPS ARE CONNECTED TO A SINGLE NSP              10
               4.1.3 A SINGLE CP IS CONNECTED TO MULTIPLE NSPS               11
               4.1.4 A SINGLE CP IS CONNECTED TO SINGLE NSP                  11
               4.2 USER ID                                                   11
               4.2.1 CP-ASSIGNED USER ID                                     12
               4.2.2 NSP-ASSIGNED USER ID                                    12
               4.3 ACCOUNTING                                                12
               4.4 ACCESS CONTROL AND CP SELECTION BY NSP                    13
               4.5 ADMISSION CONTROL INFORMATION BY NSP                      13
               4.6 ACCESS CONTROL AND DISTINGUISHING OF USERS BY CP          14
               4.7 AAA PROXY IN NSP                                          14
               5.1 BASIC CONNECTION MODEL                                    14
               5.2 CONSTITUENT LOGICAL FUNCTIONAL COMPONENTS OF THE FULLY
               ENABLED AAA FRAMEWORK                                         15
               5.3 MODULARITY OF THE FRAMEWORK                               19
               6. IANA CONSIDERATIONS                                        19
               7. SECURITY CONSIDERATIONS                                    19
               8. CONCLUSION                                                 19
               NORMATIVE REFERENCES                                          19
               AUTHORS' ADDRESSES                                            20
               COMMENTS                                                      20
               FULL COPYRIGHT STATEMENT                                      21
               COPYRIGHT (C) THE IETF TRUST (2007).                          21
               INTELLECTUAL PROPERTY                                         21
               EXPIRATION                                                    21
               ACKNOWLEDGEMENT                                               22
                1. Introduction

                1.1 Purpose and Background
                  IP multicasting is designed to serve cases of group
                  communication schemes of any kind, such as 1-to-n (case of
                  TV broadcasting services for example) or n-to-p (case of
                  videoconferencing services, for example).
                     In these environments, IP multicast provides a better
                  resource optimization than using a unicast transmission
                  scheme, where data need to be replicated as many times as
                  there are receivers. Activation of IP multicast
                  capabilities in networks yields the establishment and the
                  maintenance of multicast distribution trees that are
                  receiver-initiated by nature: multicast-formatted data are
                  forwarded to receivers who explicitly request them.

                       IP multicast-based services, such as TV broadcasting
                  or videoconferencing raise the issue of making sure that
                  potential customers are fully entitled to access the
                  corresponding contents.
                  There is indeed a need for service and content providers to
                  identify (if not authenticate, especially within the
                  context of enforcing electronic payment schemes) and to
                  invoice such customers in a reliable and efficient manner.
                  Solutions should consider a wide range of possible content
                  delivery applications: content delivered over the multicast
                  network may include video, audio, images, games, software
                  and information such as financial data, etc.

                        This memo describes a framework for specifying the
                  Authorization, Authentication and Accounting (AAA)
                  capabilities that could be activated within the context of
                  the deployment and the operation of IP multicast-based
                  services. This memo also describes a framework to realize
                  high-quality multicast transport using a Resource and
                  Admission Control System (RACS) with multicast
                  Authorization.
                  Specifically, this framework addresses the requirements
                  presented in draft-ietf-mboned-maccnt-req-04.txt, draft-ietf-mboned-maccnt-req-05.txt,
                  "Requirements for Accounting, Authentication Multicast AAA coordinated between Content
                  Provider(s) and
   Authorization in Well Managed IP Multicasting Services"
   MACCNT-REQ-draft Network Service Provider(s)" MACCNT-REQ-
                  draft describes the requirements in CDN services using IP
                  multicast[1]. The requirements are derived from:
                       - need for user tracking and billing capabilities
                       - need for network access control to satisfy the
                  requirements of the Network Service Provider (NSP) and/or
                  content access control to satisfy the requirements of the
                  Content Provider (CP)
                       - methods for sharing information between the network
                  service provider and content provider to make it possible
                  to fulfill the above two requirements.

                  Detailed requirements are presented in MACCNT-REQ-draft.
                  These requirements include mechanisms for recording end-
                  user requests and provider responses for content-delivery,
                  sharing user information (possibly anonymously depending on
                  the trust model) between content provider and network
                  service provider, and protecting resources through the
                  prevention of network and content access by unauthorized
                  users, as well as other AAA related requirements.

                  The purpose of this memo is to provide a generalized
                  framework for
                  specifying multicast-inferred AAA capabilities that can
                  meet these requirements. This framework is to provide a
                  basis for future work of investigating the applicability of
                  existing AAA protocols to provide these AAA capabilities in
                  IP multicast specific context and/or if deemed necessary,
                  the refining or defining of protocols to provide these
                  capabilities.

                2. Definitions and Abbreviations

                2.1 Definitions

                  For the purpose of this memo the following definitions
                  apply:

                  Accounting: The set of capabilities that allow the
                  retrieval of a set of statistical data that can be defined
                  on a per customer and/or a per service basis, within the
                  context of the deployment of multicast-based services. Such
                  data are retrieved for billing purposes, and can be
                  retrieved on a regular basis or upon unsolicited requests.
                  Such data include (but are not necessarily limited to) the
                  volume of multicast-formatted data that have been forwarded
                  to the receiver over a given period of time, the volume of
                  multicast-formatted data that have been exchanged between a
                  receiver (or set of) and a given source over a given period
                  of time (e.g. the duration of a multicast session), etc.

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

                  Authorization: The set of capabilities that need to be
                  activated to make sure a given requesting customer is (1)
                  what he claims to be (identification purposes), and (2) is
                  fully entitled to access a set of services (authentication
                  purposes).

                  Receiver: an end-host or end-client which receives content.
                  A receiver may be identified 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 purpose of this draft the following abbreviations
                  apply:

                  ACL: Access Control List

                  AN: Access Node

                  CAPCF: Conditional Access Policy Control Function

                  CDN: Content Delivery Network

                  CDS: Content Delivery Services

                  CP: Content Provider

                  CPE: Customer Premise Equipment

   mRACF:

                  MACF: Multicast Resource and Admission Control Function

                  NSP: Network Service Provider

                  TS: Transport System

                3. Common use models and network architecture implications

                  In some cases a single entity may design and be responsible
                  for a system that covers the various common high-level
                  requirements of a multicasting system such as 1) content
                  serving, 2) the infrastructure to multicast it, 3) network
                  and content access control mechanisms. In many cases
                  however the content provision and network provision roles
                  are divided between separate entities.  The MACCNT-REQ-
                  draft provides more detail of the multiple versus single
                  entity CDS network models.

                  As such it should not be assumed that the entity
                  responsible for the multicasting structure and the entity
                  responsible for content serving are the same.  Indeed
                  because the infrastructure for multicasting is expensive
                  and many content holders are not likely to be competent at
                  building and maintaining complicated infrastructures
                  necessary for multicasting, many content holders would
                  prefer to purchase transport and management services from a
                  network service provider and thus share the infrastructure
                  costs with other content holders.

                  Similarly network service providers in many cases do not
                  specialize in providing content and are unlikely to build
                  and maintain such a resource-intensive system without a
                  certain level of demand from content holders.

                  The use model of a single NSP providing multicasting
                  services to multiple CPs the following general requirements
                  from MACCNT-REQ-draft apply:

                       -Need for user tracking and billing capabilities
                       -Need for QoS control such as resource management and
                  admission control
                       -Need for conditional content access control
                  satisfactory to the requirements of the CP
                       -Methods for sharing information between the NSP and
                  CP to make the above two possible

                  When the NSP and CP are the same single entity the general
                  requirements are as follows.

                       -Need for user tracking and user-billing capabilities
                       -Need for access control and/or content protection at
                  level the entity deems appropriate

                4. Framework and Roles of Entities

4.1 Entities4.1 Framework for multicast
                   AAA

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

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

                  For the sake of simplicity, the above diagram portrays a
                  case where there is a single NSP entity and a single CP
                  entity, but multiple CPs can be connected to the same NSP. a single NSP
                  (e.g. NSP may provide connections to multiple CPs to
                  provide a wide selection of content categories.) It is also
                  possible for the same a single 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 A
                  NSP and CP authenticate and authorize each other when they
                  establish connectivity. Below the general case of multiple
                  NSPs with multiple CPs is explained.  Then, the various
                  combinations of Roles: single and multiple CPs and NSPs are
                  described in relation to the general case.

                4.1.1 Multiple CPs are connected to multiple NSPs

                  The user subscribes to multiple NSPs and multiple CPs in
                  this usage case.  The user (or the user's device) selects a CP and a NSP when the
                  user requests content. The NSP may be automatically
                  selected by a user terminal: e.g. a fixed line NSP for STB by a set
                  top box or a mobile NSP for by a mobile phone.  In some usage
                  cases it is possible that the NSP used by the a certain user terminal
                  will not always be the same.  For example a user may have
                  contracted with different NSPs more than one NSP: one for fixed line or
                  access and another for mobile roaming access.

                  The CP is responsible for Authentication and Authorization
   of users' access to content that may be associated with (or managed by) a
                  specific CP. In this case, when the user selects content,
                  the CP manages. is automatically selected.

                  The CP
   hopes user should send an Access-Request to collect accounting information related to the
   access of their content. The CP may choose to authenticate
   and authorize NSPs which are eligible to provide users
   access to its contents.  When the CP cannot (e.g. error or
   resource issues) or decides selected NSP
                  with enough information not (e.g. policy issues) to
   deliver content, only for authentication by the
                  CP is responsible but also for notifying CP selection and admission control by the
                  NSP.

                  When an NSP receives an Access-Request from a user, the NSP of
                  selects the reason.  It is up to appropriate CP for the NSP how to relay or
   translate received Access-Request
                  and relays the messages to content request. As the user.

   The NSP is responsible
                  for managing its network resources.
   The resources, the NSP may perform
                  admission control. It is also
   responsible for relaying the AAA messages from the CP
   whether the user is eligible to receive content
   (authentication by proxy), and the NSP's relevant AAA
   server control.The NSP will allow access to the network
                  and contents conditional to both the CP AAA server's CP's content
                  authorization result and the NSPs network utilization
   authorization result.  In certain cases availability.
                  That is, the NSP starts multicast flow only when it has
                  both 1) received an ĎĎacceptíí response from the CP and NSP may
   have a contractual relationship in which 2)
                  determined that the NSP is
   authorized network resources (e.g. bandwidth) are
                  sufficient to make the content authorization decision based
   on mutually predetermined criteria: in such cases the NSP-
   AAA may also make the content authorization decision
   without querying serve the CP-AAA. multicast channel. When neither of
                  these conditions are met, the NSP cannot or
   decides does not to start the
                  requested multicast to users, channel. When the NSP may notify the
   users of the reason. It is recommended already knows
                  that the NSP notify
   eligible users of the reason for not multicasting content
   when it is due network resources are insufficient or content unavailability, for
   example.  The there is a
                  network failure, the NSP may choose to not relay the
                  Access-Request to notify ineligible users
   of the reason CP. The NSP is also responsible for any case.

4.2 Multiple User IDs

   Users may hold multiple user IDs: IDs which have been
   separately assigned for each subscription they may have for
   various NSPs and CPs.  The NSPs and CPs control
                  relaying the user
   IDs for their respective domains.  The user IDs are only
   meaningful in Response message from the context of each domain.

   When CP to the user wants to access content,
                  whether the user registers is eligible to receive content (in
                  response to the corresponding Access-Request from the user ID (including
                  to the CP.) In cases that the NSP does not start multicast
                  because of its CP domain
   information) own network issues (e.g. lack of network
                  resources or network failure), the NSP notifies the user
                  with a request reason for content, etc: web
   authentication is one possible method.

   Each rejecting the request.

                  A CP may identify users receives an Access-Request relayed by the user IDs that it has
   issued to them.

   Terminal portability can be realized if the NSP NSP. The CP
                  authenticates a user using a NSP-assigned user ID. A NSP-
   assigned user ID is the NSPís identity and makes an access-line independent unique ID
   assigned authorization
                  decision regarding the NSPís eligibility to provide users which allows user identification from any
                  access point within the network to its contents.  The CP is responsible for
                  Authentication and possibly roaming Authorization of users' access to
   other networks.  This allows
                  content that the user CP manages. The CP hopes to collect
                  accounting information related to access the content
   from various network access points. of their
                  content. The CP responds to the NSP and regarding the relayed
                  Access-Request.  When the CP do cannot (e.g. error or
                  resource issues) or decides not need (e.g. policy issues) to know
                  deliver content, the corresponding user
   id CP is responsible for notifying the same user in
                  NSP of the other provider's domain, and it
   is not necessary that there is a one to one relationship. reason.  It is quite possible for one person up to hold multiple user
   ids the NSP how to relay or
                  translate the reasons for rejection to the same provider.

   The actual mapping rules for NSPs and user.

                4.1.2 Multiple CPs are connected to map a single NSP

                  The user IDs
   with the IDs in other provider domains is subscribes to a matter for single NSP which provides
                  multicasting of channels from multiple CPs in this usage
                  case. In this case the
   providers.  A solution should provide user does not select an API between the
   providers to flexibly support various mapping methods.

4.3 Accounting

   MACCNT-REQ-draft defines requirements for Accounting and
   Billing. These include the requirement for the NSP to log NSP.  The
                  user behavior such as selects a CP when the join action and user requests content. The
                  content may be associated with (or managed by) the leave action,
   as well as specific
                  CP, when the result of user selects content, the access-control decision.
   (MACCNT-REQ-draft, 4.5) MACCNT-REQ-draft also specifies
   that there CP is automatically
                  selected.

                  The user should be a standardized way send an Access-Request to sharing the specific NSP
                  with enough information not only for authentication by the
                  CP the user behavior but also for CP selection and content reception information
   which admission control by the
                  NSP.

                  The role of the NSP is logging.(MACCNT-REQ-draft, 4.5.1)
   Standardization the same as that described in 4.1.1.

                  The role of a CP is the logs or messages to share content
   usage information same as that described in 4.1.1.

                4.1.3 A single CP is important connected to support a single NSP
   sharing accounting information with multiple CPs or NSPs

                   A user subscribes to multiple NSPs but a single CP receiving from multiple NSPs.

   In order to provide the granularity of user-behavior and
   actual content reception information as specified in
   MACCNT-REQ-draft, this
                  usage case.  A user selects the NSP should not manage multicast
   states on a subnet basis, when the user requests
                  content but on a the CP is fixed.  The user basis (see in
   MACCNT-REQ-draft, 4.1 "User identification") because should send an
                  Access-Request to the selected NSP needs to be able to notify with enough information
                  not only for authentication by the CP of a user's start and
   stop times but also for accounting purposes. This means that
                  admission control by the NSP.

                  The role of the NSP
   sends is similar to the CP AAA description in 4.1.1,
                  with the exception that when a NSP receives an indication for Join and Leave on Access-
                  Request from a
   user basis. User-based multicast state management is
   equivalent user, NSP relays it to explicit membership tracking the CP without CP
                  selection.

                  The role of the CP is the same as that described in RFC3376 4.1.1.

                 4.1.4 A single CP is connected to single NSP

                      In this case, a user subscribes to only one NSP and
   per-host tracking one
                  CP. The user does not select NSP and CP in RFC3810.

   This framework specifies this scenario.
                  The user should send an accounting API provided by Access-Request to the NSP and accessed with
                  enough information not only for authentication by the CP to allow
                  but also for sharing user-
   behavior admission control by the NSP.

                      The role for the NSP is the same as 4.1.3
                  The role of the CP is the same as the description in 4.1.1.

                  The NSP and content-reception information between CP could be the same entity. In this case, the
                  roles of the NSP
   AAA and CP AAA. This accounting API should may be configurable
   to allow combined.

                4.2 User ID

                  Users may hold multiple user IDs: IDs which have been
                  separately assigned for each subscription they may have for
                  various NSPs and CPs.  The NSPs and CPs manage the user IDs
                  for their respective domains. A CP to request identifies a user by a
                  user ID assigned by CP itself. A NSP identifies a user by a
                  user ID assigned by NSP itself. The user IDs are only
                  meaningful in the logging information it
   actually requires.  Such an API would allow context of each domain. Users may hold
                  multiple user IDs which have been separately assigned for realtime
   accounting information sharing by
                  each subscription they may have for various NSPs and CPs.

                4.2.1 CP-assigned user ID

                  CPs assign user IDs to their users. The user may have more
                  than one CP-assigned user ID per a specific CP.  A user
                  sends an Access-Request to a NSP, the CP-assigned user ID
                  should be indicated so that the CP can identify the user
                  requesting content access.  A NSP should relay the CP-
                  assigned user ID from the user to the CP. When
   logging information is shared through A NSP should not
                  send a CP-assigned user ID to any CP except the accounting API, one which
                  assigned it and should not relay it all if there is important no
                  appropriate CP that assigned the CP user ID.

                4.2.2 NSP-assigned user ID

                  NSPs assign user IDs to their users. A user may have more
                  than one NSP-assigned user ID per a specific NSP.  A user
                  sends an Access-Request to a NSP, the NSP-assigned user ID
                  may be able indicated in it so that the NSP can identify the
                  user. The NSP should not relay the NSP-assigned user ID to match
                  the CP for security reasons. The NSP may identify the
                  multicast-access user by other methods than the NSP-
                  assigned userID, e.g. by the access port.

                  The actual mapping rules for NSP-assigned user IDs with CP-
                  user assigned IDs in account logs is a matter for the
                  providers and out of the scope of this framework.

                4.3 Accounting

                  There are some specific accounting issues for multicasting.
                  A (S,G) should be recorded as
   described a channel identifier. The
                  last hop devices, such as a IGMP or MLD router and a IGMP
                  or MLD proxy, notify a (S,G) to AAA function in the database operated by NSP.
                  The (S,G) information should be notified to the CP as part
                  of the accounting log.

                  A NSP records accounting start corresponding to only the
                  first Join for a specific user access session. A NSP should
                  not treat a Query-responded Join as described in the database operated by the CP.

   The accounting start.

                  A NSP requires the capability to log both records accounting stop triggered by not only user and host
   information for each join and leave, indicating the
   corresponding multicast source for each action. When either
                  requested Leave but also timeout of a CP source stops sending, multicast state or the
                  re-authentication failure. A NSP stops multicasting,
   in an unsolicited manner, there is may also a need record an
                  accounting stop due to notify
   the AAA servers accordingly about network availability reasons such as
                  failure. The NSP logs the users who are
   impacted by this event. reason for each accounting stop.

                  Also, intermittent logs between the join and leave would
                  allow for finer diagnostics and therefore could serve
                  useful in billing discrepancies, and provide for a better finer
                  estimation of the time span that spent for delivering the content was multicasted in
                  the even event that users disconnect without sending leave
                  messages.

                4.4 Access Control and CP selection by NSP

                  When a NSP receives an access request from a user, it is
   necessary for the NSP to determine
                  determines to which CP the request is to be directed. It is necessary for the  The
                  NSP to ensure
   that it is not spoofed by an inappropriate may select a CP based on CP-assigned userID with CP
                  domain name or user.

4.5 API channel identifier (S,G). The user should
                  include in the request sufficient information for CP
                  selection.

                4.5 Admission Control Information by NSP

                  After authorizing a user request, the NSP may have further
                  conditions for determining its admission control decision.
   MACCNT-REQ-draft defines requirements decision.

                  The NSP needs to know traffic parameters of a multicast
                  channel for admission control. The traffic parameter
                  information may be either indicated by the user or CP
                  within the access request and responses, or otherwise
                  shared between the NSP and CP outside the access-request
                  message mechanism:
                       - A user may declare traffic parameters for each
                  Access-Request.
                       - A CP may notify a mapping between the channel
                  identifier (S,G) and traffic parameters in the Response
                  message when the CP authorizes an access request.
                       - The NSP may maintain a mapping between channel
                  identifier (S,G) and traffic parameters in advance, for
                  example pre-configured by agreement between the CP and NSP
                  on a per channel basis.

                  A NSPs admission control may manage integrated network
                  resources for unicast usage, such as VoIP or unicast
                  streaming, and multicast usage. Alternatively, it may
                  manage network resources separately for unicast and
                  multicast usage. In either case, AAA and admission control
                  framework for providing the
   network capability to conduct admission control based on
   the network bandwidth multicast usage status and bandwidth management
   policy. (MACCNT-REQ-draft, 4.2.2, 4.2.3 & 4.9) is independent of unicast
                  admission control.

                  Such QoS measurement and policy mechanisms themselves
                  depend on NSP policies and are out of the scope of this
                  memo. However the NSP's AAA Server should be
   provided with an Admission control API that allows for
   interfacing so that additional conditions can be added to
   the admission control decision.

                4.6 Access Control and Distinguishing of Users by CP

                  The user ID and authentication information are forwarded
                  transparently by the NSP so that the CP can distinguish the
                  user, as well as authenticate and authorize the request.

                4.7 Caching of AAA results

   An proxy in NSP should be able to cache

                  A NSP may act as AAA results proxy of a CP based upon an agreement
                  between the NSP and a the CP.  The AAA cache proxy would store
                  information about permissions of a specific user to receive
                  multicast data from specified channel(s) up to specified
                  expiration date(s) and time(s).
                  If such caching proxying is implemented, a method must exist for the
   CP to communicate this permission information to the NSP.
   The NSP refers to the AAA cache may receive
                  authorization conditions from a CP in advance and if the cache indicates
   that
                  statically hold them, or a CP may send them dynamically in
                  the Response message.  The user has permission to receive
                  multicast data from
   a specific channel at that time, the time. The NSP may forward starts the
   data
                  multicasting without querying the CP.

   It should be possible for a

                  The CP to may send unsolicited requests to the NSP to refresh
                  or change the permissions for a user for specific
                  channel(s).

                  When a user is receiving multicast content and the
                  permission is about to expire, the NSP may send a
                  notification to the user client that his session is about
                  to expire, and that he will need to re-connect. The reauthenticate. In such
                  a case, the user will have to reestablish a connection. send the Access-Request.  In
                  the case that the user still has permission to the content,
                  they should be able to continue to receive the content
                  without interruption.
                  When re-authentication fails, the NSP should stop the
                  multicast channel and record accounting stop.

                  5. Network Connection Model and Functional Components

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

               5.1 Basic Connection Model

                  In the simple case represented in Figure 1 the NSP is the
                  sole entity providing network resources including network
                  access to the User.  First a user that requests content
                  sends an Access request to an NSP which then forwards it on
                  to the appropriate CP for Authentication and Authorization
                  purposes. The CP responds with either "success" or
                  "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.

               5.2 Constituent Logical Functional Components of the fully
               enabled AAA Framework

   MACCNT-REQ-draft defined requirements

                  Requirements for "well managed" "fully AAA and QoS enabled" IP
                  multicasting which networks were defined in MACCNT-REQ-draft. To
                  allow for levels of enablement, this memo calls defines two
                  models within the framework: "AAA enabled"
   multicasting. multicasting and
                  "Fully enabled AAA" multicasting in this memo which means "AAA enabled"
                  with added QoS admission control functions.

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

                  AAA enabled framework (basic model)
                           +-------------------------------+
                           | user                          |
                           |+- - - - - - - - - - - - - - -+|
                           || CPE                         ||
                           ||                             ||
                           |+- - - - - | - - - - - - - - -+|
                           +-----------|-------------------+
                                       |
                                -------|------ IFa
                                       |
                           +-----------|-------------------+
                           | NSP       |                   |
                           |+- - - - - |- -_+              |
                           ||TS        |    |              |
                           |    +------|-+                 |
                              ||   | AN     |  |              |
                           |    |        |                 |
                           ||   +------|-+  |              |
                           |           |     IFb           |
                           ||   +------|-+  | | +---------+|
                           |    |        |----|-|mAAA     ||
                           ||   | NAS    |  | | | (CAPCF*)|| |(MACF *) || * optional
                           |    +--------+      +---------+|
                           ||+- - - - - - - +      |       |
                           +-----------------------|--------+
                                                   |
                                            -------|------ IFc
                                                   |
                           +-----------------------|-------+
                           | CP               +---------+  |
                           |                  |  CP-AAA |  |
                           |                  +---------+  |
                           +-------------------------------+
                                   Figure 2

                  The user entity includes the CPE (Customer Premise
                  Equipment) which includes the user host(s) and optionally a
                  multicast proxy (not shown in the Figure 2.)

                  The NSP (Network Service Provider) in the basic model
                  includes the transport system and a logical element for
                  multicast AAA functionality.  The transport system is
                  comprised of the access node and NAS (network access
   server.)
                  server) An AN may be connected directly to mAAA or a NAS
                  relays AAA information between an AN and a mAAA
                  Descriptions of AN and its interfaces are out of scope for
                  this memo.  The multicast AAA function may be provided by a
                  multicast AAA server (mAAA) which may include
   a the function
                  by which the access policy is downloaded to the NAS (conditional
                  (Multicast access policy control function.) The interface between
                  mAAA and the NAS is labeled IFb in Figure 2. Over IFb the
                  NAS makes an access request to the NSP-mAAA and the mAAA
                  replies. The mAAA may push conditional access policy to the
                  NAS.

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

                  The interface between the user and the NSP is labeled IFa
                  in Figure 2.  Over IFa the user makes a multicasting
                  request to the NSP.  The NSP may in reply send multicast
                  traffic depending on the NSP and CP's CPís policy decisions.

                  The interface between the NSP and CP is labeled IFc. Over
                  IFc the NSP requests to the CP-AAA for access to contents
                  and the CP replies.  CP may also send conditional access
                  policy over this interface for AAA-caching. within the context of proxying
                  multicast AAA messagescaching.

                       Fully enabled framework (c)
                           +-------------------------------+
                           | user                          |
                           |+- - - - - - - - - - - - - - -+|
                           || CPE                         ||
                           ||                             ||
                           |+- - - - - | - - - - - - - - -+|
                           +-----------|-------------------+
                                       |
                                -------|------ IFa
                                       |
                           +-----------|-----------------------+
                           |+- - - - - |- - _+   + - - - - - + |
                           ||TS        |   | |   |           | |
                           |    +------|-+ |       +--------+  |
                           ||   | AN     | | |   | | mRACF MACF  || |
                           |    |        | |       |        |  |
                           ||   +------|-+ | |   | +---|----+| |
                           |           |   |           |    |  |
                           |           |   | |     IFd----- |  |
                           |           |   |  IFb      |    |  |
                           ||   +------|---+ | | | +---|----+| |
                           |    |          |---|---| mAAA   |  |
                           ||   | NAS      | | | | |(CAPCF*)|| |(MACF *)|| | * optional
                           |    +----------+ |     +--------+  |
                           ||+- - - - - - - -+ - - |- - - - -+ |
                           +-----------------------|-----------+
                                                   |
                                            -------|------ IFc
                                                   |
                           +-----------------------|-------+
                           | CP               +---------+  |
                           |                  |  CP-AAA |  |
                           |                  +---------+  |
                            +-------------------------------+
                                          Figure 3

                  In the fully enabled model the NSP also includes a
                  component that provides network resource management (e.g.
                  QoS management), as described in section 3.4, "Network
                  Resource Management by NSP".  In the fully enabled model
                  (Figure 3) resource management and admission control is
                  provided by mRACF MACF (multicast resource and admission control
   function.)  This means that mRACF and Authorization portion
   of mAAA comprise RACS. function).
                  Before replying to the user's multicast request the mAAA
                  queries the mRACF MACF for a network resource access decision
                  over the interface IFd.   The mRACF MACF is responsible for
                  allocating network resources for multicast traffic.  So that mRACF has  To
                  provide MACF with the necessary relevant network resource
                  availability information, NAS notifies mRACF MACF via mAAA of the
   stopping of that
                  sending multicast traffic. traffic has ceased.

                5.3 Modularity of the framework

                  In the interest of flexibility, this framework is modular
                  so that it is possible that partially enabled versions of
                  the models are supported.  A An AAA-enabled version provides
                  AAA functionality without Network Resource management.  A
                  Network-Resource-Management-enabled (QoS-enabled) version
                  provides Network Resource management without AAA
                  functionality.  Similarly, the possibility of one or more
                  layers of transit provision between an NSP and CP is in the
                  interest of modularity and extendibility.

                6. IANA considerations

                  This memo does not raise any IANA consideration issues.

                7. Security considerations

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

                8. Conclusion

                  This memo provides a generalized framework for solution
                  standards to meet the requirements presented in MACCNT-REQ-
   draft. requirements.  Further work should be
                  done to specify the interfaces between the user and NSP,
                  NAS and mAAA, mAAA and
   mRACF MACF and NSP-mAAA and CP-AAA
                  (presented in 5.2.)

                Normative References

                  [1] Hayashi, et. al., "Accounting, Authentication Requirements for Multicast AAA
                       coordinated between Content Provider(s) and
       Authorization Issues in Well Managed IP Multicasting
       Services", draft-ietf-mboned-maccnt-req-04.txt,
       February 2006, Network
                       Service Provider(s)", draft-ietf-mboned-maccnt-req-
                       05.txt, September 2007, Work in Progress.

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

                  [3] RFC-3376, Cain B., et.al., "Internet Group Management
                       Protocol, Version 3", October 2002.

               Authors' Addresses

                          Hiroaki Satou
                          NTT Network Service Systems Laboratories
                          3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585
                  Japan
                          Phone : +81 422 59 4683
                          Email : satou.hiroaki@lab.ntt.co.jp

                          Hiroshi Ohta
                          NTT Network Service Systems Laboratories
                          3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585
                  Japan
                                  Phone : +81 422 59 3617
                          Email: ohta.hiroshi@lab.ntt.co.jp

                          Christian Jacquenet
                          France Telecom
           3, avenue Francois Chateau
           CS 36901, 35069 Rennes Cedex, R&D
                          4, rue du Clos Courtel -
                                                 - BP 91226
                          35512 Cesson-SťvignĀECedex, France
                          Phone: +33 2 99 87 63 31 12 49 40
                          Email: christian.jacquenet@francetelecom.com christian.jacquenet@orange-ftgroup.com

                          Tsunemasa Hayashi
                          NTT Network Innovation Laboratories
                          1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847
                  Japan
                          Phone: +81 46 859 8790
                          Email: tsunemasa@gmail.com

                          Haixiang He
                          Nortel
                          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.

                Full Copyright Statement

                  Copyright (C) The IETF Trust (2007).

                  This document is subject to the rights, licenses and
                  restrictions contained in BCP 78, and except as set forth
                  therein, the authors retain all their rights.

                  "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, THE IETF TRUST 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 January 10, May 17, 2008.

                Acknowledgement

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