draft-ietf-mboned-multiaaa-framework-06.txt   draft-ietf-mboned-multiaaa-framework-07.txt 
Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008
Internet Draft Hiroaki Satou, NTT Internet Draft Hiroaki Satou, NTT
Intended Status: Hiroshi Ohta, NTT Intended Status: Hiroshi Ohta, NTT
Informational Informational
Expires: August Christian Jacquenet, France Telecom Expires: January Christian Jacquenet, France Telecom
22, 2008 3, 2009
Tsunemasa Hayashi, NTT Tsunemasa Hayashi, NTT
Haixiang He, Nortel Networks Haixiang He, Nortel Networks
February 25, 2007 July 1, 2008
AAA Framework for Multicasting AAA and Admission Control Framework for Multicasting
<draft-ietf-mboned-multiaaa-framework-06.txt> <draft-ietf-mboned-multiaaa-framework-07.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author By submitting this Internet-Draft, each author represents
represents that any applicable patent or other IPR that any applicable patent or other IPR claims of which he
claims of which he or she is aware have been or will or she is aware have been or will be disclosed, and any of
be disclosed, and any of which he or she becomes which he or she becomes aware will be disclosed, in
aware will be disclosed, in accordance with Section accordance with Section 6 of BCP 79.
6 of BCP 79.
Internet-Drafts are working documents of the Internet-Drafts are working documents of the Internet
Internet Engineering Task Force (IETF), its areas, Engineering Task Force (IETF), its areas, and its working
and its working groups. Note that other groups may groups. Note that other groups may also distribute working
also distribute working documents as Internet- documents as Internet-Drafts.
Drafts.
Internet-Drafts are draft documents valid for a Internet-Drafts are draft documents valid for a maximum of
maximum of six months and may be updated, replaced, six months and may be updated, replaced, or obsoleted by
or obsoleted by other documents at any time. It is other documents at any time. It is inappropriate to use
inappropriate to use Internet-Drafts as reference Internet-Drafts as reference material or to cite them other
material or to cite them other than as "work in than as "work in progress."
progress."
The list of current Internet-Drafts can be accessed The list of current Internet-Drafts can be accessed at
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 http://www.ietf.org/shadow.html. accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 22, 2008. Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008
This Internet-Draft will expire on January 3, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). This document Copyright (C) The IETF Trust (2008). This document is
is subject to the rights, licenses and restrictions subject to the rights, licenses and restrictions contained
contained in BCP 78, and except as set forth in BCP 78, and except as set forth therein, the authors
therein, the authors retain all their rights. retain all their rights.
Abstract Abstract
IP multicast-based services, such as TV broadcasting IP multicast-based services, such as TV broadcasting or
or videoconferencing raise the issue of making sure videoconferencing raise the issue of making sure that
that potential customers are fully entitled to potential customers are fully entitled to access the
access the corresponding contents. There is indeed a corresponding contents. There is indeed a need for service
need for service and content providers to identify and content providers to identify users (if not
(if not authenticate, especially within the context authenticate, especially within the context of enforcing
of enforcing electronic payment schemes) and to electronic payment schemes) and to retrieve statistical
invoice such customers in a reliable and efficient information for accounting purposes, as far as content and
manner. This memo describes the framework for network usage are concerned. This memo describes the
specifying the Authorization, Authentication and framework for specifying the Authorization, Authentication
Accounting (AAA) capabilities that could be and Accounting (AAA) capabilities that could be activated
activated within the context of the deployment and within the context of the deployment and the operation of
the operation of IP multicast-based services. This IP multicast-based services. This framework addresses the
framework addresses the requirements presented in requirements presented in "Requirements for Accounting,
draft-ietf-mboned-maccnt-req-04.txt, "Requirements Authentication and Authorization in Well Managed IP
for Accounting, Authentication and Authorization in Multicasting Services" [I-D.mboned-maccnt-req]. The memo
Well Managed IP Multicasting Services". The memo provides a basic AAA enabled model as well as an extended
provides a basic AAA enabled model as well as an fully enabled model with resource and admission control
extended fully enabled model with resource and coordination.
admission control coordination.
Table of Contents Table of Contents
1. INTRODUCTION 4 1. INTRODUCTION 4
1.1 PURPOSE AND BACKGROUND 4 1.1 PURPOSE AND BACKGROUND 4
2. DEFINITIONS AND ABBREVIATIONS 5 2. DEFINITIONS AND ABBREVIATIONS 5
2.1 DEFINITIONS 5 2.1 DEFINITIONS 5
2.2 ABBREVIATIONS 6 2.2 ABBREVIATIONS 6
3. COMMON USE MODELS AND NETWORK ARCHITECTURE IMPLICATIONS 7 3. COMMON USE MODELS AND NETWORK ARCHITECTURE IMPLICATIONS 7
4. FRAMEWORK AND ROLES OF ENTITIES 8 4. FRAMEWORK AND ROLES OF ENTITIES 9
4.1 "AAA FRAMEWORK IN MULTICAST-ENABLED ENVIRONMENTS 8 4.1 "AAA FRAMEWORK IN MULTICAST-ENABLED ENVIRONMENTS 9
4.1.1 MULTIPLE CPS ARE CONNECTED TO MULTIPLE NSPS 9 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.2 MULTIPLE CPS ARE CONNECTED TO A SINGLE NSP 11
4.1.3 A SINGLE CP IS CONNECTED TO MULTIPLE NSPS 10 4.1.3 A SINGLE CP IS CONNECTED TO MULTIPLE NSPS 11
4.1.4 A SINGLE CP IS CONNECTED TO SINGLE NSP 10 4.1.4 A SINGLE CP IS CONNECTED TO SINGLE NSP 11
4.2 USER ID 11 4.2 USER ID 12
4.2.1 CP-ASSIGNED USER ID 11 4.2.1 CP-ASSIGNED USER ID 12
4.2.2 NSP-ASSIGNED USER ID 11 4.2.2 NSP-ASSIGNED USER ID 12
4.3 ACCOUNTING 12 4.3 ACCOUNTING 13
4.4 ACCESS CONTROL AND CP SELECTION BY NSP 13 4.4 ACCESS CONTROL AND CP SELECTION BY NSP 14
4.5 ADMISSION CONTROL INFORMATION BY NSP 13 4.5 ADMISSION CONTROL INFORMATION BY NSP 14
4.6 ACCESS CONTROL AND DISTINGUISHING OF USERS BY CP 14 4.6 ACCESS CONTROL AND DISTINGUISHING OF USERS BY CP 15
4.7 AAA PROXY IN NSP 14 Internet Draft AAA and Admission Control Framework for
5.1 BASIC CONNECTION MODEL 15 Multicasting July, 2008
4.7 AAA PROXY IN NSP 15
5.1 BASIC CONNECTION MODEL 16
5.2 CONSTITUENT LOGICAL FUNCTIONAL COMPONENTS OF THE FULLY 5.2 CONSTITUENT LOGICAL FUNCTIONAL COMPONENTS OF THE FULLY
ENABLED AAA FRAMEWORK 15 ENABLED AAA FRAMEWORK 17
5.3 MODULARITY OF THE FRAMEWORK 19 5.3 MODULARITY OF THE FRAMEWORK 21
6. IANA CONSIDERATIONS 19 6. IANA CONSIDERATIONS 21
7. SECURITY CONSIDERATIONS 19 7. SECURITY CONSIDERATIONS 21
8. CONCLUSION 19 8. CONCLUSION 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 schemes of any kind, such as 1-to-n (case of communication schemes of any kind, such as one-to-many
TV broadcasting services for example) or n-to-p (case of (case of TV broadcasting services for example) or many-to-
videoconferencing services, for example). many (case of videoconferencing services, for example).
In these environments, IP multicast provides a better In these environments, IP multicast provides a better
resource optimization than using a unicast transmission resource optimization than using a unicast transmission
scheme, where data need to be replicated as many times as scheme, where data need to be replicated as many times as
there are receivers. Activation of IP multicast there are receivers. Activation of IP multicast
capabilities in networks yields the establishment and the capabilities in networks yields the establishment and the
maintenance of multicast distribution trees that are maintenance of multicast distribution trees 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. forwarded to receivers who explicitly request them.
IP multicast-based services, such as TV broadcasting or IP multicast-based services, such as TV broadcasting or
skipping to change at page 5, line 5 skipping to change at page 5, line 5
corresponding contents. There is indeed a need for service corresponding contents. There is indeed a need for service
and content providers to identify (if not authenticate, and content providers to identify (if not authenticate,
especially within the context of enforcing electronic especially within the context of enforcing electronic
payment schemes) and to invoice such customers in a payment schemes) and to invoice such customers in a
reliable and efficient manner. Solutions should consider a reliable and efficient manner. Solutions should consider a
wide range of possible content delivery applications: wide range of possible content delivery applications:
content delivered over the multicast network may include content delivered over the multicast network may include
video, audio, images, games, software and information such video, audio, images, games, software and information such
as financial data, etc. as financial data, etc.
Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008
This memo describes a framework for specifying the This memo describes a framework for specifying the
Authorization, Authentication and Accounting (AAA) Authorization, Authentication and Accounting (AAA)
capabilities that could be activated within the context of capabilities that could be activated within the context of
the deployment and the operation of IP multicast-based the deployment and the operation of IP multicast-based
services. This memo also describes a framework to realize services. This memo also describes a framework to realize
high-quality multicast transport using a Multicast high-quality multicast transport using a Multicast
Admission Control Function (MACF) with multicast Admission Control Function (MACF) with multicast
Authorization. Authorization.
Specifically, this framework addresses the requirements Specifically, this framework addresses the requirements
presented in draft-ietf-mboned-maccnt-req-05.txt, presented in "Requirements for Multicast AAA coordinated
"Requirements for Multicast AAA coordinated between Content between Content Provider(s) and Network Service
Provider(s) and Network Service Provider(s)" MACCNT-REQ- Provider(s)" which describes the requirements in CDN
draft describes the requirements in CDN services using IP services using IP multicast. The requirements are derived
multicast[1]. The requirements are derived from: from:
- need for user tracking and billing capabilities - need for user tracking and billing capabilities
- need for network access control to satisfy the - need for network access control to satisfy the
requirements of the Network Service Provider (NSP) and/or requirements of the Network Service Provider (NSP) and/or
content access control to satisfy the requirements of the content access control to satisfy the requirements of the
Content Provider (CP) Content Provider (CP)
- methods for sharing information between the network - methods for sharing information between the network
service provider and content provider to make it possible service provider and content provider to make it possible
to fulfill the above two requirements. to fulfill the above two requirements. [I-D.mboned-maccnt-
req]
Detailed requirements are presented in MACCNT-REQ-draft. Detailed requirements are presented in "Requirements for
Accounting, Authentication and Authorization in Well
Managed IP Multicasting Services" [I-D.mboned-maccnt-req].
These requirements include mechanisms for recording end- These requirements include mechanisms for recording end-
user requests and provider responses for content-delivery, user requests and provider responses for content-delivery,
sharing user information (possibly anonymously depending on sharing user information (possibly anonymously depending on
the trust model) between content provider and network the trust model) between content provider and network
service provider, and protecting resources through the service provider, and protecting resources through the
prevention of network and content access by unauthorized prevention of network and content access by unauthorized
users, as well as other AAA related requirements. users, as well as other AAA related requirements.
The purpose of this memo is to provide a generalized The purpose of this memo is to provide a generalized
framework for specifying multicast-inferred AAA framework for specifying multicast-inferred AAA
skipping to change at page 5, line 50 skipping to change at page 6, line 5
framework is to provide a basis for future work of framework is to provide a basis for future work of
investigating the applicability of existing AAA protocols investigating the applicability of existing AAA protocols
to provide these AAA capabilities in IP multicast specific to provide these AAA capabilities in IP multicast specific
context and/or if deemed necessary, the refining or context and/or if deemed necessary, the refining or
defining of protocols to provide these capabilities. defining of protocols to provide these capabilities.
2. Definitions and Abbreviations 2. Definitions and Abbreviations
2.1 Definitions 2.1 Definitions
Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008
For the purpose of this memo the following definitions For the purpose of this memo the following definitions
apply: apply:
Accounting: The set of capabilities that allow the Accounting: The set of capabilities that allow the
retrieval of a set of statistical data that can be defined retrieval of a set of statistical data that can be defined
on a per customer and/or a per service basis, within the on a per customer and/or a per service basis, within the
context of the deployment of multicast-based services. Such context of the deployment of multicast-based services. Such
data are retrieved for billing purposes, and can be data are retrieved for billing purposes, and can be
retrieved on a regular basis or upon unsolicited requests. retrieved on a regular basis or upon unsolicited requests.
Such data include (but are not necessarily limited to) the Such data include (but are not necessarily limited to) the
volume of multicast-formatted data that have been forwarded volume of multicast-formatted data that have been forwarded
to the receiver over a given period of time, the volume of to the receiver over a given period of time, the volume of
multicast-formatted data that have been exchanged between a multicast-formatted data that have been exchanged between a
receiver (or set of) and a given source over a given period receiver (or set of) and a given source over a given period
of time (e.g. the duration of a multicast session), etc. of time (e.g. the duration of a multicast session), etc.
Authentication: action for identifying a user as a genuine Authentication: action for identifying a user as a genuine
one. one.
Authorization: The set of capabilities that need to be Authorization: The set of capabilities that need to be
activated to make sure a given requesting customer is (1) activated to make sure an authenticated user is fully
what he claims to be (identification purposes), and (2) is entitled to access a set of services.
fully entitled to access a set of services (authentication
purposes). Join: Signaling mechanism used by receivers to indicate
they want to access a multicast group and receive the
corresponding traffic.
Leave: Signaling mechanism used by receivers to indicate
they want to leave a multicast group and not receive the
corresponding traffic anymore.
Receiver: an end-host or end-client which receives content. Receiver: an end-host or end-client which receives content.
A receiver may be identified by a network ID such as MAC A receiver may be identified by a network ID such as MAC
address or IP address. 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 reception device. same reception device. (Note: The definition of a receiver
(device) and a user (human) should not be confused.)
Note: The definition of a receiver (device) 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
ACL: Access Control List ACL: Access Control List
Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008
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
functions used by a Content Provider
CPE: Customer Premise Equipment CPE: Customer Premise Equipment
ID: Identifier
IF: network interface
mAAA: Authentication, Authorization, and Accounting
functions activated in multicast-enabled environments
MACF: Multicast Admission Control Function MACF: Multicast Admission Control Function
NAS: Network Access Server (RFC2881)
NSP: Network Service Provider NSP: Network Service Provider
TS: Transport System NSP-mAAA: Authentication, Authorization, and Accounting
functions used by a Network Service provider
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 system that covers the various common high-level for a system that covers the various common high-level
requirements of a multicasting system such as 1) content requirements of a multicasting system such as 1) content
serving, 2) the infrastructure to multicast it, 3) network serving, 2) the infrastructure to multicast it, 3) network
and content access control mechanisms. In many cases and content access control mechanisms.
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 In many cases however the content provision and network
responsible for the multicasting structure and the entity provision roles are divided between separate entities.
responsible for content serving are the same. Indeed Commonly, Content Providers (CP) do not build and maintain
because the infrastructure for multicasting is expensive their own multicast network infrastructure as this is not
and many content holders are not likely to be competent at their primary business area. CP often purchase transport
building and maintaining complicated infrastructures and management services from network service providers
necessary for multicasting, many content holders would instead. Similarly Network Service Providers (NSP) may not
prefer to purchase transport and management services from a make their business in providing content. [I-D.mboned-
network service provider and thus share the infrastructure maccnt-req] provides more detail of the multiple versus
costs with other content holders.
Similarly network service providers in many cases do not Internet Draft AAA and Admission Control Framework for
specialize in providing content and are unlikely to build Multicasting July, 2008
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 single-entity Content Delivery Service (CDS) network
services to multiple CPs the following general requirements models.
from MACCNT-REQ-draft apply:
In the usage model where a single NSP provides multicast
services to multiple CPs, the following general
requirements from [I-D.mboned-maccnt-req] apply:
-Need for user tracking and billing capabilities -Need for user tracking and billing capabilities
-Need for QoS control such as resource management and -Need for QoS control such as resource management and
admission control admission control
-Need for conditional content access control -Need for conditional multicast access control
satisfactory to the requirements of the CP satisfactory to the requirements of the CP
-Methods for sharing information between the NSP and -Methods for sharing information between the NSP and
CP to make the above two possible CP to make the above two possible
When the NSP and CP are the same single entity the general When the NSP and CP are the same single entity then the
requirements are as follows. general requirements are as follows.
-Need for user tracking and user-billing capabilities -Need for user tracking and user-billing capabilities
-Need for access control and/or content protection at -Need for access control and/or content protection at
level the entity deems appropriate level the entity deems appropriate
Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008
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 can be represented as A general high-level framework is depicted in Figure 1.
follows.
+------------------------------+ +------------------------------+
| user | | user |
| | | |
+------------------------------+ +------------------------------+
| Access ^ Response |
| Request | |
V | |
+------------------------------+ +------------------------------+
| NSP | | NSP |
| | | |
+------------------------------+ +------------------------------+
| Access ^ Response |
| Request | (Success) |
v | |
+------------------------------+ +------------------------------+
| CP | | CP |
| | | |
+------------------------------+ +------------------------------+
Figure 1
Figure 1: High-level AAA framework in Multicast-Enabled
Environments
For the sake of simplicity, the above diagram portrays a For the sake of simplicity, the above diagram portrays a
case where there is a single NSP entity and a single CP case where there is a single NSP entity and a single CP
entity, but multiple CPs can be connected to a single NSP entity (one-to-one model), but multiple CPs can be
(e.g. NSP may provide connections to multiple CPs to connected to a single NSP (e.g. NSP may provide connections
provide a wide selection of content categories.) It is also to multiple CPs to provide a wide selection of content
possible for a single CP to be connected to multiple NSP categories: one-to-many model) It is also possible for a
networks (e.g. network selection). Furthermore it is single CP to be connected to multiple NSP networks (e.g.
possible that the NSP and CP could be the same entity. A network selection). Furthermore it is possible that the NSP
NSP and CP authenticate and authorize each other when they and CP could be the same entity. A NSP and CP authenticate
establish connectivity. Below the general case of multiple and authorize each other when they establish connectivity.
NSPs with multiple CPs is explained. Then, the various Below the general case of multiple NSPs with multiple CPs
combinations of single and multiple CPs and NSPs are is explained. Then, the various combinations of single and
described in relation to the general case. multiple CPs and NSPs are described in relation to the
general case.
4.1.1 Multiple CPs are connected to multiple NSPs 4.1.1 Multiple CPs are connected to multiple NSPs
The user subscribes to multiple NSPs and multiple CPs in The user subscribes to multiple NSPs and multiple CPs in
this usage case. The user selects a CP and a NSP when the this usage case. The user selects a CP and a NSP when the
user requests content. The NSP may be automatically user requests content. The NSP may be automatically
selected by a user terminal: e.g. a fixed line NSP by a set 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 top box or a mobile NSP by a mobile phone. In some usage
Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008
cases it is possible that the NSP used by a certain user cases it is possible that the NSP used by a certain user
will not always be the same. For example a user may have will not always be the same. For example a user may have
contracted with more than one NSP: one for fixed line contracted with more than one NSP: one for fixed line
access and another for mobile roaming access. access and another for mobile roaming access.
The content may be associated with (or managed by) a The content may be associated with (or managed by) a
specific CP. In this case, when the user selects content, specific CP. In this case, when the user selects content,
the CP is automatically selected. the CP is automatically selected.
The user should send an Access-Request to the selected NSP Requests for multicast sent by the user to a selected NSP
with enough information not only for authentication by the should include enough information not only for
CP but also for CP selection and admission control by the authentication by the CP but also for CP selection and
NSP. admission control by the NSP.
When an NSP receives an Access-Request from a user, the NSP When an NSP receives a request for multicast from a user,
selects the appropriate CP for the received Access-Request the NSP requests the appropriate CP to make sure that the
and relays the content request. As the NSP is responsible user is entitled to access the corresponding content As
for managing its network resources, the NSP may perform the NSP is responsible for managing its network resources,
admission control.The NSP will allow access to the network the NSP may perform admission control.The NSP will allow
and contents conditional to both the CP's content access to the multicast service, depending on both the
authorization result and the NSPs network availability. response sent by the CP and the availability of resources
That is, the NSP starts multicast flow only when it has operated by the NSP. That is, the NSP will forward
both 1) received an "accept" response from the CP and 2) multicast traffic towards the user only when the NSP has 1)
determined that the network resources (e.g. bandwidth) are made sure the user is entitled to access the network
sufficient to serve the multicast channel. When neither of resources operated by the NSP, 2) received a confirmation
these conditions are met, the NSP does not start the from the CP that the user is entitled to access the content
requested multicast channel. When the NSP already knows 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 that network resources are insufficient or there is a
network failure, the NSP may choose to not relay the network failure, the NSP may choose to not request the CP
Access-Request to the CP. The NSP is also responsible for about the user's ability to retrieve content. The NSP is
relaying the Response message from the CP to the user also responsible for notifiying the user whether he/she is
whether the user is eligible to receive content (in eligible to receive content depending on the response sent
response to the corresponding Access-Request from the user by the CP. In cases where the NSP does not start
to the CP.) In cases that the NSP does not start
multicasting because of its own network issues (e.g. lack multicasting because of its own network issues (e.g. lack
of network resources or network failure), the NSP notifies of network resources or network failure), the NSP notifies
the user with a reason for rejecting the request. the user with a reason for rejecting the request.
A CP receives an Access-Request relayed by the NSP. The CP A CP receives an inquiry from the NSP. The CP authenticates
authenticates the NSP's identity and makes an authorization the NSP's identity and makes an authorization decision
decision regarding the NSP's eligibility to provide users regarding the user's eligibility to access the requested
access to its contents. The CP is responsible for contents. The CP is responsible for the authentication
Authentication and Authorization of users' access to and authorization of users so that they can access the
content that the CP manages. The CP hopes to collect content managed by the CP. The CP notifies the NSP
accounting information related to the access of their accordingly. When the CP cannot (e.g. error or resource
content. The CP responds to the NSP regarding the relayed issues) or decides not (e.g. policy issues) to deliver
Access-Request. When the CP cannot (e.g. error or
resource issues) or decides not (e.g. policy issues) to Internet Draft AAA and Admission Control Framework for
deliver content, the CP is responsible for notifying the Multicasting July, 2008
NSP of the reason. It is up to the NSP how to relay or
translate the reasons for rejection to the user. 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
in NSP' is described in 4.7 for this case.
As defined in [I-D.mboned-maccnt-req], the CP may require
the retrieval of accounting information related to the
access of its 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 of channels from multiple CPs in this usage multicasting from multiple CPs in this usage case. In this
case. In this case the user does not select an NSP. The case the user does not select an NSP. The user selects a
user selects a CP when the user requests content. The CP when the user requests content. The content may be
content may be associated with (or managed by) the specific associated with (or managed by) the specific CP, so that
CP, so that when the user selects content, the CP is when the user selects content, the CP is automatically
automatically selected. selected.
The user should send an Access-Request to the specific NSP
with enough information not only for authentication by the The user should send a request for multicast to the
CP but also for CP selection and admission control by the specific NSP with enough information not only for
NSP. authentication by the CP but also for CP selection and
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 A single CP is connected to multiple NSPs
A user subscribes to multiple NSPs but a single CP in this In this usage case, a user subscribes to multiple NSPs but
usage case. A user selects the NSP when the user requests only a single CP. A user selects the NSP when the user
content but the CP is fixed. The user should send an requests multicast but the CP is fixed. The user should
Access-Request to the selected NSP with enough information send a request for multicast to the selected NSP with
not only for authentication by the CP but also for enough information not only for authentication by the CP
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 exception that when a NSP receives an Access- with the exception that when a NSP receives a request from
Request from a user, NSP relays it to the CP without CP a user, NSP makes an inquiry to the CP without CP selection.
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. In this case, a user subscribes to only one NSP and one CP.
The user does not select NSP and CP in this scenario. The The user does not select a NSP and CP in this scenario.
user should send an Access-Request to the NSP with enough Requests for multicast sent by the user to a selected NSP
information not only for authentication by the CP but also
for admission control by the NSP. Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008
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 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 role of the CP is the same as the description in 4.1.1.
The NSP and CP could be the same entity. In this case, the The NSP and CP could be the same entity. In this case, the
roles of the NSP and CP may be combined. roles of the NSP and CP may be combined.
4.2 User ID 4.2 User ID
Users may hold multiple user IDs: IDs which have been Users may hold multiple user IDs: IDs which have been
separately assigned for each subscription they may have for separately assigned for each subscription to various NSPs
various NSPs and CPs. The NSPs and CPs manage the user IDs and CPs. The NSPs and CPs manage the user IDs for their
for their respective domains. A CP identifies a user by a respective domains. A CP identifies a user by a user ID
user ID assigned by the CP itself. A NSP identifies a user assigned by the CP itself. A NSP identifies a user by a
by a user ID assigned by the NSP itself. The user IDs are user ID assigned by the NSP itself. The user IDs are only
only meaningful within the context of each domain. Users meaningful within the context of each domain. Users may
may hold multiple user IDs which have been separately hold multiple user IDs which have been separately assigned
assigned for each subscription they may have for various for each subscription they may have for various NSPs and
NSPs and CPs. CPs.
4.2.1 CP-assigned user ID 4.2.1 CP-assigned user ID
CPs assign user IDs to their users. The user may have more CPs assign user IDs to their users. The user may have more
than one CP-assigned user ID per specific CP. A user sends than one CP-assigned user ID per specific CP. A user
an Access-Request to a NSP, the CP-assigned user ID should requests multicast to a NSP, the CP-assigned user ID should
be indicated so that the CP can identify the user be indicated so that the CP can identify the user
requesting content access. A NSP should relay the CP- requesting content access. A NSP should notify the CP-
assigned user ID from the user to the CP. A NSP should not assigned user ID to the CP. A NSP should not share a CP-
send a CP-assigned user ID to any CP except the one which assigned user ID with any CP except the one which assigned
assigned it and should not relay it at all if there is no it and should not relay it at all if there is no
appropriate CP that assigned the user ID. appropriate CP that assigned the user ID.
4.2.2 NSP-assigned user ID 4.2.2 NSP-assigned user ID
NSPs assign user IDs to their users. A user may have more NSPs assign user IDs to their users. A user may have more
than one NSP-assigned user ID per a specific NSP. A user than one NSP-assigned user ID per a specific NSP. A user
sends an Access-Request to a NSP, the NSP-assigned user ID requests for multicast to a NSP, the NSP-assigned user ID
may be indicated in the request so that the NSP can may be indicated in the request so that the NSP can
identify the user. The NSP should not relay the NSP- identify the user. The NSP should not inform the NSP-
assigned user ID to the CP for security reasons. The NSP assigned user ID to the CP for security reasons. The NSP
may identify the multicast-access user by other methods may identify the multicast-access user by other methods
than the NSP-assigned userID, e.g. by the access port. than the NSP-assigned userID, e.g. by the access port.
Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008
The actual mapping rules for NSP-assigned user IDs with CP- The actual mapping rules for NSP-assigned user IDs with CP-
user assigned IDs in account logs is a matter for the user assigned IDs in account logs is a matter for the
providers and out of the scope of this framework. providers and out of 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) should be recorded as a channel identifier. The An (S,G) should be recorded as a channel identifier. The
last hop device, such as an IGMP or MLD router or an IGMP last hop device, such as an IGMP or MLD router or an IGMP
or MLD proxy, notifies the NSP's AAA function of the (S,G) or MLD proxy, notifies the NSP's mAAA function of the (S,G)
channel identifier. The NSP should notify the CP of the channel identifier. The NSP should notify the CP of the
(S,G) information in the accounting report messages. (S,G) information in the accounting report messages.
A NSP records an accounting start corresponding to only the A NSP records an accounting start corresponding to only the
first Join for a specific user-access session. A NSP should first Join for a specific user-access session. A NSP should
not treat a "Join" response to a Query as the accounting not treat a "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: 1) a user requested Leave, 2) a timeout of a following: 1) a user requested Leave, 2) a timeout of a
multicast state or 3) a re-authentication failure. A NSP multicast state or 3) a re-authentication failure. A NSP
may also record an accounting stop due to network may also record an accounting stop due to network
availability reasons such as failure. The NSP logs the availability reasons such as failure. The NSP logs 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 diagnostics and therefore could serve useful in for finer diagnostics and therefore could serve useful in
billing discrepancies, and provide for a better estimation billing discrepancies, and provide for a better estimation
of the time-span that content was multicasted, in the event of the time-span that content was multicast, in the event
that users disconnect without sending leave messages. that users disconnect without sending leave messages.
There are two levels of accounting report messaging. There are two levels of accounting report messaging.
Messages in Accounting level 1 include a channel identifier, Messages in Accounting level 1 include a channel identifier,
a user identifier, and the accounting start and stop time a user identifier, and the accounting start and stop time
information. Accounting level 2 includes all information of information. Accounting level 2 includes all information of
Level 1, plus traffic volume information. Level 1, plus traffic volume information.
QoS class is an optional item for each accounting level. QoS class is an optional item for each accounting level.
Whether to send, and at what interval to send intermittent Whether to send, and at what interval to send intermittent
skipping to change at page 12, line 51 skipping to change at page 14, line 5
may also agree to include additional option information in may also agree to include 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 either configured statically or can be CP may be either configured statically or can be
dynamically requested by the CP in its response to the dynamically requested by the CP in its response to the
Access-Request relayed by the NSP to the CP. The Access-Request relayed by the NSP to 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
Multicasting July, 2008
In case of very fast channel changes, the amount of items In case of very fast channel changes, the amount of items
logged by the NSP could become high. In order to reduce logged by the NSP could become high. In order to reduce
the number of report messages sent to the CP, the NSP can the number of report messages sent to the CP, the NSP can
consolidate multiple sets of accounting information inside consolidate multiple sets of accounting information inside
a single accounting report message. [4] a single accounting report message. [I-D.ancp-framework]
4.4 Access Control and CP selection by NSP 4.4 Access Control and CP selection by NSP
When a NSP receives an access request from a user, the NSP When a NSP receives an access request from a user, the NSP
determines to which CP the request is to be directed. The determines to which CP the request is to be directed. The
NSP may select a CP based on CP-assigned userID with CP NSP may select a CP based on CP-assigned userID with CP
domain name or channel identifier (S,G). The user should domain name or channel identifier (S,G). The user should
include in the request sufficient information for CP include in the request sufficient information for CP
selection. selection.
4.5 Admission Control Information by NSP 4.5 Admission Control Information by NSP
After authorizing a user request, the NSP may have further After authorizing a user request, the NSP may have further
conditions for determining its admission control decision. conditions for determining its admission control decision.
The NSP receives traffic parameters (such as QoS class, The NSP receives parameters (such as QoS class, required
required bandwidth, burst-size, etc.) of a multicast bandwidth, burst-size, etc.) of multicast traffic. Such
channel. Such parameters serve as information to be parameters serve as information to be considered in the
considered in the admission control decision. The traffic admission control decision. The traffic parameters can be
parameters can be communicated as follows: communicated as follows:
- A CP may notify a mapping between the channel - A CP may notify a mapping between the channel
identifier (S,G) and traffic parameters in the Response identifier (S,G) and traffic parameters in the Response
message when the CP authorizes an access request. Such message when the CP authorizes an access request. Such
parameters may include required bandwidth, burst-size, QoS parameters may include required bandwidth, burst-size, QoS
class downgrade policy, etc. class downgrade policy, etc.
- A user may indicate in the Request willingness to - A user may indicate in the Request willingness to
accept QoS class downgrade to best-effort streaming. accept QoS class downgrade to best-effort streaming.
- The NSP may maintain a mapping between channel - The NSP may maintain a mapping between channel
identifier (S,G) and traffic parameters in advance, for identifier (S,G) and traffic parameters in advance, for
example pre-configured by agreement between the CP and NSP example pre-configured by agreement between the CP and NSP
on a per channel basis. on a per channel (S,G) basis.
The ultimate admission decision is made by the NSP based on The ultimate admission decision is made by the NSP based on
required traffic parameters of the requested, and available required traffic parameters of the requested, and available
resources. In a case that it cannot guarantee the required resources. In a case that it cannot guarantee the required
network resources for the requested channel, streaming the network resources for the requested multicast traffic,
requested channel as best-effort traffic is optional. streaming the requested multicast traffic as best-effort is
The user may indicate in his/her Access Request whether optional. The user may indicate in his/her Access
he/she will accept best-effort grade streaming if Request whether he/she will accept best-effort grade
guaranteed class is not available. The CP's preference for streaming if guaranteed class is not available. The CP's
accepting downgrading to best-effort streaming may be preference for accepting downgrading to best-effort
either configured statically or can be dynamically streaming may be either configured statically or can be
requested by the CP in its response to the Access-Request dynamically requested by the CP in its response to the
relayed by the NSP to the CP. In the case that it cannot
offered a guaranteed QoS stream, the NSP may decide to Internet Draft AAA and Admission Control Framework for
either to decline admission or to stream the requested Multicasting July, 2008
channel as best-effort traffic. The NSP should not stream
best-effort traffic if either the user or CP has indicated Access-Request relayed by the NSP to the CP. In the case
against best-effort provision. 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 unicast usage, such as VoIP or unicast resources for unicast usage, such as VoIP or unicast
streaming, and multicast usage. Alternatively, it may streaming, and multicast usage. Alternatively, it may
manage network resources separately for unicast and manage network resources separately for unicast and
multicast usage. In either ease, AAA and admission control multicast usage. In either ease, AAA and admission 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
skipping to change at page 14, line 38 skipping to change at page 15, line 45
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 the NSP and the CP. The AAA proxy would store between the NSP and the CP. The AAA proxy would store
information about permissions of a specific user to receive information about permissions of a specific user to receive
multicast data from specified channel(s) up to specified multicast data from 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 conditions from a CP in advance and authorization conditions from a CP in advance and
statically hold them, or a CP may send them dynamically in statically hold them, or a CP may send them dynamically in
the Response message. In either case, the user has the Response message. In either case, the user has
permission to receive multicast channel 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 the permissions for a user for specific or change the permissions for a user for specific group(s)
channel(s). or channel(s).
When a user is receiving multicast content and the When a user is receiving multicast traffic while the
permission is about to expire, the NSP may send a permission is about to expire, the NSP may send a
notification to the user client that his session is about notification to the user client that his session is about
to expire, and that he will need to reauthenticate. In such to expire, and that he will need to re-authenticate. In
a case, the user will have to send the Access-Request. In such a case, the user will have to send the Access-Request.
the case that the user still has permission to the content, In the case that the user still has permission to the
they should be able to continue to receive the content
without interruption. Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008
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 channel and record accounting stop. multicast traffic and record accounting stop.
5. Network Connection Model and Functional Components 5. Network Connection Model and Functional Components
Section 3.1 introduces the high-level AAA framework for Section 3.1 introduced the high-level AAA framework for
multicasting. This section provides more detail on the multicasting. This section provides more detail on the
network connection model and constituent functional network connection model and constituent functional
components. components.
5.1 Basic Connection Model 5.1 Basic Connection Model
+------------------------------+
| receiver |
| |
+------------------------------+
| ^ Response
| Request |
V |
+------------------------------+
| NSP's network |
| |
+------------------------------+
| ^ Response
| Request | (Success)
v |
+------------------------------+
| CP's network |
| |
+------------------------------+
Figure 2: Basic Connection Model
In the simple case represented in Figure 1 the NSP is the In the simple case represented in Figure 1 the NSP is the
sole entity providing network resources including network sole entity providing network resources including network
access to the User. First a user that requests content access to the multicast receiver. First a receiver sends a
sends an Access request to an NSP which then forwards it on request for multicast (e.g. an IGMP Report message) to an
to the appropriate CP for Authentication and Authorization NSP which may then forward a mAAA request towards the
purposes. The CP responds with either "success" or appropriate CP for authentication and authorization
"failure". If "success", the NSP may forward a success purposes. The receiver gets information about a given
response and stream multicast data to the user. 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 the user selects the NSP to which to send its Internet Draft AAA and Admission Control Framework for
content request. Based on this request the NSP selects an Multicasting July, 2008
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 In this model the receiver selects the NSP to which the
relationship between NSP and CP can be 1:1, 1:N or M:N. Join request will be sent. Based on this request the NSP
Users may connect to multiple networks, and networks have selects an appropriate CP to which it forwards the
multiple users. corresponding mAAA request. The CP responds to the NSP's m
AAA request: it may not respond to another NSP in regards
to the request.
In this model, as described in section 4.1, the
relationship between NSP and CP can be one-to-one, one-to-
many or many-to-many. Receivers may connect to multiple
networks.
5.2 Constituent Logical Functional Components of the fully 5.2 Constituent Logical Functional Components of the fully
enabled AAA Framework enabled AAA Framework
Requirements for "fully AAA and QoS enabled" IP Requirements for "fully AAA and QoS enabled" IP
multicasting networks were defined in MACCNT-REQ-draft. To multicasting networks were defined in MACCNT-REQ-draft. To
allow for levels of enablement, this memo defines two allow for levels of enablement, this memo defines two
models within the framework: "AAA enabled" multicasting and models within the framework: "AAA enabled" multicasting and
"Fully enabled AAA" multicasting which means "AAA enabled" "Fully enabled AAA" multicasting which means "AAA enabled"
with added admission control functions. with added admission control functions.
Section 3.1 introduces the high-level AAA framework for Section 3.1 introduces the high-level AAA framework for
multicasting. Below is a diagram of a AAA enabled multicasting. Below is a diagram of a AAA enabled
multicasting network with AAA, including the logical multicasting network with AAA, including the logical
components within the various entities. components within the various entities.
AAA enabled framework (basic model) Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008
+-------------------------------+ +-------------------------------+
| user | | user |
|+- - - - - - - - - - - - - - -+| |+- - - - - - - - - - - - - - -+|
|| CPE || || CPE ||
|| || || ||
|+- - - - - | - - - - - - - - -+| |+- - - - - | - - - - - - - - -+|
+-----------|-------------------+ +-----------|-------------------+
| |
-------|------ IFa -------|------ IFa
| |
skipping to change at page 16, line 39 skipping to change at page 18, line 41
||+- - - - - - - + | | ||+- - - - - - - + | |
+-----------------------|--------+ +-----------------------|--------+
| |
-------|------ IFc -------|------ IFc
| |
+-----------------------|-------+ +-----------------------|-------+
| CP +---------+ | | CP +---------+ |
| | CP-AAA | | | | CP-AAA | |
| +---------+ | | +---------+ |
+-------------------------------+ +-------------------------------+
Figure 2 Figure 3: AAA enabled framework (basic model)
The user entity includes the CPE (Customer Premise The user entity includes the CPE (Customer Premise
Equipment) which includes the user host(s) and optionally a Equipment) which connects the receiver (s).
multicast proxy (not shown in the Figure 2.)
The NSP (Network Service Provider) in the basic model The NSP (Network Service Provider) in the basic model
includes the transport system and a logical element for includes the transport system and a logical element for
multicast AAA functionality. The transport system is multicast AAA functionality. The TS (transport system) is
comprised of the access node and NAS (network access comprised of the access node and NAS (Network Access
server.) An AN may be connected directory to mAAA or a NAS Server) An AN (Access Node) may be connected directly to
relays AAA information between an AN and a mAAA mAAA or a NAS relays AAA information between an AN and a
Descriptions of AN and its interfaces are out of scope for mAAA. Descriptions of AN and its interfaces are out of the
this memo. The multicast AAA function may be provided by a scope for this memo. The multicast AAA function may be
multicast AAA server (mAAA) which may include the function provided by a mAAA which may include the function that
by which the access policy is downloaded to the NAS
(conditional access policy control function.) The interface Internet Draft AAA and Admission Control Framework for
between mAAA and the NAS is labeled IFb in Figure 2. Over Multicasting July, 2008
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.
downloads Join access control lists to the NAS (this
function is referred to conditional access policy control
function.)
Interface between mAAA and NAS
The interface between mAAA and the NAS is labeled IFb in
Figure 2. Over IFb the NAS sends an access request to the
NSP-mAAA and the mAAA replies. The mAAA may push
conditional access policy to the NAS.
CP-AAA
The content provider may have its own AAA server which has The content provider may have its own AAA server which has
the authority over access policy for its contents. the authority over access policy for its contents.
Interface between user and NSP
The interface between the user and the NSP is labeled IFa The interface between the user and the NSP is labeled IFa
in Figure 2. Over IFa the user makes a multicasting in Figure 3. Over IFa the user makes a multicasting
request to the NSP. The NSP may in reply send multicast request to the NSP. The NSP may in return forward
traffic depending on the NSP and CP's policy decisions. multicast traffic depending on the NSP and CP's policy
decisions.
Interface between NSP and CP
The interface between the NSP and CP is labeled IFc. Over The interface between the NSP and CP is labeled IFc. Over
IFc the NSP requests to the CP-AAA for access to contents IFc the NSP requests to the CP-AAA for access to contents
and the CP replies. CP may also send conditional access and the CP replies. CP may also send conditional access
policy over this interface for AAA-proxying. policy over this interface for AAA-proxying.
Fully enabled framework Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008
+-------------------------------+ +-------------------------------+
| user | | user |
|+- - - - - - - - - - - - - - -+| |+- - - - - - - - - - - - - - -+|
|| CPE || || CPE ||
|| || || ||
|+- - - - - | - - - - - - - - -+| |+- - - - - | - - - - - - - - -+|
+-----------|-------------------+ +-----------|-------------------+
| |
-------|------ IFa -------|------ IFa
| |
+-----------|-----------------------+ +-----------|-----------------------+
|+- - - - - |- - _+ + - - - - - + | |+- - - - - |- - _+ + - - - - - + |
||TS | | | | | | || | | | | | |
| +------|-+ | +--------+ | | +------|-+ | +--------+ |
|| | AN | | | | | MACF || | || | AN | | | | | MACF || |
| | | | | | | | | | | | | |
|| +------|-+ | | | +---|----+| | || +------|-+ | | | +---|----+| |
| | | | | | | | | | | |
| | | | IFd----- | | | | | | IFd----- | |
| | | IFb | | | | | | IFb | | |
|| +------|---+ | | | +---|----+| | || +------|---+ | | | +---|----+| |
| | |---|---| mAAA | | | | |---|---| mAAA | |
|| | NAS | | | | |(MACF *)|| | * optional || | NAS | | | | |(MACF *)|| | * optional
skipping to change at page 18, line 40 skipping to change at page 20, line 42
||+- - - - - - - -+ - - |- - - - -+ | ||+- - - - - - - -+ - - |- - - - -+ |
+-----------------------|-----------+ +-----------------------|-----------+
| |
-------|------ IFc -------|------ IFc
| |
+-----------------------|-------+ +-----------------------|-------+
| CP +---------+ | | CP +---------+ |
| | CP-AAA | | | | CP-AAA | |
| +---------+ | | +---------+ |
+-------------------------------+ +-------------------------------+
Figure 3
Figure 4: Fully enabled framework
In the fully enabled model the NSP also includes a In the fully enabled model the NSP also includes a
component that provides network resource management (e.g. component that provides network resource management (e.g.
QoS management), as described in section 3.4, "Network QoS management), as described in section 3.4, "Network
Resource Management by NSP". In the fully enabled model Resource Management by NSP". In the fully enabled model
(Figure 3) resource management and admission control is (Figure 3) resource management and admission control is
provided by MACF (multicast admission control function.) provided by MACF (Multicast Admission Control Function).
This means that Before replying to the user's multicast This means that, before replying to the user's multicast
request the mAAA queries the MACF for a network resource request, the mAAA queries the MACF for a network resource
access decision over the interface IFd. The MACF is access decision over the interface IFd. The MACF is
responsible for allocating network resources for multicast responsible for allocating network resources for forwarding
traffic. So that MACF has the necessary network resource multicast traffic. MACF also receives Leave information
availability information, NAS notifies MACF via mAAA of the from NAS so that MACF releases corresponding reserved
stopping of multicast traffic. resources.
Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008
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 is possible that partially enabled versions of so that it is possible that partially enabled versions of
the models are supported. A AAA-enabled version provides the models are supported. A AAA-enabled version provides
AAA functionality without Network Resource management. A AAA functionality without Network Resource management. A
Network-Resource-Management-enabled (QoS-enabled) version Network-Resource-Management-enabled (QoS-enabled) version
provides Network Resource management without AAA provides Network Resource management without AAA
functionality. Similarly, the possibility of one or more functionality. Similarly, the possibility of one or more
layers of transit provision between an NSP and CP is in the layers of transit provision between an NSP and CP is in the
interest of 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
Refer to section 3.3. Also the user information related to The user information related to authentication with the CP
authentication with the CP must be protected in some way. and the information related to user accounting shared
between the NSP and the CP must be protected in some way.
Otherwise, this memo does not raise any new security issues Otherwise, this memo does not raise any new security issues
which are not already addressed by the original protocols. which are not already addressed by the original protocols.
Enhancement of multicast access control capabilities should Enhancement of multicast access control 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 meet the requirements. Further work should be standards to meet the requirements. Further work should be
done to specify the interfaces between the user and NSP, done to specify the interfaces between the user and NSP,
NAS and mAAA, mAAA and MACF and NSP-mAAA and CP-AAA NAS and mAAA, mAAA and MACF and NSP-mAAA and CP-AAA
(presented in 5.2.) (presented in 5.2.)
Normative References Normative References
[1] Hayashi, et. al., "Requirements for Multicast AAA [I-D.mboned-maccnt-req]
Hayashi, et. al., "Requirements for Multicast AAA
coordinated between Content Provider(s) and Network coordinated between Content Provider(s) and Network
Service Provider(s)", draft-ietf-mboned-maccnt-req- Service Provider(s)", draft-ietf-mboned-maccnt-req-
05.txt, September 2007, Work in Progress. 06.txt, June 2008, Work in Progress.
[2] RFC-3810, Vida, R. and L. Costa, "Multicast Listener [I-D.ancp-framework]
Discovery Version 2 (MLDv2) for IPv6", June 2004. Ooghe, et. al, "Framework and Requirements for an
Access Node Control Mechanism in Broadband Multi-
[3] RFC-3376, Cain B., et.al., "Internet Group Management Internet Draft AAA and Admission Control Framework for
Protocol, Version 3", October 2002. Multicasting July, 2008
[4] Ooghe, et. al, "Framework and Requirements for an Service Networks", draft-ietf-ancp-framework-04.txt,
Access Node Control Mechanism in Broadband Multi- November 2007, Work in Progress.
Service Networks", draft-ietf-ancp-framework-05.txt,
February 2008, Work in Progress.
Authors' Addresses Authors' Addresses
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
skipping to change at page 20, line 33 skipping to change at page 22, line 31
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, 35069 Rennes Cedex, France
Phone: +33 2 99 87 63 31 Phone: +33 2 99 87 61 92
Email: christian.jacquenet@francetelecom.com Email: christian.jacquenet@orange-ftgroup.com
Tsunemasa Hayashi Tsunemasa Hayashi
NTT Network Innovation Laboratories NTT Network Innovation Laboratories
1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847
Japan Japan
Phone: +81 46 859 8790 Phone: +81 46 859 8790
Email: tsunemasa@gmail.com Email: tsunemasa@gmail.com
Haixiang He Haixiang He
Nortel Nortel
600 Technology Park Drive 600 Technology Park Drive
Billerica, MA 01801, USA Billerica, MA 01801, USA
Phone: +1 978 288 7482 Phone: +1 978 288 7482
Email: haixiang@nortel.com Email: haixiang@nortel.com
Comments Comments
Comments are solicited and should be addressed to the Comments are solicited and should be addressed to the
mboned working group's mailing list at mboned working group's mailing list at
mboned@lists.uoregon.edu_and/or the authors. mboned@lists.uoregon.edu_and/or the authors.
Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and This document is subject to the rights, licenses and
restrictions contained in BCP 78, and except as set forth restrictions contained in BCP 78, and except as set forth
therein, the authors retain all their rights. therein, the authors retain all their rights.
This document and the information contained herein are This document and the information contained herein are
provided on an "AS IS" basis and THE CONTRIBUTOR, THE provided on an "AS IS" basis and THE CONTRIBUTOR, THE
skipping to change at page 22, line 51 skipping to change at page 23, line 54
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications, attention any copyrights, patents or patent applications,
or other proprietary rights that may cover technology that or other proprietary rights that may cover technology that
may be required to implement this standard. Please may be required to implement this standard. Please
address the information to the IETF at ietf-ipr@ietf.org. address the information to the IETF at ietf-ipr@ietf.org.
Expiration Expiration
This Internet-Draft will expire on August 22, 2008. This Internet-Draft will expire on January 3, 2009.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided Funding for the RFC Editor function is currently provided
by the Internet Society. by the Internet Society.
 End of changes. 97 change blocks. 
303 lines changed or deleted 433 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/