draft-ietf-mboned-multiaaa-framework-07.txt   draft-ietf-mboned-multiaaa-framework-08.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: Informational Hiroshi Ohta, NTT
Informational Expires: August 1, 2009 Christian Jacquenet, France Telecom
Expires: January Christian Jacquenet, France Telecom
3, 2009
Tsunemasa Hayashi, NTT Tsunemasa Hayashi, NTT
Haixiang He, Nortel Networks Haixiang He, Nortel Networks
July 1, 2008 January 28, 2009
AAA and Admission Control Framework for Multicasting AAA and Admission Control Framework for Multicasting
<draft-ietf-mboned-multiaaa-framework-07.txt> <draft-ietf-mboned-multiaaa-framework-08.txt>
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance
By submitting this Internet-Draft, each author represents with the provisions of BCP 78 and BCP 79.
that any applicable patent or other IPR claims of which he
or she is aware have been or will be disclosed, and any of
which he or she becomes aware will be disclosed, in
accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by six months and may be updated, replaced, or obsoleted by
other documents at any time. It is inappropriate to use other documents at any time. It is inappropriate to use
Internet-Drafts as reference material or to cite them other Internet-Drafts as reference material or to cite them other
than as "work in progress." 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 http://www.ietf.org/shadow.html. accessed at http://www.ietf.org/shadow.html.
Internet Draft AAA and Admission Control Framework for This Internet-Draft will expire on August 1, 2009.
Multicasting July, 2008
This Internet-Draft will expire on January 3, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). This document is Copyright (c) 2009 IETF Trust and the persons identified as the
subject to the rights, licenses and restrictions contained document authors. All rights reserved.
in BCP 78, and except as set forth therein, the authors
retain all their rights. Internet Draft AAA and Admission Control Framework for
Multicasting January, 2009
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
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 customers are fully entitled to access the potential customers are fully entitled to access the
corresponding contents. There is indeed a need for service corresponding contents. There is indeed a need for service
and content providers to identify users (if not and content providers to identify users (if not
authenticate, especially within the context of enforcing authenticate, especially within the context of enforcing
electronic payment schemes) and to retrieve statistical electronic payment schemes) and to retrieve statistical
skipping to change at page 3, line 5 skipping to change at page 3, line 5
and Accounting (AAA) capabilities that could be activated and Accounting (AAA) capabilities that could be activated
within the context of the deployment and the operation of within the context of the deployment and the operation of
IP multicast-based services. This framework addresses the IP multicast-based services. This framework addresses the
requirements presented in "Requirements for Accounting, requirements presented in "Requirements for Accounting,
Authentication and Authorization in Well Managed IP Authentication and Authorization in Well Managed IP
Multicasting Services" [I-D.mboned-maccnt-req]. The memo Multicasting Services" [I-D.mboned-maccnt-req]. The memo
provides a basic AAA enabled model as well as an extended provides a basic AAA enabled model as well as an extended
fully enabled model with resource and admission control fully enabled model with resource and admission control
coordination. coordination.
Multicasting January, 2009
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 9 4. FRAMEWORK AND ROLES OF ENTITIES...............................9
4.1 "AAA FRAMEWORK IN MULTICAST-ENABLED ENVIRONMENTS 9 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 11 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.3 A SINGLE CP IS CONNECTED TO MULTIPLE NSPS.................11
4.1.4 A SINGLE CP IS CONNECTED TO SINGLE NSP 11 4.1.4 A SINGLE CP IS CONNECTED TO SINGLE NSP....................11
4.2 USER ID 12 4.2 USER ID.....................................................12
4.2.1 CP-ASSIGNED USER ID 12 4.2.1 CP-ASSIGNED USER ID.......................................12
4.2.2 NSP-ASSIGNED USER ID 12 4.2.2 NSP-ASSIGNED USER ID......................................12
4.3 ACCOUNTING 13 4.3 ACCOUNTING..................................................13
4.4 ACCESS CONTROL AND CP SELECTION BY NSP 14 4.4 ACCESS CONTROL AND CP SELECTION BY NSP......................14
4.5 ADMISSION CONTROL INFORMATION BY NSP 14 4.5 ADMISSION CONTROL INFORMATION BY NSP........................14
4.6 ACCESS CONTROL AND DISTINGUISHING OF USERS BY CP 15 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 Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008 Multicasting January, 2009
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
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 one-to-many communication schemes of any kind, such as one-to-many
(case of TV broadcasting services for example) or many-to- (case of TV broadcasting services for example) or many-to-
many (case of videoconferencing services, for example). many (case of videoconferencing services, for example).
skipping to change at page 5, line 6 skipping to change at page 5, line 6
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 Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008 Multicasting January, 2009
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.
skipping to change at page 6, line 6 skipping to change at page 6, line 6
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 Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008 Multicasting January, 2009
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.
skipping to change at page 7, line 6 skipping to change at page 7, line 6
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 Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008 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
skipping to change at page 8, line 6 skipping to change at page 8, line 6
provision roles are divided between separate entities. provision roles are divided between separate entities.
Commonly, Content Providers (CP) do not build and maintain Commonly, Content Providers (CP) do not build and maintain
their own multicast network infrastructure as this is not their own multicast network infrastructure as this is not
their primary business area. CP often purchase transport their primary business area. CP often purchase transport
and management services from network service providers and management services from network service 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- make their business in providing content. [I-D.mboned-
maccnt-req] provides more detail of the multiple versus maccnt-req] provides more detail of the multiple versus
Internet Draft AAA and Admission Control Framework for Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008 Multicasting January, 2009
single-entity Content Delivery Service (CDS) network single-entity Content Delivery Service (CDS) network
models. models.
In the usage model where a single NSP provides multicast In the usage model where a single NSP provides multicast
services to multiple CPs, the following general services to multiple CPs, the following general
requirements from [I-D.mboned-maccnt-req] apply: 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
skipping to change at page 9, line 6 skipping to change at page 9, line 6
CP to make the above two possible CP to make the above two possible
When the NSP and CP are the same single entity then the When the NSP and CP are the same single entity then the
general 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 Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008 Multicasting January, 2009
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 10, line 6 skipping to change at page 10, line 6
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 Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008 Multicasting January, 2009
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.
skipping to change at page 11, line 6 skipping to change at page 11, line 6
A CP receives an inquiry from the NSP. The CP authenticates A CP receives an inquiry from the NSP. The CP authenticates
the NSP's identity and makes an authorization decision the NSP's identity and makes an authorization decision
regarding the user's eligibility to access the requested regarding the user's eligibility to access the requested
contents. The CP is responsible for the authentication contents. The CP is responsible for the authentication
and authorization of users so that they can access the and authorization of users so that they can access the
content managed by the CP. The CP notifies the NSP content managed by the CP. The CP notifies the NSP
accordingly. When the CP cannot (e.g. error or resource accordingly. When the CP cannot (e.g. error or resource
issues) or decides not (e.g. policy issues) to deliver issues) or decides not (e.g. policy issues) to deliver
Internet Draft AAA and Admission Control Framework for Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008 Multicasting January, 2009
content, the CP is responsible for notifying the NSP about content, the CP is responsible for notifying the NSP about
the reason. It is up to the NSP to relay or translate the the reason. It is up to the NSP to relay or translate the
reasons for rejection to the user. 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 described in 4.7 for this case. in NSP' is described in 4.7 for this case.
As defined in [I-D.mboned-maccnt-req], the CP may require As defined in [I-D.mboned-maccnt-req], the CP may require
the retrieval of accounting information related to the the retrieval of accounting information related to the
skipping to change at page 12, line 6 skipping to change at page 12, line 6
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 a NSP and CP in this scenario. The user does not select a NSP and CP in this scenario.
Requests for multicast sent by the user to a selected NSP Requests for multicast sent by the user to a selected NSP
Internet Draft AAA and Admission Control Framework for Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008 Multicasting January, 2009
should include enough information not only for should include enough information not only for
authentication by the CP but also for admission control by authentication by the CP but also for admission control by
the NSP. 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.
skipping to change at page 13, line 6 skipping to change at page 13, line 6
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
requests for multicast 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 inform 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 Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008 Multicasting January, 2009
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
skipping to change at page 14, line 6 skipping to change at page 14, line 6
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 Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008 Multicasting January, 2009
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. [I-D.ancp-framework] 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
skipping to change at page 15, line 6 skipping to change at page 15, line 6
network resources for the requested multicast traffic, network resources for the requested multicast traffic,
streaming the requested multicast traffic as best-effort is streaming the requested multicast traffic as best-effort is
optional. The user may indicate in his/her Access optional. The user may indicate in his/her Access
Request whether he/she will accept best-effort grade Request whether he/she will accept best-effort grade
streaming if guaranteed class is not available. The CP's streaming if guaranteed class is not available. The CP's
preference for accepting downgrading to best-effort preference for accepting downgrading to best-effort
streaming may be either configured statically or can be streaming 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
Internet Draft AAA and Admission Control Framework for Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008 Multicasting January, 2009
Access-Request relayed by the NSP to the CP. In the case Access-Request relayed by the NSP to the CP. In the case
that it cannot be offered a guaranteed QoS stream, the NSP that it cannot be offered a guaranteed QoS stream, the NSP
may decide either to decline admission or to stream the may decide either to decline admission or to stream the
requested multicast traffic as best-effort. The NSP should requested multicast traffic as best-effort. The NSP should
not stream best-effort traffic if either the user or CP has not stream best-effort traffic if either the user or CP has
indicated against best-effort provision. 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
skipping to change at page 16, line 6 skipping to change at page 16, line 6
or channel(s). or channel(s).
When a user is receiving multicast traffic while 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 re-authenticate. In to expire, and that he will need to re-authenticate. In
such a case, the user will have to send the Access-Request. such a case, the user will have to send the Access-Request.
In the case that the user still has permission to the In the case that the user still has permission to the
Internet Draft AAA and Admission Control Framework for Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008 Multicasting January, 2009
content, they should be able to continue to receive the content, they should be able to continue to receive the
multicast traffic without interruption. multicast traffic without interruption.
When re-authentication fails, the NSP should stop the When re-authentication fails, the NSP should stop the
multicast traffic 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 introduced the high-level AAA framework for Section 3.1 introduced the high-level AAA framework for
skipping to change at page 17, line 6 skipping to change at page 17, line 6
NSP which may then forward a mAAA request towards the NSP which may then forward a mAAA request towards the
appropriate CP for authentication and authorization appropriate CP for authentication and authorization
purposes. The receiver gets information about a given purposes. The receiver gets information about a given
multicast group (*,G) or channel (S,G) corresponding to the multicast group (*,G) or channel (S,G) corresponding to the
content beforehand for generating the request. The CP content beforehand for generating the request. The CP
responds with either "success" or "failure". If "success", responds with either "success" or "failure". If "success",
the NSP grants access to the receiver and forwards the NSP grants access to the receiver and forwards
multicast traffic accordingly. multicast traffic accordingly.
Internet Draft AAA and Admission Control Framework for Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008 Multicasting January, 2009
In this model the receiver selects the NSP to which the In this model the receiver selects the NSP to which the
Join request will be sent. Based on this request the NSP Join request will be sent. Based on this request the NSP
selects an appropriate CP to which it forwards the selects an appropriate CP to which it forwards the
corresponding mAAA request. The CP responds to the NSP's m corresponding mAAA request. The CP responds to the NSP's m
AAA request: it may not respond to another NSP in regards AAA request: it may not respond to another NSP in regards
to the request. to the request.
In this model, as described in section 4.1, the In this model, as described in section 4.1, the
relationship between NSP and CP can be one-to-one, one-to- relationship between NSP and CP can be one-to-one, one-to-
skipping to change at page 18, line 6 skipping to change at page 18, line 6
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.
Internet Draft AAA and Admission Control Framework for Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008 Multicasting January, 2009
+-------------------------------+ +-------------------------------+
| user | | user |
|+- - - - - - - - - - - - - - -+| |+- - - - - - - - - - - - - - -+|
|| CPE || || CPE ||
|| || || ||
|+- - - - - | - - - - - - - - -+| |+- - - - - | - - - - - - - - -+|
+-----------|-------------------+ +-----------|-------------------+
| |
-------|------ IFa -------|------ IFa
skipping to change at page 19, line 6 skipping to change at page 19, line 6
includes the transport system and a logical element for includes the transport system and a logical element for
multicast AAA functionality. The TS (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 (Access Node) may be connected directly to Server) An AN (Access Node) may be connected directly to
mAAA or a NAS relays AAA information between an AN and a mAAA or a NAS relays AAA information between an AN and a
mAAA. Descriptions of AN and its interfaces are out of the mAAA. Descriptions of AN and its interfaces are out of the
scope for this memo. The multicast AAA function may be scope for this memo. The multicast AAA function may be
provided by a mAAA which may include the function that provided by a mAAA which may include the function that
Internet Draft AAA and Admission Control Framework for Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008 Multicasting January, 2009
downloads Join access control lists to the NAS (this downloads Join access control lists to the NAS (this
function is referred to conditional access policy control function is referred to conditional access policy control
function.) 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. Over IFb the NAS sends an access request to the Figure 2. Over IFb the NAS sends an access request to the
NSP-mAAA and the mAAA replies. The mAAA may push NSP-mAAA and the mAAA replies. The mAAA may push
skipping to change at page 20, line 6 skipping to change at page 20, line 6
multicast traffic depending on the NSP and CP's policy multicast traffic depending on the NSP and CP's policy
decisions. decisions.
Interface between NSP and CP 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.
Internet Draft AAA and Admission Control Framework for Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008 Multicasting January, 2009
+-------------------------------+ +-------------------------------+
| user | | user |
|+- - - - - - - - - - - - - - -+| |+- - - - - - - - - - - - - - -+|
|| CPE || || CPE ||
|| || || ||
|+- - - - - | - - - - - - - - -+| |+- - - - - | - - - - - - - - -+|
+-----------|-------------------+ +-----------|-------------------+
| |
-------|------ IFa -------|------ IFa
skipping to change at page 21, line 6 skipping to change at page 21, line 6
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 forwarding responsible for allocating network resources for forwarding
multicast traffic. MACF also receives Leave information multicast traffic. MACF also receives Leave information
from NAS so that MACF releases corresponding reserved from NAS so that MACF releases corresponding reserved
resources. resources.
Internet Draft AAA and Admission Control Framework for Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008 Multicasting January, 2009
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
skipping to change at page 21, line 48 skipping to change at page 21, line 48
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
[I-D.mboned-maccnt-req] [I-D.mboned-maccnt-req]
Hayashi, et. al., "Requirements for Multicast AAA 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-
06.txt, June 2008, Work in Progress. 07.txt, January 2009, Work in Progress.
[I-D.ancp-framework] [I-D.ancp-framework]
Ooghe, et. al, "Framework and Requirements for an Ooghe, et. al, "Framework and Requirements for an
Access Node Control Mechanism in Broadband Multi- Access Node Control Mechanism in Broadband Multi-
Internet Draft AAA and Admission Control Framework for Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008 Multicasting January, 2009
Service Networks", draft-ietf-ancp-framework-04.txt, Service Networks", draft-ietf-ancp-framework-07.txt,
November 2007, Work in Progress. November 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 22, line 47 skipping to change at line 997
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 are solicited and should be addressed to the
mboned working group's mailing list at
mboned@lists.uoregon.edu_and/or the authors.
Internet Draft AAA and Admission Control Framework for
Multicasting July, 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and
restrictions contained in BCP 78, and except as set forth
therein, the authors retain all their rights.
This document and the information contained herein are
provided on an "AS IS" basis and THE CONTRIBUTOR, THE
ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY),
THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE
USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS
OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR
A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope
of any Intellectual Property Rights or other rights that
might be claimed to pertain to the implementation or use
of the technology described in this document or the extent
to which any license under such rights might or might not
be available; nor does it represent that it has made any
independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and
any assurances of licenses to be made available, or the
result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by
implementers or users of this specification can be
obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications,
or other proprietary rights that may cover technology that
may be required to implement this standard. Please
address the information to the IETF at ietf-ipr@ietf.org.
Expiration
This Internet-Draft will expire on January 3, 2009.
Acknowledgement
Funding for the RFC Editor function is currently provided
by the Internet Society.
 End of changes. 31 change blocks. 
73 lines changed or deleted 70 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/