draft-ietf-mboned-multiaaa-framework-08.txt   draft-ietf-mboned-multiaaa-framework-09.txt 
Internet Draft Hiroaki Satou, NTT mboned T. Hayashi
Intended Status: Informational Hiroshi Ohta, NTT Internet-Draft NTT Network Innovation
Expires: August 1, 2009 Christian Jacquenet, France Telecom Intended status: Informational Laboratories
Tsunemasa Hayashi, NTT Expires: February 4, 2010 H. He
Haixiang He, Nortel Networks Nortel
H. Satou
January 28, 2009 H. Ohta
NTT Network Service Systems
Laboratories
C. Jacquenet
France Telecom
August 3, 2009
AAA and Admission Control Framework for Multicasting Requirements for Multicast AAA coordinated between Content Provider(s)
<draft-ietf-mboned-multiaaa-framework-08.txt> and Network Service Provider(s)
draft-ietf-mboned-multiaaa-framework-09
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance
with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet This Internet-Draft is submitted to IETF in full conformance with the
Engineering Task Force (IETF), its areas, and its working provisions of BCP 78 and BCP 79. This document may contain material
groups. Note that other groups may also distribute working from IETF Documents or IETF Contributions published or made publicly
documents as Internet-Drafts. 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 draft documents valid for a maximum of Internet-Drafts are working documents of the Internet Engineering
six months and may be updated, replaced, or obsoleted by Task Force (IETF), its areas, and its working groups. Note that
other documents at any time. It is inappropriate to use other groups may also distribute working documents as Internet-
Internet-Drafts as reference material or to cite them other Drafts.
than as "work in progress."
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be The list of Internet-Draft Shadow Directories can be accessed at
accessed at http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 1, 2009. This Internet-Draft will expire on February 4, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
Internet Draft AAA and Admission Control Framework for
Multicasting January, 2009
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with and restrictions with respect to this document.
respect to this document.
Abstract Abstract
IP multicast-based services, such as TV broadcasting or IP multicast-based services, such as TV broadcasting or
videoconferencing raise the issue of making sure that videoconferencing raise the issue of making sure that potential
potential customers are fully entitled to access the customers are fully entitled to access the corresponding contents.
corresponding contents. There is indeed a need for service There is indeed a need for service and content providers to identify
and content providers to identify users (if not users (if not authenticate, especially within the context of
authenticate, especially within the context of enforcing enforcing electronic payment schemes) and to retrieve statistical
electronic payment schemes) and to retrieve statistical information for accounting purposes, as far as content and network
information for accounting purposes, as far as content and usage are concerned. This memo describes the framework for
network usage are concerned. This memo describes the specifying the Authorization, Authentication and Accounting (AAA)
framework for specifying the Authorization, Authentication capabilities that could be activated within the context of the
and Accounting (AAA) capabilities that could be activated deployment and the operation of IP multicast-based services. This
within the context of the deployment and the operation of framework addresses the requirements presented in "Requirements for
IP multicast-based services. This framework addresses the Accounting, Authentication and Authorization in Well Managed IP
requirements presented in "Requirements for Accounting, Multicasting Services" [I-D.ietf-mboned-maccnt-req]. The memo
Authentication and Authorization in Well Managed IP provides a basic AAA enabled model as well as an extended fully
Multicasting Services" [I-D.mboned-maccnt-req]. The memo enabled model with resource and admission control coordination.
provides a basic AAA enabled model as well as an extended
fully enabled model with resource and admission control
coordination.
Multicasting January, 2009
Table of Contents Table of Contents
1. INTRODUCTION..................................................4
1.1 PURPOSE AND BACKGROUND.......................................4
2. DEFINITIONS AND ABBREVIATIONS.................................5
2.1 DEFINITIONS..................................................5
2.2 ABBREVIATIONS................................................6
3. COMMON USE MODELS AND NETWORK ARCHITECTURE IMPLICATIONS.......7
4. FRAMEWORK AND ROLES OF ENTITIES...............................9
4.1 "AAA FRAMEWORK IN MULTICAST-ENABLED ENVIRONMENTS.............9
4.1.1 MULTIPLE CPS ARE CONNECTED TO MULTIPLE NSPS................9
4.1.2 MULTIPLE CPS ARE CONNECTED TO A SINGLE NSP................11
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.....................................................12
4.2.1 CP-ASSIGNED USER ID.......................................12
4.2.2 NSP-ASSIGNED USER ID......................................12
4.3 ACCOUNTING..................................................13
4.4 ACCESS CONTROL AND CP SELECTION BY NSP......................14
4.5 ADMISSION CONTROL INFORMATION BY NSP........................14
4.6 ACCESS CONTROL AND DISTINGUISHING OF USERS BY CP............15
4.7 AAA PROXY IN NSP............................................15
5.1 BASIC CONNECTION MODEL......................................16
5.2 CONSTITUENT LOGICAL FUNCTIONAL COMPONENTS OF THE FULLY
ENABLED AAA FRAMEWORK...........................................17
5.3 MODULARITY OF THE FRAMEWORK.................................21
6. IANA CONSIDERATIONS..........................................21
7. SECURITY CONSIDERATIONS......................................21
8. CONCLUSION...................................................21
Internet Draft AAA and Admission Control Framework for 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
Multicasting January, 2009 1.1. Purpose and Background . . . . . . . . . . . . . . . . . . 4
2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 5
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6
3. Common use models and network architecture implications . . . 7
4. Framework and Roles of Entities . . . . . . . . . . . . . . . 8
4.1. AAA Framework in Multicast-Enabled Environments . . . . . 8
4.2. User ID . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 11
4.4. Access Control and CP selection by NSP . . . . . . . . . . 12
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. Network Connection Model and Functional Components . . . . . . 14
5.1. Basic Connection Model . . . . . . . . . . . . . . . . . . 15
5.2. Constituent Logical Functional Components of the fully
enabled AAA Framework . . . . . . . . . . . . . . . . . . 16
5.3. Modularity of the framework . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Normative References . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
1.1 Purpose and Background 1.1. Purpose and Background
IP multicasting is designed to serve cases of group IP multicasting is designed to serve cases of group communication
communication schemes of any kind, such as one-to-many schemes of any kind, such as one-to-many (case of TV broadcasting
(case of TV broadcasting services for example) or many-to- services for example) or many-to- many (case of videoconferencing
many (case of videoconferencing services, for example). services, for example).
In these environments, IP multicast provides a better In these environments, IP multicast provides a better resource
resource optimization than using a unicast transmission optimization than using a unicast transmission scheme, where data
scheme, where data need to be replicated as many times as need to be replicated as many times as there are receivers.
there are receivers. Activation of IP multicast Activation of IP multicast capabilities in networks yields the
capabilities in networks yields the establishment and the establishment and the maintenance of multicast distribution trees
maintenance of multicast distribution trees that are that are receiver-initiated by nature: multicast-formatted data are
receiver-initiated by nature: multicast-formatted data are forwarded to receivers who explicitly request them. IP multicast-
forwarded to receivers who explicitly request them. based services, such as TV broadcasting or videoconferencing raise
IP multicast-based services, such as TV broadcasting or the issue of making sure that potential customers are fully entitled
videoconferencing raise the issue of making sure that to access the corresponding contents. There is indeed a need for
potential customers are fully entitled to access the service and content providers to identify (if not authenticate,
corresponding contents. There is indeed a need for service especially within the context of enforcing electronic payment
and content providers to identify (if not authenticate, schemes) and to invoice such customers in a reliable and efficient
especially within the context of enforcing electronic manner. Solutions should consider a wide range of possible content
payment schemes) and to invoice such customers in a delivery applications: content delivered over the multicast network
reliable and efficient manner. Solutions should consider a may include video, audio, images, games, software and information
wide range of possible content delivery applications: such as financial data, etc.
content delivered over the multicast network may include
video, audio, images, games, software and information such
as financial data, etc.
Internet Draft AAA and Admission Control Framework for This memo describes a framework for specifying the Authorization,
Multicasting January, 2009 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 Multicast Admission
Control Function (MACF) with multicast Authorization.
This memo describes a framework for specifying the Specifically, this framework addresses the requirements presented in
Authorization, Authentication and Accounting (AAA) "Requirements for Multicast AAA coordinated between Content
capabilities that could be activated within the context of Provider(s) and Network Service Provider(s)" which describes the
the deployment and the operation of IP multicast-based requirements in CDN services using IP multicast. The requirements
services. This memo also describes a framework to realize are derived from:
high-quality multicast transport using a Multicast
Admission Control Function (MACF) with multicast
Authorization.
Specifically, this framework addresses the requirements need for user tracking and billing capabilities
presented in "Requirements for Multicast AAA coordinated
between Content Provider(s) and Network Service
Provider(s)" which describes the requirements in CDN
services using IP multicast. 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. [I-D.mboned-maccnt-
req]
Detailed requirements are presented in "Requirements for need for network access control to satisfy the requirements of the
Accounting, Authentication and Authorization in Well Network Service Provider (NSP) and/or content access control to
Managed IP Multicasting Services" [I-D.mboned-maccnt-req]. satisfy the requirements of the Content Provider (CP)
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 methods for sharing information between the network service
framework for specifying multicast-inferred AAA provider and content provider to make it possible to fulfill the
capabilities that can meet these requirements. This above two requirements. [I-D.mboned-maccnt- req]
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 Detailed requirements are presented in "Requirements for Accounting,
Authentication and Authorization in Well Managed IP Multicasting
Services" [I-D.ietf-mboned-maccnt-req]. 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.
2.1 Definitions 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.
Internet Draft AAA and Admission Control Framework for 2. Definitions and Abbreviations
Multicasting January, 2009
For the purpose of this memo the following definitions 2.1. Definitions
apply:
Accounting: The set of capabilities that allow the For the purpose of this memo the following definitions apply:
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 Accounting: The set of capabilities that allow the retrieval of a
one. 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.
Authorization: The set of capabilities that need to be Authentication: action for identifying a user as a genuine one.
activated to make sure an authenticated user is fully
entitled to access a set of services.
Join: Signaling mechanism used by receivers to indicate Authorization: The set of capabilities that need to be activated
they want to access a multicast group and receive the to make sure an authenticated user is fully entitled to access a
corresponding traffic. set of services.
Leave: Signaling mechanism used by receivers to indicate Join: Signaling mechanism used by receivers to indicate they want
they want to leave a multicast group and not receive the to access a multicast group and receive the corresponding traffic.
corresponding traffic anymore.
Receiver: an end-host or end-client which receives content. Leave: Signaling mechanism used by receivers to indicate they want
A receiver may be identified by a network ID such as MAC to leave a multicast group and not receive the corresponding
address or IP address. traffic anymore.
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 User: a human with a user account. A user may possibly use
multiple reception devices. Multiple users may use the multiple reception devices. Multiple users may use the same
same reception device. (Note: The definition of a receiver reception device. (Note: The definition of a receiver (device)
(device) and a user (human) should not be confused.) and a user (human) should not be confused.)
2.2 Abbreviations 2.2. Abbreviations
For the purpose of this draft the following abbreviations For the purpose of this draft the following abbreviations apply:
apply:
AAA: Authentication.Authorization.and Accounting AAA: Authentication.Authorization.and Accounting
ACL: Access Control List ACL: Access Control List
Internet Draft AAA and Admission Control Framework for
Multicasting January, 2009
AN: Access Node AN: Access Node
CDN: Content Delivery Network CDN: Content Delivery Network
CDS: Content Delivery Services CDS: Content Delivery Services
CP: Content Provider CP: Content Provider
CP-AAA: Authentication, Authorization, and Accounting CP-AAA: Authentication, Authorization, and Accounting functions
functions used by a Content Provider used by a Content Provider
CPE: Customer Premise Equipment CPE: Customer Premise Equipment
ID: Identifier ID: Identifier
IF: network interface IF: network interface
mAAA: Authentication, Authorization, and Accounting mAAA: Authentication, Authorization, and Accounting functions
functions activated in multicast-enabled environments activated in multicast-enabled environments
MACF: Multicast Admission Control Function MACF: Multicast Admission Control Function
NAS: Network Access Server (RFC2881) NAS: Network Access Server (RFC2881)
NSP: Network Service Provider NSP: Network Service Provider
NSP-mAAA: Authentication, Authorization, and Accounting functions
NSP-mAAA: Authentication, Authorization, and Accounting used by a Network Service provider
functions used by a Network Service provider
QoS: Quality of Service QoS: Quality of Service
3. Common use models and network architecture implications 3. Common use models and network architecture implications
In some cases a single entity may design and be responsible In some cases a single entity may design and be responsible for a
for a system that covers the various common high-level system that covers the various common high-level requirements of a
requirements of a multicasting system such as 1) content multicasting system such as 1) content serving, 2) the infrastructure
serving, 2) the infrastructure to multicast it, 3) network to multicast it, 3) network and content access control mechanisms.
and content access control mechanisms.
In many cases however the content provision and network In many cases however the content provision and network provision
provision roles are divided between separate entities. roles are divided between separate entities. Commonly, Content
Commonly, Content Providers (CP) do not build and maintain Providers (CP) do not build and maintain their own multicast network
their own multicast network infrastructure as this is not infrastructure as this is not their primary business area. CP often
their primary business area. CP often purchase transport purchase transport and management services from network service
and management services from network service providers providers instead. Similarly Network Service Providers (NSP) may not
instead. Similarly Network Service Providers (NSP) may not make their business in providing content. [I-D.mboned- maccnt-req]
make their business in providing content. [I-D.mboned- provides more detail of the multiple versus single-entity Content
maccnt-req] provides more detail of the multiple versus Delivery Service (CDS) network models.
Internet Draft AAA and Admission Control Framework for In the usage model where a single NSP provides multicast services to
Multicasting January, 2009 multiple CPs, the following general requirements from [I-D.ietf-
mboned-maccnt-req] apply:
single-entity Content Delivery Service (CDS) network Need for user tracking and billing capabilities
models.
In the usage model where a single NSP provides multicast Need for QoS control such as resource management and admission
services to multiple CPs, the following general control
requirements from [I-D.mboned-maccnt-req] apply:
-Need for user tracking and billing capabilities Need for conditional multicast access control satisfactory to the
-Need for QoS control such as resource management and requirements of the CP
admission control
-Need for conditional multicast 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 then the Methods for sharing information between the NSP and CP to make the
general requirements are as follows. above two possible
-Need for user tracking and user-billing capabilities When the NSP and CP are the same single entity then the general
-Need for access control and/or content protection at requirements are as follows.
level the entity deems appropriate
Internet Draft AAA and Admission Control Framework for Need for user tracking and user-billing capabilities
Multicasting January, 2009
Need for access control and/or content protection at level the
entity deems appropriate
4. Framework and Roles of Entities 4. Framework and Roles of Entities
4.1 AAA Framework in Multicast-Enabled Environments 4.1. AAA Framework in Multicast-Enabled Environments
A general high-level framework is depicted in Figure 1. A general high-level framework is depicted in Figure 1.
+------------------------------+ +------------------------------+
| user | | user |
| | | |
+------------------------------+ +------------------------------+
| |
| |
| |
skipping to change at page 9, line 33 skipping to change at page 8, line 30
| | | |
+------------------------------+ +------------------------------+
| |
| |
| |
+------------------------------+ +------------------------------+
| CP | | CP |
| | | |
+------------------------------+ +------------------------------+
Figure 1: High-level AAA framework in Multicast-Enabled Figure 1: High-level AAA framework in Multicast-Enabled Environments
Environments
For the sake of simplicity, the above diagram portrays a
case where there is a single NSP entity and a single CP
entity (one-to-one model), but multiple CPs can be
connected to a single NSP (e.g. NSP may provide connections
to multiple CPs to provide a wide selection of content
categories: one-to-many model) It is also possible for a
single CP to be connected to multiple NSP networks (e.g.
network selection). Furthermore it is possible that the NSP
and CP could be the same entity. 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 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 Figure 1
this usage case. The user selects a CP and a NSP when the
user requests content. The NSP may be automatically
selected by a user terminal: e.g. a fixed line NSP by a set
top box or a mobile NSP by a mobile phone. In some usage
Internet Draft AAA and Admission Control Framework for For the sake of simplicity, the above diagram portrays a case where
Multicasting January, 2009 there is a single NSP entity and a single CP entity (one-to-one
model), but multiple CPs can be connected to a single NSP (e.g. NSP
may provide connections to multiple CPs to provide a wide selection
of content categories: one-to-many model) It is also possible for a
single CP to be connected to multiple NSP networks (e.g. network
selection). Furthermore it is possible that the NSP and CP could be
the same entity. 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 single and multiple CPs and NSPs are described in relation to the
general case.
cases it is possible that the NSP used by a certain user 4.1.1. Multiple CPs are connected to multiple NSPs
will not always be the same. For example a user may have
contracted with more than one NSP: one for fixed line
access and another for mobile roaming access.
The content may be associated with (or managed by) a The user subscribes to multiple NSPs and multiple CPs in this usage
specific CP. In this case, when the user selects content, case. The user selects a CP and a NSP when the user requests
the CP is automatically selected. content. The NSP may be automatically selected by a user terminal:
Requests for multicast sent by the user to a selected NSP e.g. a fixed line NSP by a set top box or a mobile NSP by a mobile
should include enough information not only for phone. In some usage cases it is possible that the NSP used by a
authentication by the CP but also for CP selection and certain user will not always be the same. For example a user may
admission control by the NSP. have contracted with more than one NSP: one for fixed line access and
another for mobile roaming access.
When an NSP receives a request for multicast from a user, The content may be associated with (or managed by) a specific CP. In
the NSP requests the appropriate CP to make sure that the this case, when the user selects content, the CP is automatically
user is entitled to access the corresponding content As selected.
the NSP is responsible for managing its network resources,
the NSP may perform admission control.The NSP will allow
access to the multicast service, depending on both the
response sent by the CP and the availability of resources
operated by the NSP. That is, the NSP will forward
multicast traffic towards the user only when the NSP has 1)
made sure the user is entitled to access the network
resources operated by the NSP, 2) received a confirmation
from the CP that the user is entitled to access the content
and (possibly) 3) determined that the network resources
(e.g. bandwidth) are sufficient to deliver the multicast
traffic to the user with the relevant level of quality.
When neither of the first two conditions are met, the NSP
will not forward multicast traffic to the user. Condition
#3 may also be a showstopper. When the NSP already knows
that network resources are insufficient or there is a
network failure, the NSP may choose to not request the CP
about the user's ability to retrieve content. The NSP is
also responsible for notifiying the user whether he/she is
eligible to receive content depending on the response sent
by the CP. In cases where the NSP does not start
multicasting because of its own network issues (e.g. lack
of network resources or network failure), the NSP notifies
the user with a reason for rejecting the request.
A CP receives an inquiry from the NSP. The CP authenticates Requests for multicast sent by the user to a selected NSP should
the NSP's identity and makes an authorization decision include enough information not only for authentication by the CP but
regarding the user's eligibility to access the requested also for CP selection and admission control by the NSP.
contents. The CP is responsible for the authentication
and authorization of users so that they can access the
content managed by the CP. The CP notifies the NSP
accordingly. When the CP cannot (e.g. error or resource
issues) or decides not (e.g. policy issues) to deliver
Internet Draft AAA and Admission Control Framework for When an NSP receives a request for multicast from a user, the NSP
Multicasting January, 2009 requests the appropriate CP to make sure that the user is entitled to
access the corresponding content As the NSP is responsible for
managing its network resources, the NSP may perform admission
control.The NSP will allow access to the multicast service, depending
on both the response sent by the CP and the availability of resources
operated by the NSP. That is, the NSP will forward multicast traffic
towards the user only when the NSP has 1) made sure the user is
entitled to access the network resources operated by the NSP, 2)
received a confirmation from the CP that the user is entitled to
access the content and (possibly) 3) determined that the network
resources (e.g. bandwidth) are sufficient to deliver the multicast
traffic to the user with the relevant level of quality. When neither
of the first two conditions are met, the NSP will not forward
multicast traffic to the user. Condition #3 may also be a
showstopper. When the NSP already knows that network resources are
insufficient or there is a network failure, the NSP may choose to not
request the CP about the user's ability to retrieve content. The NSP
is also responsible for notifiying the user whether he/she is
eligible to receive content depending on the response sent by the CP.
In cases where the NSP does not start multicasting because of its own
network issues (e.g. lack of network resources or network failure),
the NSP notifies the user with a reason for rejecting the request.
content, the CP is responsible for notifying the NSP about A CP receives an inquiry from the NSP. The CP authenticates the
the reason. It is up to the NSP to relay or translate the NSP's identity and makes an authorization decision regarding the
reasons for rejection to the user. user's eligibility to access the requested contents. The CP is
responsible for the authentication and authorization of users so that
they can access the content managed by the CP. The CP notifies the
NSP accordingly. When the CP cannot (e.g. error or resource issues)
or decides not (e.g. policy issues) to deliver content, the CP is
responsible for notifying the NSP about the reason. It is up to the
NSP to relay or translate the reasons for rejection to the user.
A CP may delegate AAA responsibility to a NSP. 'AAA proxy A CP may delegate AAA responsibility to a NSP. 'AAA proxy in NSP' is
in NSP' is described in 4.7 for this case. described in 4.7 for this case.
As defined in [I-D.mboned-maccnt-req], the CP may require As defined in [I-D.ietf-mboned-maccnt-req], the CP may require the
the retrieval of accounting information related to the retrieval of accounting information related to the access of its
access of its content. content.
4.1.2 Multiple CPs are connected to a single NSP 4.1.2. Multiple CPs are connected to a single NSP
The user subscribes to a single NSP which provides The user subscribes to a single NSP which provides multicasting from
multicasting from multiple CPs in this usage case. In this multiple CPs in this usage case. In this case the user does not
case the user does not select an NSP. The user selects a select an NSP. The user selects a CP when the user requests content.
CP when the user requests content. The content may be The content may be associated with (or managed by) the specific CP,
associated with (or managed by) the specific CP, so that so that when the user selects content, the CP is automatically
when the user selects content, the CP is automatically
selected. selected.
The user should send a request for multicast to the The user should send a request for multicast to the specific NSP with
specific NSP with enough information not only for enough information not only for authentication by the CP but also for
authentication by the CP but also for CP selection and CP selection and admission control by the NSP.
admission control by the NSP.
The role of the NSP is the same as that described in 4.1.1. The role of the NSP is the same as that described in 4.1.1.
The role of a CP is the same as that described in 4.1.1. The role of a CP is the same as that described in 4.1.1.
4.1.3 A single CP is connected to multiple NSPs 4.1.3. Multiple CPs are connected to a single NSP
In this usage case, a user subscribes to multiple NSPs but In this usage case, a user subscribes to multiple NSPs but only a
only a single CP. A user selects the NSP when the user single CP. A user selects the NSP when the user requests multicast
requests multicast but the CP is fixed. The user should but the CP is fixed. The user should send a request for multicast to
send a request for multicast to the selected NSP with the selected NSP with enough information not only for authentication
enough information not only for authentication by the CP by the CP but also for admission control by the NSP.
but also for admission control by the NSP.
The role of the NSP is similar to the description in 4.1.1, The role of the NSP is similar to the description in 4.1.1, with the
with the exception that when a NSP receives a request from exception that when a NSP receives a request from a user, NSP makes
a user, NSP makes an inquiry to the CP without CP selection. an inquiry to the CP without CP selection.
The role of the CP is the same as that described in 4.1.1. The role of the CP is the same as that described in 4.1.1.
4.1.4 A single CP is connected to single NSP 4.1.4. A single CP is connected to single NSP
In this case, a user subscribes to only one NSP and one CP.
The user does not select a NSP and CP in this scenario.
Requests for multicast sent by the user to a selected NSP
Internet Draft AAA and Admission Control Framework for
Multicasting January, 2009
should include enough information not only for
authentication by the CP but also for admission control by
the NSP.
The role for the NSP is the same as 4.1.3 In this case, a user subscribes to only one NSP and one CP. The user
The role of the CP is the same as the description in 4.1.1. does not select a NSP and CP in this scenario. Requests for
multicast sent by the user to a selected NSP should include enough
information not only for authentication by the CP but also for
admission control by the NSP.
The NSP and CP could be the same entity. In this case, the The role for the NSP is the same as 4.1.3 The role of the CP is the
roles of the NSP and CP may be combined. same as the description in 4.1.1.
4.2 User ID The NSP and CP could be the same entity. In this case, the roles of
the NSP and CP may be combined.
Users may hold multiple user IDs: IDs which have been 4.2. User ID
separately assigned for each subscription to various NSPs
and CPs. The NSPs and CPs manage the user IDs for their
respective domains. A CP identifies a user by a user ID
assigned by the CP itself. A NSP identifies a user by a
user ID assigned by the NSP itself. The user IDs are only
meaningful within the context of each domain. Users may
hold multiple user IDs which have been separately assigned
for each subscription they may have for various NSPs and
CPs.
4.2.1 CP-assigned user ID Users may hold multiple user IDs: IDs which have been separately
assigned for each subscription to various NSPs and CPs. The NSPs and
CPs manage the user IDs for their respective domains. A CP
identifies a user by a user ID assigned by the CP itself. A NSP
identifies a user by a user ID assigned by the NSP itself. The user
IDs are only meaningful within the context of each domain. Users may
hold multiple user IDs which have been separately assigned for each
subscription they may have for various NSPs and CPs.
CPs assign user IDs to their users. The user may have more 4.2.1. CP-assigned user ID
than one CP-assigned user ID per specific CP. A user
requests multicast 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 notify the CP-
assigned user ID to the CP. A NSP should not share a CP-
assigned user ID with any CP except the one which assigned
it and should not relay it at all if there is no
appropriate CP that assigned the user ID.
4.2.2 NSP-assigned user ID CPs assign user IDs to their users. The user may have more than one
CP-assigned user ID per specific CP. A user requests multicast 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 notify the
CP- assigned user ID to the CP. A NSP should not share a CP-
assigned user ID with any CP except the one which assigned it and
should not relay it at all if there is no appropriate CP that
assigned the user ID.
NSPs assign user IDs to their users. A user may have more 4.2.2. NSP-assigned user ID
than one NSP-assigned user ID per a specific NSP. A user
requests for multicast to a NSP, the NSP-assigned user ID
may be indicated in the request so that the NSP can
identify the user. The NSP should not inform the NSP-
assigned user ID to 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.
Internet Draft AAA and Admission Control Framework for NSPs assign user IDs to their users. A user may have more than one
Multicasting January, 2009 NSP-assigned user ID per a specific NSP. A user requests for
multicast to a NSP, the NSP-assigned user ID may be indicated in the
request so that the NSP can identify the user. The NSP should not
inform the NSP- assigned user ID to 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- The actual mapping rules for NSP-assigned user IDs with CP- user
user assigned IDs in account logs is a matter for the assigned IDs in account logs is a matter for the providers and out of
providers and out of the scope of this framework. the scope of this framework.
4.3 Accounting 4.3. Accounting
There are some accounting issues specific to multicasting. There are some accounting issues specific to multicasting. An (S,G)
An (S,G) should be recorded as a channel identifier. The should be recorded as a channel identifier. The last hop device,
last hop device, such as an IGMP or MLD router or an IGMP such as an IGMP or MLD router or an IGMP or MLD proxy, notifies the
or MLD proxy, notifies the NSP's mAAA function of the (S,G) NSP's mAAA function of the (S,G) channel identifier. The NSP should
channel identifier. The NSP should notify the CP of the notify the CP of the (S,G) information in the accounting report
(S,G) information in the accounting report messages. messages.
A NSP records an accounting start corresponding to only the A NSP records an accounting start corresponding to only the first
first Join for a specific user-access session. A NSP should Join for a specific user-access session. A NSP should not treat a
not treat a "Join" response to a Query as the accounting "Join" response to a Query as the accounting start.
start.
A NSP records an accounting stop triggered by any of the A NSP records an accounting stop triggered by any of the following:
following: 1) a user requested Leave, 2) a timeout of a 1) a user requested Leave, 2) a timeout of a multicast state or 3) a
multicast state or 3) a re-authentication failure. A NSP re-authentication failure. A NSP may also record an accounting stop
may also record an accounting stop due to network due to network availability reasons such as failure. The NSP logs
availability reasons such as failure. The NSP logs the the reason for each accounting stop.
reason for each accounting stop.
Intermittent logs between the join and leave would allow Intermittent logs between the join and leave would allow for finer
for finer diagnostics and therefore could serve useful in diagnostics and therefore could serve useful in billing
billing discrepancies, and provide for a better estimation discrepancies, and provide for a better estimation of the time-span
of the time-span that content was multicast, in the event that content was multicast, in the event that users disconnect
that users disconnect without sending leave messages. without sending leave messages.
There are two levels of accounting report messaging. There are two levels of accounting report messaging. Messages in
Messages in Accounting level 1 include a channel identifier, Accounting level 1 include a channel identifier, a user identifier,
a user identifier, and the accounting start and stop time and the accounting start and stop time information. Accounting level
information. Accounting level 2 includes all information of 2 includes all information of Level 1, plus traffic volume
Level 1, plus traffic volume information. information.
QoS class is an optional item for each accounting level. QoS class is an optional item for each accounting level. Whether to
Whether to send, and at what interval to send intermittent send, and at what interval to send intermittent log information is
log information is optional for both levels. CP and NSPs optional for both levels. CP and NSPs may also agree to include
may also agree to include additional option information in additional option information in accounting messages of either level.
accounting messages of either level.
The level of account report messaging between the NSP and The level of account report messaging between the NSP and CP may be
CP may be either configured statically or can be either configured statically or can be dynamically requested by the
dynamically requested by the CP in its response to the CP in its response to the Access-Request relayed by the NSP to the
Access-Request relayed by the NSP to the CP. The CP. The determination of the actual level of report messaging is
determination of the actual level of report messaging is
configured by the NSP at the NAS. configured by the NSP at the NAS.
Internet Draft AAA and Admission Control Framework for In case of very fast channel changes, the amount of items logged by
Multicasting January, 2009 the NSP could become high. In order to reduce the number of report
messages sent to the CP, the NSP can consolidate multiple sets of
accounting information inside a single accounting report message.
In case of very fast channel changes, the amount of items 4.4. Access Control and CP selection by NSP
logged by the NSP could become high. In order to reduce
the number of report messages sent to the CP, the NSP can
consolidate multiple sets of accounting information inside
a single accounting report message. [I-D.ancp-framework]
4.4 Access Control and CP selection by NSP When a NSP receives an access request from a user, the NSP determines
to which CP the request is to be directed. The NSP may select a CP
based on CP-assigned userID with CP domain name or channel identifier
(S,G). The user should include in the request sufficient information
for CP selection.
When a NSP receives an access request from a user, the NSP 4.5. Admission Control Information by NSP
determines to which CP the request is to be directed. The
NSP may select a CP based on CP-assigned userID with CP
domain name or 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.
After authorizing a user request, the NSP may have further The NSP receives parameters (such as QoS class, required bandwidth,
conditions for determining its admission control decision. burst-size, etc.) of multicast traffic. Such parameters serve as
information to be considered in the admission control decision. The
traffic parameters can be communicated as follows:
The NSP receives parameters (such as QoS class, required A CP may notify a mapping between the channel identifier (S,G) and
bandwidth, burst-size, etc.) of multicast traffic. Such traffic parameters in the Response message when the CP authorizes
parameters serve as information to be considered in the an access request. Such parameters may include required
admission control decision. The traffic parameters can be bandwidth, burst-size, QoS class downgrade policy, etc.
communicated as follows:
- 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. Such
parameters may include required bandwidth, burst-size, QoS
class downgrade policy, etc.
- A user may indicate in the Request willingness to
accept QoS class downgrade to best-effort streaming.
- 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 (S,G) basis.
The ultimate admission decision is made by the NSP based on A user may indicate in the Request willingness to accept QoS class
required traffic parameters of the requested, and available downgrade to best-effort streaming.
resources. In a case that it cannot guarantee the required
network resources for the requested multicast traffic,
streaming the requested multicast traffic as best-effort is
optional. The user may indicate in his/her Access
Request whether he/she will accept best-effort grade
streaming if guaranteed class is not available. The CP's
preference for accepting downgrading to best-effort
streaming may be either configured statically or can be
dynamically requested by the CP in its response to the
Internet Draft AAA and Admission Control Framework for The NSP may maintain a mapping between channel identifier (S,G)
Multicasting January, 2009 and traffic parameters in advance, for example pre-configured by
agreement between the CP and NSP on a per channel (S,G) basis.
Access-Request relayed by the NSP to the CP. In the case The ultimate admission decision is made by the NSP based on required
that it cannot be offered a guaranteed QoS stream, the NSP traffic parameters of the requested, and available resources. In a
may decide either to decline admission or to stream the case that it cannot guarantee the required network resources for the
requested multicast traffic as best-effort. The NSP should requested multicast traffic, streaming the requested multicast
not stream best-effort traffic if either the user or CP has traffic as best-effort is optional. The user may indicate in his/her
indicated against best-effort provision. Access Request whether he/she will accept best-effort grade streaming
if guaranteed class is not available. The CP's preference for
accepting downgrading to best-effort streaming may be either
configured statically or can be dynamically requested by the CP in
its response to the Access-Request relayed by the NSP to the CP. In
the case that it cannot be offered a guaranteed QoS stream, the NSP
may decide either to decline admission or to stream the requested
multicast traffic as best-effort. The NSP should not stream best-
effort traffic if either the user or CP has indicated against best-
effort provision.
A NSP's admission control may manage integrated network A NSP's admission control may manage integrated network resources for
resources for unicast usage, such as VoIP or unicast unicast usage, such as VoIP or unicast streaming, and multicast
streaming, and multicast usage. Alternatively, it may usage. Alternatively, it may manage network resources separately for
manage network resources separately for unicast and unicast and multicast usage. In either ease, AAA and admission
multicast usage. In either ease, AAA and admission control control framework for multicast usage is independent of unicast
framework for multicast usage is independent of unicast
admission control. admission control.
Such QoS measurement and policy mechanisms themselves Such QoS measurement and policy mechanisms themselves depend on NSP
depend on NSP policies and are out of the scope of this policies and are out of the scope of this memo.
memo.
4.6 Access Control and Distinguishing of Users by CP 4.6. Access Control and Distinguishing of Users by CP
The user ID and authentication information are forwarded The user ID and authentication information are forwarded
transparently by the NSP so that the CP can distinguish the transparently by the NSP so that the CP can distinguish the user, as
user, as well as authenticate and authorize the request. well as authenticate and authorize the request.
4.7 AAA proxy in NSP 4.7. AAA proxy in NSP
A NSP may act as AAA proxy of a CP based upon an agreement A NSP may act as AAA proxy of a CP based upon an agreement between
between the NSP and the CP. The AAA proxy would store the NSP and the CP. The AAA proxy would store information about
information about permissions of a specific user to receive permissions of a specific user to receive multicast data from
multicast data from specified channel(s) up to specified specified channel(s) up to specified expiration date(s) and time(s).
expiration date(s) and time(s).
If such proxying is implemented, the NSP may receive If such proxying is implemented, the NSP may receive authorization
authorization conditions from a CP in advance and conditions from a CP in advance and statically hold them, or a CP may
statically hold them, or a CP may send them dynamically in send them dynamically in the Response message. In either case, the
the Response message. In either case, the user has user has permission to receive multicast traffic and therefore the
permission to receive multicast traffic and therefore the
NSP starts the multicasting without querying the CP. NSP starts the multicasting without querying the CP.
The CP may send unsolicited requests to the NSP to refresh The CP may send unsolicited requests to the NSP to refresh or change
or change the permissions for a user for specific group(s) the permissions for a user for specific group(s) or channel(s).
or channel(s).
When a user is receiving multicast traffic while 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-authenticate. In
such a case, the user will have to send the Access-Request.
In the case that the user still has permission to the
Internet Draft AAA and Admission Control Framework for
Multicasting January, 2009
content, they should be able to continue to receive the When a user is receiving multicast traffic while the permission is
multicast traffic without interruption. 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-
authenticate. In such a case, the user will have to 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 multicast
traffic without interruption.
When re-authentication fails, the NSP should stop the When re-authentication fails, the NSP should stop the multicast
multicast traffic and record accounting stop. traffic and record accounting stop.
5. Network Connection Model and Functional Components 5. Network Connection Model and Functional Components
Section 3.1 introduced the high-level AAA framework for Section 3.1 introduced the high-level AAA framework for multicasting.
multicasting. This section provides more detail on the This section provides more detail on the network connection model and
network connection model and constituent functional constituent functional components.
components.
5.1 Basic Connection Model 5.1. Basic Connection Model
+------------------------------+ +------------------------------+
| receiver | | receiver |
| | | |
+------------------------------+ +------------------------------+
| ^ Response | ^ Response
| Request | | Request |
V | V |
+------------------------------+ +------------------------------+
| NSP's network | | NSP's network |
skipping to change at page 16, line 44 skipping to change at page 15, line 28
| ^ Response | ^ Response
| Request | (Success) | Request | (Success)
v | v |
+------------------------------+ +------------------------------+
| CP's network | | CP's network |
| | | |
+------------------------------+ +------------------------------+
Figure 2: Basic Connection Model Figure 2: Basic Connection Model
In the simple case represented in Figure 1 the NSP is the Figure 2
sole entity providing network resources including network
access to the multicast receiver. First a receiver sends a
request for multicast (e.g. an IGMP Report message) to an
NSP which may then forward a mAAA request towards the
appropriate CP for authentication and authorization
purposes. The receiver gets information about a given
multicast group (*,G) or channel (S,G) corresponding to the
content beforehand for generating the request. The CP
responds with either "success" or "failure". If "success",
the NSP grants access to the receiver and forwards
multicast traffic accordingly.
Internet Draft AAA and Admission Control Framework for
Multicasting January, 2009
In this model the receiver selects the NSP to which the In the simple case represented in Figure 1 the NSP is the sole entity
Join request will be sent. Based on this request the NSP providing network resources including network access to the multicast
selects an appropriate CP to which it forwards the receiver. First a receiver sends a request for multicast (e.g. an
corresponding mAAA request. The CP responds to the NSP's m IGMP Report message) to an NSP which may then forward a mAAA request
AAA request: it may not respond to another NSP in regards towards the appropriate CP for authentication and authorization
to the request. purposes. The receiver gets information about a given multicast
group (*,G) or channel (S,G) corresponding to the content beforehand
for generating the request. The CP responds with either "success" or
"failure". If "success", the NSP grants access to the receiver and
forwards multicast traffic accordingly.
In this model, as described in section 4.1, the In this model the receiver selects the NSP to which the Join request
relationship between NSP and CP can be one-to-one, one-to- will be sent. Based on this request the NSP selects an appropriate
many or many-to-many. Receivers may connect to multiple CP to which it forwards the corresponding mAAA request. The CP
networks. responds to the NSP's m AAA request: it may not respond to another
NSP in regards to the request.
5.2 Constituent Logical Functional Components of the fully In this model, as described in section 4.1, the relationship between
enabled AAA Framework NSP and CP can be one-to-one, one-to- many or many-to-many.
Receivers may connect to multiple networks.
Requirements for "fully AAA and QoS enabled" IP 5.2. Constituent Logical Functional Components of the fully enabled AAA
multicasting networks were defined in MACCNT-REQ-draft. To Framework
allow for levels of enablement, this memo defines two
models within the framework: "AAA enabled" multicasting and
"Fully enabled AAA" multicasting which means "AAA enabled"
with added admission control functions.
Section 3.1 introduces the high-level AAA framework for Requirements for "fully AAA and QoS enabled" IP multicasting networks
multicasting. Below is a diagram of a AAA enabled were defined in MACCNT-REQ-draft. To allow for levels of enablement,
multicasting network with AAA, including the logical this memo defines two models within the framework: "AAA enabled"
components within the various entities. multicasting and "Fully enabled AAA" multicasting which means "AAA
enabled" with added admission control functions.
Internet Draft AAA and Admission Control Framework for Section 3.1 introduces the high-level AAA framework for multicasting.
Multicasting January, 2009 Below is a diagram of a AAA enabled multicasting network with AAA,
including the logical components within the various entities.
+-------------------------------+ +-------------------------------+
| user | | user |
|+- - - - - - - - - - - - - - -+| |+- - - - - - - - - - - - - - -+|
|| CPE || || CPE ||
|| || || ||
|+- - - - - | - - - - - - - - -+| |+- - - - - | - - - - - - - - -+|
+-----------|-------------------+ +-----------|-------------------+
| |
-------|------ IFa -------|------ IFa
skipping to change at page 18, line 41 skipping to change at page 17, line 38
||+- - - - - - - + | | ||+- - - - - - - + | |
+-----------------------|--------+ +-----------------------|--------+
| |
-------|------ IFc -------|------ IFc
| |
+-----------------------|-------+ +-----------------------|-------+
| CP +---------+ | | CP +---------+ |
| | CP-AAA | | | | CP-AAA | |
| +---------+ | | +---------+ |
+-------------------------------+ +-------------------------------+
Figure 3: AAA enabled framework (basic model)
The user entity includes the CPE (Customer Premise Figure 3: AAA enabled framework (basic model)
Equipment) which connects the receiver (s).
The NSP (Network Service Provider) in the basic model Figure 3
includes the transport system and a logical element for
multicast AAA functionality. The TS (transport system) is
comprised of the access node and NAS (Network Access
Server) An AN (Access Node) may be connected directly to
mAAA or a NAS relays AAA information between an AN and a
mAAA. Descriptions of AN and its interfaces are out of the
scope for this memo. The multicast AAA function may be
provided by a mAAA which may include the function that
Internet Draft AAA and Admission Control Framework for The user entity includes the CPE (Customer Premise Equipment) which
Multicasting January, 2009 connects the receiver (s).
downloads Join access control lists to the NAS (this The NSP (Network Service Provider) in the basic model includes the
function is referred to conditional access policy control transport system and a logical element for multicast AAA
function.) functionality. The TS (transport system) is comprised of the access
node and NAS (Network Access Server) An AN (Access Node) may be
connected directly to mAAA or a NAS relays AAA information between an
AN and a mAAA. Descriptions of AN and its interfaces are out of the
scope for this memo. The multicast AAA function may be provided by a
mAAA which may include the function that downloads Join access
control lists to the NAS (this function is referred to conditional
access policy control function.)
Interface between mAAA and NAS Interface between mAAA and NAS
The interface between mAAA and the NAS is labeled IFb in The interface between mAAA and the NAS is labeled IFb in Figure 2.
Figure 2. Over IFb the NAS sends an access request to the Over IFb the NAS sends an access request to the NSP-mAAA and the mAAA
NSP-mAAA and the mAAA replies. The mAAA may push replies. The mAAA may push conditional access policy to the NAS.
conditional access policy to the NAS.
CP-AAA CP-AAA
The content provider may have its own AAA server which has
the authority over access policy for its contents. The content provider may have its own AAA server which has the
authority over access policy for its contents.
Interface between user and NSP Interface between user and NSP
The interface between the user and the NSP is labeled IFa
in Figure 3. Over IFa the user makes a multicasting The interface between the user and the NSP is labeled IFa in Figure
request to the NSP. The NSP may in return forward 3. Over IFa the user makes a multicasting request to the NSP. The
multicast traffic depending on the NSP and CP's policy NSP may in return forward multicast traffic depending on the NSP and
decisions. CP's policy decisions.
Interface between NSP and CP Interface between NSP and CP
The interface between the NSP and CP is labeled IFc. Over
IFc the NSP requests to the CP-AAA for access to contents
and the CP replies. CP may also send conditional access
policy over this interface for AAA-proxying.
Internet Draft AAA and Admission Control Framework for The interface between the NSP and CP is labeled IFc. Over IFc the
Multicasting January, 2009 NSP requests to the CP-AAA for access to contents and the CP replies.
CP may also send conditional access policy over this interface for
AAA-proxying.
+-------------------------------+ +-------------------------------+
| user | | user |
|+- - - - - - - - - - - - - - -+| |+- - - - - - - - - - - - - - -+|
|| CPE || || CPE ||
|| || || ||
|+- - - - - | - - - - - - - - -+| |+- - - - - | - - - - - - - - -+|
+-----------|-------------------+ +-----------|-------------------+
| |
-------|------ IFa -------|------ IFa
skipping to change at page 20, line 45 skipping to change at page 19, line 42
-------|------ IFc -------|------ IFc
| |
+-----------------------|-------+ +-----------------------|-------+
| CP +---------+ | | CP +---------+ |
| | CP-AAA | | | | CP-AAA | |
| +---------+ | | +---------+ |
+-------------------------------+ +-------------------------------+
Figure 4: Fully enabled framework Figure 4: Fully enabled framework
In the fully enabled model the NSP also includes a Figure 4
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 MACF (Multicast Admission Control Function).
This means that, before replying to the user's multicast
request, the mAAA queries the MACF for a network resource
access decision over the interface IFd. The MACF is
responsible for allocating network resources for forwarding
multicast traffic. MACF also receives Leave information
from NAS so that MACF releases corresponding reserved
resources.
Internet Draft AAA and Admission Control Framework for In the fully enabled model the NSP also includes a component that
Multicasting January, 2009 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 MACF (Multicast Admission Control Function).
This means that, before replying to the user's multicast request, the
mAAA queries the MACF for a network resource access decision over the
interface IFd. The MACF is responsible for allocating network
resources for forwarding multicast traffic. MACF also receives Leave
information from NAS so that MACF releases corresponding reserved
resources.
5.3 Modularity of the framework 5.3. Modularity of the framework
In the interest of flexibility, this framework is modular In the interest of flexibility, this framework is modular so that it
so that it is possible that partially enabled versions of is possible that partially enabled versions of the models are
the models are supported. A AAA-enabled version provides supported. A AAA-enabled version provides AAA functionality without
AAA functionality without Network Resource management. A Network Resource management. A Network-Resource-Management-enabled
Network-Resource-Management-enabled (QoS-enabled) version (QoS-enabled) version provides Network Resource management without
provides Network Resource management without AAA AAA functionality. Similarly, the possibility of one or more layers
functionality. Similarly, the possibility of one or more of transit provision between an NSP and CP is in the interest of
layers of transit provision between an NSP and CP is in the modularity and extendibility.
interest of modularity and extendibility.
6. IANA considerations 6. IANA Considerations
This memo does not raise any IANA consideration issues. This memo does not raise any IANA consideration issues.
7. Security considerations 7. Security Considerations
The user information related to authentication with the CP The user information related to authentication with the CP and the
and the information related to user accounting shared information related to user accounting shared between the NSP and the
between the NSP and the CP must be protected in some way. CP must be protected in some way. Otherwise, this memo does not
Otherwise, this memo does not raise any new security issues raise any new security issues which are not already addressed by the
which are not already addressed by the original protocols. original protocols. Enhancement of multicast access control
Enhancement of multicast access control capabilities should capabilities should enhance security performance.
enhance security performance.
8. Conclusion 8. Conclusion
This memo provides a generalized framework for solution This memo provides a generalized framework for solution standards to
standards to meet the requirements. Further work should be meet the requirements. Further work should be done to specify the
done to specify the interfaces between the user and NSP, interfaces between the user and NSP, NAS and mAAA, mAAA and MACF and
NAS and mAAA, mAAA and MACF and NSP-mAAA and CP-AAA NSP-mAAA and CP-AAA (presented in 5.2.)
(presented in 5.2.)
Normative References 9. Normative References
[I-D.mboned-maccnt-req] [I-D.ietf-ancp-framework]
Hayashi, et. al., "Requirements for Multicast AAA Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S.
coordinated between Content Provider(s) and Network Wadhwa, "Framework and Requirements for an Access Node
Service Provider(s)", draft-ietf-mboned-maccnt-req- Control Mechanism in Broadband Multi-Service Networks",
07.txt, January 2009, Work in Progress. draft-ietf-ancp-framework-11 (work in progress),
July 2009.
[I-D.ancp-framework] [I-D.ietf-mboned-maccnt-req]
Ooghe, et. al, "Framework and Requirements for an Hayashi, T., He, H., Satou, H., Ohta, H., and S. Vaidya,
Access Node Control Mechanism in Broadband Multi- "Requirements for Multicast AAA coordinated between
Content Provider(s) and Network Service Provider(s)",
draft-ietf-mboned-maccnt-req-08 (work in progress),
July 2009.
Internet Draft AAA and Admission Control Framework for Authors' Addresses
Multicasting January, 2009
Service Networks", draft-ietf-ancp-framework-07.txt, Tsunemasa Hayashi
November 2008, Work in Progress. NTT Network Innovation Laboratories
1-1 Hikarino'oka
Yokosuka-shi, Kanagawa 239-0847
Japan
Authors' Addresses Phone: +81 46 859 8790
Email: hayashi.tsunemasa@lab.ntt.co.jp
Haixiang He
Nortel
600 Technology Park Drive
Billerica, MA 01801
USA
Phone: +1 978 288 7482
Email: haixiang@nortel.com
Hiroaki Satou Hiroaki Satou
NTT Network Service Systems Laboratories NTT Network Service Systems Laboratories
3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 3-9-11 Midoricho
Musashino-shi, Tokyo 180-8585
Japan Japan
Phone : +81 422 59 4683 Phone : +81 422 59 4683
Email : satou.hiroaki@lab.ntt.co.jp Email : satou.hiroaki@lab.ntt.co.jp
Hiroshi Ohta Hiroshi Ohta
NTT Network Service Systems Laboratories NTT Network Service Systems Laboratories
3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 3-9-11 Midoricho
Musashino-shi, Tokyo 180-8585
Japan Japan
Phone : +81 422 59 3617 Phone : +81 422 59 3617
Email: ohta.hiroshi@lab.ntt.co.jp Email: ohta.hiroshi@lab.ntt.co.jp
Christian Jacquenet Christian Jacquenet
France Telecom France Telecom
3, avenue Francois Chateau 3, avenue Francois Chateau
CS 36901, 35069 Rennes Cedex, France CS 36901, Rennes Cedex 95134
France
Phone: +33 2 99 87 61 92 Phone: +33 2 99 87 61 92
Email: christian.jacquenet@orange-ftgroup.com Email: 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
 End of changes. 144 change blocks. 
650 lines changed or deleted 567 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/