draft-ietf-mboned-multiaaa-framework-05.txt   draft-ietf-mboned-multiaaa-framework-06.txt 
Internet Draft Hiroaki Satou, NTT
Internet Draft AAA Framework for Multicasting November Intended Status: Hiroshi Ohta, NTT
2007 Informational
Expires: August Christian Jacquenet, France Telecom
Hiroaki Satou, NTT 22, 2008
Internet Draft Hiroshi Ohta, NTT
Expires: May 17, Christian Jacquenet, France Telecom
2008
Tsunemasa Hayashi, NTT Tsunemasa Hayashi, NTT
Haixiang He, Nortel Networks Haixiang He, Nortel Networks
November 19, 2007 February 25, 2007
AAA Framework for Multicasting AAA Framework for Multicasting
<draft-ietf-mboned-multiaaa-framework-05.txt> <draft-ietf-mboned-multiaaa-framework-06.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author By submitting this Internet-Draft, each author
represents that any applicable patent or other IPR represents that any applicable patent or other IPR
claims of which he or she is aware have been or will claims of which he or she is aware have been or will
be disclosed, and any of which he or she becomes be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section aware will be disclosed, in 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 Engineering Task Force (IETF), its areas, Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may and its working groups. Note that other groups may
also distribute working documents as Internet-Drafts. also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a Internet-Drafts are draft documents valid for a
maximum of six months and may be updated, replaced, maximum of six months and may be updated, replaced,
or obsoleted by other documents at any time. It is or obsoleted by other documents at any time. It is
inappropriate to use Internet-Drafts as reference inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in material or to cite them other 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 http://www.ietf.org/ietf/1id-abstracts.txt. at http://www.ietf.org/ietf/1id-abstracts.txt.
Internet Draft AAA Framework for Multicasting November
2007
The list of Internet-Draft Shadow Directories can be 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 May 17, 2008. This Internet-Draft will expire on August 22, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). This document Copyright (C) The IETF Trust (2008). This document
is subject to the rights, licenses and restrictions is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, contained in BCP 78, and except as set forth
the authors retain all their rights. therein, the authors retain all their rights.
Abstract Abstract
IP multicast-based services, such as TV broadcasting IP multicast-based services, such as TV broadcasting
or videoconferencing raise the issue of making sure or videoconferencing raise the issue of making sure
that potential customers are fully entitled to that potential customers are fully entitled to
access the corresponding contents. There is indeed a access the corresponding contents. There is indeed a
need for service and content providers to identify need for service and content providers to identify
(if not authenticate, especially within the context (if not authenticate, especially within the context
of enforcing electronic payment schemes) and to of enforcing electronic payment schemes) and to
invoice such customers in a reliable and efficient invoice such customers in a reliable and efficient
manner. This memo describes the framework for manner. This memo describes the framework for
specifying the Authorization, Authentication and specifying the Authorization, Authentication and
skipping to change at page 3, line 5 skipping to change at page 3, line 5
activated within the context of the deployment and activated within the context of the deployment and
the operation of IP multicast-based services. This the operation of IP multicast-based services. This
framework addresses the requirements presented in framework addresses the requirements presented in
draft-ietf-mboned-maccnt-req-04.txt, "Requirements draft-ietf-mboned-maccnt-req-04.txt, "Requirements
for Accounting, Authentication and Authorization in for Accounting, Authentication and Authorization in
Well Managed IP Multicasting Services". The memo Well Managed IP Multicasting Services". The memo
provides a basic AAA enabled model as well as an provides a basic AAA enabled model as well as an
extended fully enabled model with resource and extended fully enabled model with resource and
admission control coordination. admission control coordination.
STATUS OF THIS MEMO 1 Table of Contents
COPYRIGHT NOTICE 2 1. INTRODUCTION 4
ABSTRACT 2 1.1 PURPOSE AND BACKGROUND 4
1. INTRODUCTION 5 2. DEFINITIONS AND ABBREVIATIONS 5
1.1 PURPOSE AND BACKGROUND 5 2.1 DEFINITIONS 5
2. DEFINITIONS AND ABBREVIATIONS 6 2.2 ABBREVIATIONS 6
2.1 DEFINITIONS 6
2.2 ABBREVIATIONS 7
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 8
4.1 FRAMEWORK FOR MULTICAST AAA 8 4.1 "AAA FRAMEWORK IN MULTICAST-ENABLED ENVIRONMENTS 8
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 10
4.1.3 A SINGLE CP IS CONNECTED TO MULTIPLE NSPS 11 4.1.3 A SINGLE CP IS CONNECTED TO MULTIPLE NSPS 10
4.1.4 A SINGLE CP IS CONNECTED TO SINGLE NSP 11 4.1.4 A SINGLE CP IS CONNECTED TO SINGLE NSP 10
4.2 USER ID 11 4.2 USER ID 11
4.2.1 CP-ASSIGNED USER ID 12 4.2.1 CP-ASSIGNED USER ID 11
4.2.2 NSP-ASSIGNED USER ID 12 4.2.2 NSP-ASSIGNED USER ID 11
4.3 ACCOUNTING 12 4.3 ACCOUNTING 12
4.4 ACCESS CONTROL AND CP SELECTION BY NSP 13 4.4 ACCESS CONTROL AND CP SELECTION BY NSP 13
4.5 ADMISSION CONTROL INFORMATION BY NSP 13 4.5 ADMISSION CONTROL INFORMATION BY NSP 13
4.6 ACCESS CONTROL AND DISTINGUISHING OF USERS BY CP 14 4.6 ACCESS CONTROL AND DISTINGUISHING OF USERS BY CP 14
4.7 AAA PROXY IN NSP 14 4.7 AAA PROXY IN NSP 14
5.1 BASIC CONNECTION MODEL 14 5.1 BASIC CONNECTION MODEL 15
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 15
5.3 MODULARITY OF THE FRAMEWORK 19 5.3 MODULARITY OF THE FRAMEWORK 19
6. IANA CONSIDERATIONS 19 6. IANA CONSIDERATIONS 19
7. SECURITY CONSIDERATIONS 19 7. SECURITY CONSIDERATIONS 19
8. CONCLUSION 19 8. CONCLUSION 19
NORMATIVE REFERENCES 19
AUTHORS' ADDRESSES 20
COMMENTS 20
FULL COPYRIGHT STATEMENT 21
COPYRIGHT (C) THE IETF TRUST (2007). 21
INTELLECTUAL PROPERTY 21
EXPIRATION 21
ACKNOWLEDGEMENT 22
1. Introduction 1. 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 1-to-n (case of
TV broadcasting services for example) or n-to-p (case of TV broadcasting services for example) or n-to-p (case of
videoconferencing services, for example). 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 videoconferencing raise the issue of making sure that
or 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. corresponding contents. There is indeed a need for service
There is indeed a need for service and content providers to and content providers to identify (if not authenticate,
identify (if not authenticate, especially within the especially within the context of enforcing electronic
context of enforcing electronic payment schemes) and to payment schemes) and to invoice such customers in a
invoice such customers in a reliable and efficient manner. reliable and efficient manner. Solutions should consider a
Solutions should consider a wide range of possible content wide range of possible content delivery applications:
delivery applications: content delivered over the multicast content delivered over the multicast network may include
network may include video, audio, images, games, software video, audio, images, games, software and information such
and information such as financial data, etc. as financial data, etc.
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 Resource and high-quality multicast transport using a Multicast
Admission Control System (RACS) 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 draft-ietf-mboned-maccnt-req-05.txt,
"Requirements for Multicast AAA coordinated between Content "Requirements for Multicast AAA coordinated between Content
Provider(s) and Network Service Provider(s)" MACCNT-REQ- Provider(s) and Network Service Provider(s)" MACCNT-REQ-
draft describes the requirements in CDN services using IP draft describes the requirements in CDN services using IP
multicast[1]. The requirements are derived from: multicast[1]. The requirements are derived 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
skipping to change at page 6, line 18 skipping to change at page 5, line 38
Detailed requirements are presented in MACCNT-REQ-draft. Detailed requirements are presented in MACCNT-REQ-draft.
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 framework for specifying multicast-inferred AAA
specifying multicast-inferred AAA capabilities that can capabilities that can meet these requirements. This
meet these requirements. This framework is to provide a framework is to provide a basis for future work of
basis for future work of investigating the applicability of investigating the applicability of existing AAA protocols
existing AAA protocols to provide these AAA capabilities in to provide these AAA capabilities in IP multicast specific
IP multicast specific context and/or if deemed necessary, context and/or if deemed necessary, the refining or
the refining or defining of protocols to provide these defining of protocols to provide these capabilities.
capabilities.
2. Definitions and Abbreviations 2. Definitions and Abbreviations
2.1 Definitions 2.1 Definitions
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
skipping to change at page 7, line 28 skipping to change at page 6, line 47
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:
ACL: Access Control List ACL: Access Control List
AN: Access Node AN: Access Node
CAPCF: Conditional Access Policy Control Function
CDN: Content Delivery Network CDN: Content Delivery Network
CDS: Content Delivery Services CDS: Content Delivery Services
CP: Content Provider CP: Content Provider
CPE: Customer Premise Equipment CPE: Customer Premise Equipment
MACF: Multicast Admission Control Function MACF: Multicast Admission Control Function
NSP: Network Service Provider NSP: Network Service Provider
TS: Transport System TS: Transport System
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
skipping to change at page 8, line 42 skipping to change at page 8, line 9
-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 the general
requirements are as follows. 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
4. Framework and Roles of Entities4.1 Framework for multicast 4. Framework and Roles of Entities
AAA
4.1 "AAA Framework in Multicast-Enabled Environments
A general high-level framework can be represented as A general high-level framework can be represented as
follows. follows.
+------------------------------+ +------------------------------+
| user | | user |
| | | |
+------------------------------+ +------------------------------+
| Access ^ Response | Access ^ Response
| Request | | Request |
skipping to change at page 10, line 15 skipping to change at page 9, line 34
NSP. NSP.
When an NSP receives an Access-Request from a user, the NSP When an NSP receives an Access-Request from a user, the NSP
selects the appropriate CP for the received Access-Request selects the appropriate CP for the received Access-Request
and relays the content request. As the NSP is responsible and relays the content request. As the NSP is responsible
for managing its network resources, the NSP may perform for managing its network resources, the NSP may perform
admission control.The NSP will allow access to the network admission control.The NSP will allow access to the network
and contents conditional to both the CP's content and contents conditional to both the CP's content
authorization result and the NSPs network availability. authorization result and the NSPs network availability.
That is, the NSP starts multicast flow only when it has That is, the NSP starts multicast flow only when it has
both 1) received an ĎĎacceptíí response from the CP and 2) both 1) received an "accept" response from the CP and 2)
determined that the network resources (e.g. bandwidth) are determined that the network resources (e.g. bandwidth) are
sufficient to serve the multicast channel. When neither of sufficient to serve the multicast channel. When neither of
these conditions are met, the NSP does not start the these conditions are met, the NSP does not start the
requested multicast channel. When the NSP already knows requested multicast channel. 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 relay the
Access-Request to the CP. The NSP is also responsible for Access-Request to the CP. The NSP is also responsible for
relaying the Response message from the CP to the user relaying the Response message from the CP to the user
whether the user is eligible to receive content (in whether the user is eligible to receive content (in
response to the corresponding Access-Request from the user response to the corresponding Access-Request from the user
to the CP.) In cases that the NSP does not start multicast to the CP.) In cases that the NSP does not start
because of its own network issues (e.g. lack of network multicasting because of its own network issues (e.g. lack
resources or network failure), the NSP notifies the user of network resources or network failure), the NSP notifies
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 Access-Request relayed by the NSP. The CP
authenticates the NSPís identity and makes an authorization authenticates the NSP's identity and makes an authorization
decision regarding the NSPís eligibility to provide users decision regarding the NSP's eligibility to provide users
access to its contents. The CP is responsible for access to its contents. The CP is responsible for
Authentication and Authorization of users' access to Authentication and Authorization of users' access to
content that the CP manages. The CP hopes to collect content that the CP manages. The CP hopes to collect
accounting information related to the access of their accounting information related to the access of their
content. The CP responds to the NSP regarding the relayed content. The CP responds to the NSP regarding the relayed
Access-Request. When the CP cannot (e.g. error or Access-Request. When the CP cannot (e.g. error or
resource issues) or decides not (e.g. policy issues) to resource issues) or decides not (e.g. policy issues) to
deliver content, the CP is responsible for notifying the deliver content, the CP is responsible for notifying the
NSP of the reason. It is up to the NSP how to relay or NSP of the reason. It is up to the NSP how to relay or
translate the reasons for rejection to the user. translate the reasons for rejection to the user.
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 of channels from multiple CPs in this usage
case. In this case the user does not select an NSP. The case. In this case the user does not select an NSP. The
user selects a CP when the user requests content. The user selects a CP when the user requests content. The
content may be associated with (or managed by) the specific content may be associated with (or managed by) the specific
CP, when the user selects content, the CP is automatically CP, so that when the user selects content, the CP is
selected. automatically selected.
The user should send an Access-Request to the specific NSP The user should send an Access-Request to the specific NSP
with enough information not only for authentication by the with enough information not only for authentication by the
CP but also for CP selection and admission control by the CP but also for CP selection and admission control by the
NSP. 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
skipping to change at page 11, line 32 skipping to change at page 10, line 49
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 an Access-
Request from a user, NSP relays it to the CP without CP Request from a user, NSP relays it 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 In this case, a user subscribes to only one NSP and one CP.
CP. The user does not select NSP and CP in this scenario. The user does not select NSP and CP in this scenario. The
The user should send an Access-Request to the NSP with user should send an Access-Request to the NSP with enough
enough information not only for authentication by the CP information not only for authentication by the CP but also
but also for admission control by the NSP. 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 they may have for
various NSPs and CPs. The NSPs and CPs manage the user IDs various NSPs and CPs. The NSPs and CPs manage the user IDs
for their respective domains. A CP identifies a user by a for their respective domains. A CP identifies a user by a
user ID assigned by CP itself. A NSP identifies a user by a user ID assigned by the CP itself. A NSP identifies a user
user ID assigned by NSP itself. The user IDs are only by a user ID assigned by the NSP itself. The user IDs are
meaningful in the context of each domain. Users may hold only meaningful within the context of each domain. Users
multiple user IDs which have been separately assigned for may hold multiple user IDs which have been separately
each subscription they may have for various NSPs and CPs. assigned for each subscription they may have for various
NSPs and 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 a specific CP. A user than one CP-assigned user ID per specific CP. A user sends
sends an Access-Request to a NSP, the CP-assigned user ID an Access-Request to a NSP, the CP-assigned user ID should
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 relay the CP-
assigned user ID from the user to the CP. A NSP should not assigned user ID from the user to the CP. A NSP should not
send a CP-assigned user ID to any CP except the one which send a CP-assigned user ID to any CP except the one which
assigned it and should not relay it all if there is no assigned 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 sends an Access-Request to a NSP, the NSP-assigned user ID
may be indicated in it so that the NSP can identify the may be indicated in the request so that the NSP can
user. The NSP should not relay the NSP-assigned user ID to identify the user. The NSP should not relay the NSP-
the CP for security reasons. The NSP may identify the assigned user ID to the CP for security reasons. The NSP
multicast-access user by other methods than the NSP- may identify the multicast-access user by other methods
assigned userID, e.g. by the access port. than the NSP-assigned userID, e.g. by the access port.
The actual mapping rules for NSP-assigned user IDs with CP- The actual mapping rules for NSP-assigned user IDs with CP-
user 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 specific accounting issues for multicasting. There are some accounting issues specific to multicasting.
A (S,G) should be recorded as a channel identifier. The An (S,G) should be recorded as a channel identifier. The
last hop devices, such as a IGMP or MLD router and a IGMP last hop device, such as an IGMP or MLD router or an IGMP
or MLD proxy, notify a (S,G) to AAA function in the NSP. or MLD proxy, notifies the NSP's AAA function of the (S,G)
The (S,G) information should be notified to the CP as part channel identifier. The NSP should notify the CP of the
of the accounting log. (S,G) information in the accounting report messages.
A NSP records 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 Query-responded Join as the accounting start. not treat a "Join" response to a Query as the accounting
start.
A NSP records accounting stop triggered by not only user A NSP records an accounting stop triggered by any of the
requested Leave but also timeout of a multicast state or following: 1) a user requested Leave, 2) a timeout of a
re-authentication failure. A NSP may also record an multicast state or 3) a re-authentication failure. A NSP
accounting stop due to network availability reasons such as may also record an accounting stop due to network
failure. The NSP logs the reason for each accounting stop. availability reasons such as failure. The NSP logs the
reason for each accounting stop.
Also, intermittent logs between the join and leave would Intermittent logs between the join and leave would allow
allow for finer diagnostics and therefore could serve for finer diagnostics and therefore could serve useful in
useful in billing discrepancies, and provide for a finer billing discrepancies, and provide for a better estimation
estimation of the time spent for delivering the content in of the time-span that content was multicasted, in the event
the event that users disconnect without sending leave that users disconnect without sending leave messages.
messages.
There are two levels of accounting report messaging.
Messages in Accounting level 1 include a channel identifier,
a user identifier, and the accounting start and stop time
information. Accounting level 2 includes all information of
Level 1, plus traffic volume information.
QoS class is an optional item for each accounting level.
Whether to send, and at what interval to send intermittent
log information is optional for both levels. CP and NSPs
may also agree to include additional option information in
accounting messages of either level.
The level of account report messaging between the NSP and
CP may be either configured statically or can be
dynamically requested by the CP in its response to the
Access-Request relayed by the NSP to the CP. The
determination of the actual level of report messaging is
configured by the NSP at the NAS.
In case of very fast channel changes, the amount of items
logged by the NSP could become high. In order to reduce
the number of report messages sent to the CP, the NSP can
consolidate multiple sets of accounting information inside
a single accounting report message. [4]
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 needs to know traffic parameters of a multicast The NSP receives traffic parameters (such as QoS class,
channel for admission control. The traffic parameter required bandwidth, burst-size, etc.) of a multicast
information may be either indicated by the user or CP channel. Such parameters serve as information to be
within the access request and responses, or otherwise considered in the admission control decision. The traffic
shared between the NSP and CP outside the access-request parameters can be communicated as follows:
message mechanism:
- A user may declare traffic parameters for each
Access-Request.
- 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. message when the CP authorizes an access request. Such
parameters may include required bandwidth, burst-size, QoS
class downgrade policy, etc.
- A user may indicate in the Request willingness to
accept QoS class downgrade to best-effort streaming.
- The NSP may maintain a mapping between channel - 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 basis.
A NSPs admission control may manage integrated network The ultimate admission decision is made by the NSP based on
required traffic parameters of the requested, and available
resources. In a case that it cannot guarantee the required
network resources for the requested channel, streaming the
requested channel as best-effort traffic is optional.
The user may indicate in his/her Access Request whether
he/she will accept best-effort grade streaming if
guaranteed class is not available. The CP's preference for
accepting downgrading to best-effort streaming may be
either configured statically or can be dynamically
requested by the CP in its response to the Access-Request
relayed by the NSP to the CP. In the case that it cannot
offered a guaranteed QoS stream, the NSP may decide to
either to decline admission or to stream the requested
channel as best-effort traffic. 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
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 case, 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
depend on NSP policies and are out of the scope of this depend on NSP policies and are out of the scope of this
memo. memo.
4.6 Access Control and Distinguishing of Users by CP 4.6 Access Control and Distinguishing of Users by CP
The user ID and authentication information are forwarded The user ID and authentication information are forwarded
skipping to change at page 14, line 22 skipping to change at page 14, line 33
transparently by the NSP so that the CP can distinguish the transparently by the NSP so that the CP can distinguish the
user, as well as authenticate and authorize the request. user, as well as authenticate and authorize the request.
4.7 AAA proxy in NSP 4.7 AAA proxy in NSP
A NSP may act as AAA proxy of a CP based upon an agreement A NSP may act as AAA proxy of a CP based upon an agreement
between 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. The user has permission to receive the Response message. In either case, the user has
multicast channel at that time. The NSP starts the permission to receive multicast channel and therefore 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
channel(s). channel(s).
When a user is receiving multicast content and the When a user is receiving multicast content and 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 reauthenticate. In such
a case, the user will have to send the Access-Request. In a case, the user will have to send the Access-Request. In
skipping to change at page 14, line 41 skipping to change at page 15, line 4
channel(s). channel(s).
When a user is receiving multicast content and the When a user is receiving multicast content and 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 reauthenticate. In such
a case, the user will have to send the Access-Request. In a case, the user will have to send the Access-Request. In
the case that the user still has permission to the content, the case that the user still has permission to the content,
they should be able to continue to receive the content they should be able to continue to receive the content
without interruption. 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 channel 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 introduces the high-level AAA framework for
multicasting. This section provides more details 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
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 User. First a user that requests content
sends an Access request to an NSP which then forwards it on sends an Access request to an NSP which then forwards it on
to the appropriate CP for Authentication and Authorization to the appropriate CP for Authentication and Authorization
skipping to change at page 16, line 5 skipping to change at page 16, line 22
+-----------|-------------------+ +-----------|-------------------+
| |
-------|------ IFa -------|------ IFa
| |
+-----------|-------------------+ +-----------|-------------------+
| NSP | | | NSP | |
|+- - - - - |- -_+ | |+- - - - - |- -_+ |
||TS | | | ||TS | | |
| +------|-+ | | +------|-+ |
|| | AN | | | || | AN | | |
| | | | | | |---------+ |
|| +------|-+ | | || +------|-+ | | |
| | IFb | | | IFb | |
|| +------|-+ | | +---------+| || +------|-+ | | +---------+|
| | |----|-|mAAA || | | |----|-|mAAA ||
|| | NAS | | | |(MACF *) || * optional || | NAS | | | |(MACF *) || * optional
| +--------+ +---------+| | +--------+ +---------+|
||+- - - - - - - + | | ||+- - - - - - - + | |
+-----------------------|--------+ +-----------------------|--------+
| |
-------|------ IFc -------|------ IFc
| |
+-----------------------|-------+ +-----------------------|-------+
skipping to change at page 16, line 32 skipping to change at page 16, line 49
Figure 2 Figure 2
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 includes the user host(s) and optionally a
multicast proxy (not shown in the Figure 2.) 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 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 directly to mAAA or a NAS server.) An AN may be connected directory to mAAA or a NAS
relays AAA information between an AN and a mAAA relays AAA information between an AN and a mAAA
Descriptions of AN and its interfaces are out of scope for Descriptions of AN and its interfaces are out of scope for
this memo. The multicast AAA function may be provided by a this memo. The multicast AAA function may be provided by a
multicast AAA server (mAAA) which may include the function multicast AAA server (mAAA) which may include the function
by which the access policy is downloaded to the NAS by which the access policy is downloaded to the NAS
(Multicast access control function.) The interface between (conditional access policy control function.) The interface
mAAA and the NAS is labeled IFb in Figure 2. Over IFb the between mAAA and the NAS is labeled IFb in Figure 2. Over
NAS makes an access request to the NSP-mAAA and the mAAA IFb the NAS makes an access request to the NSP-mAAA and the
replies. The mAAA may push conditional access policy to the mAAA replies. The mAAA may push conditional access policy
NAS. to the NAS.
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.
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 2. 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 reply send multicast
traffic depending on the NSP and CPís policy decisions. traffic depending on the NSP and CP's policy decisions.
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 within the context of proxying policy over this interface for AAA-proxying.
multicast AAA messagescaching.
Fully enabled framework Fully enabled framework
+-------------------------------+ +-------------------------------+
| user | | user |
|+- - - - - - - - - - - - - - -+| |+- - - - - - - - - - - - - - -+|
|| CPE || || CPE ||
|| || || ||
|+- - - - - | - - - - - - - - -+| |+- - - - - | - - - - - - - - -+|
+-----------|-------------------+ +-----------|-------------------+
| |
skipping to change at page 18, line 47 skipping to change at page 18, line 47
| | CP-AAA | | | | CP-AAA | |
| +---------+ | | +---------+ |
+-------------------------------+ +-------------------------------+
Figure 3 Figure 3
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.)
Before replying to the user's multicast request the mAAA This means that Before replying to the user's multicast
queries the MACF for a network resource access decision request the mAAA queries the MACF for a network resource
over the interface IFd. The MACF is responsible for access decision over the interface IFd. The MACF is
allocating network resources for multicast traffic. To responsible for allocating network resources for multicast
provide MACF with the relevant network resource traffic. So that MACF has the necessary network resource
availability information, NAS notifies MACF via mAAA that availability information, NAS notifies MACF via mAAA of the
sending multicast traffic has ceased. stopping of multicast traffic.
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. An 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.
skipping to change at page 19, line 42 skipping to change at page 19, line 42
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 [1] 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. 05.txt, September 2007, Work in Progress.
[2] RFC-3810, Vida, R. and L. Costa, "Multicast Listener [2] RFC-3810, Vida, R. and L. Costa, "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", June 2004. Discovery Version 2 (MLDv2) for IPv6", June 2004.
[3] RFC-3376, Cain B., et.al., "Internet Group Management [3] RFC-3376, Cain B., et.al., "Internet Group Management
Protocol, Version 3", October 2002. Protocol, Version 3", October 2002.
[4] Ooghe, et. al, "Framework and Requirements for an
Access Node Control Mechanism in Broadband Multi-
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
Hiroshi Ohta Hiroshi Ohta
NTT Network Service Systems Laboratories NTT Network Service Systems Laboratories
3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585
Japan Japan
Phone : +81 422 59 3617 Phone : +81 422 59 3617
Email: ohta.hiroshi@lab.ntt.co.jp Email: ohta.hiroshi@lab.ntt.co.jp
Christian Jacquenet Christian Jacquenet
France Telecom R&D France Telecom
4, rue du Clos Courtel - 3, avenue Francois Chateau
- BP 91226 CS 36901, 35069 Rennes Cedex, France
35512 Cesson-SťvignĀECedex, France Phone: +33 2 99 87 63 31
Phone: +33 2 99 12 49 40 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
skipping to change at page 20, line 47 skipping to change at page 21, line 4
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.
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). 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
ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY),
THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE
USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS
OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR
A PARTICULAR PURPOSE.". A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope The IETF takes no position regarding the validity or scope
of any Intellectual Property Rights or other rights that of any Intellectual Property Rights or other rights that
might be claimed to pertain to the implementation or use might be claimed to pertain to the implementation or use
of the technology described in this document or the extent of the technology described in this document or the extent
to which any license under such rights might or might not to which any license under such rights might or might not
be available; nor does it represent that it has made any be available; nor does it represent that it has made any
independent effort to identify any such rights. independent effort to identify any such rights.
skipping to change at page 21, line 51 skipping to change at page 22, line 51
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 May 17, 2008. This Internet-Draft will expire on August 22, 2008.
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. 61 change blocks. 
164 lines changed or deleted 199 lines changed or added

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