draft-ietf-mboned-multiaaa-framework-03.txt   draft-ietf-mboned-multiaaa-framework-04.txt 
MBONED WG Hiroaki Satou, NTT Internet Draft AAA Framework for Multicasting
Internet-Draft Hiroshi Ohta, NTT Hiroaki Satou, NTT
Proposed Status: Informational Christian Jacquenet, France Telecom Internet Draft Hiroshi Ohta, NTT
Expires: September 2, 2007 Tsunemasa Hayashi, NTT Expires: Jan 10, 2008 Christian Jacquenet, France Telecom
Intended status: Informational Tsunemasa Hayashi, NTT
Haixiang He, Nortel Networks Haixiang He, Nortel Networks
March 4, 2007
July 9, 2007
AAA Framework for Multicasting AAA Framework for Multicasting
<draft-ietf-mboned-multiaaa-framework-03.txt> <draft-ietf-mboned-multiaaa-framework-04.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author
applicable patent or other IPR claims of which he or she is aware represents that any applicable patent or other IPR
have been or will be disclosed, and any of which he or she becomes claims of which he or she is aware have been or will
aware will be disclosed, in accordance with Section 6 of BCP 79. be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6
of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet
Task Force (IETF), its areas, and its working groups. Note that Engineering Task Force (IETF), its areas, and its
other groups may also distribute working documents as Internet- working groups. Note that other groups may also
Drafts. distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a
and may be updated, replaced, or obsoleted by other documents at any maximum of six months and may be updated, replaced,
time. It is inappropriate to use Internet-Drafts as reference or obsoleted by other documents at any time. It is
material or to cite them other than as "work in progress." inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed
http://www.ietf.org/ietf/1id-abstracts.txt. at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Internet Draft AAA Framework for Multicasting
http://www.ietf.org/shadow.html. The list of Internet-Draft Shadow Directories can be
accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 2, 2007. This Internet-Draft will expire on January 10, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007). This document
is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth
therein, the authors retain all their rights.
Abstract Abstract
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 potential or videoconferencing raise the issue of making sure
customers are fully entitled to access the corresponding that potential customers are fully entitled to access
contents. There is indeed a need for service and content the corresponding contents. There is indeed a need
providers to identify (if not authenticate, especially within the for service and content providers to identify (if not
context of enforcing electronic payment schemes) and to invoice authenticate, especially within the context of
such customers in a reliable and efficient manner. This memo enforcing electronic payment schemes) and to invoice
describes the framework for specifying the Authorization, such customers in a reliable and efficient manner.
Authentication and Accounting (AAA) capabilities that could be This memo describes the framework for specifying the
activated within the context of the deployment and the operation Authorization, Authentication and Accounting (AAA)
of IP multicast-based services. This framework addresses the capabilities that could be activated within the
requirements presented in draft-ietf-mboned-maccnt-req-04.txt, context of the deployment and the operation of IP
"Requirements for Accounting, Authentication and Authorization in multicast-based services. This framework addresses
Well Managed IP Multicasting Services". the requirements presented in draft-ietf-mboned-
maccnt-req-04.txt, "Requirements for Accounting,
Authentication and Authorization in Well Managed IP
Multicasting Services". The memo provides a basic AAA
enabled model as well as an extended fully enabled
model with resource and admission control
coordination.
1. Introduction 1. Introduction
1.1 Purpose and Background 1.1 Purpose and Background
IP multicasting is designed to serve cases of group communication IP multicasting is designed to serve cases of group
schemes of any kind, such as 1-to-n (case of TV broadcasting communication schemes of any kind, such as 1-to-n (case of
services for example) or n-to-p (case of videoconferencing services, TV broadcasting services for example) or n-to-p (case of
for example). videoconferencing services, for example).
In these environments, IP multicast provides a better resource In these environments, IP multicast provides a better
optimization than using a unicast transmission scheme, where data resource optimization than using a unicast transmission
need to be replicated as many times as there are receivers. scheme, where data need to be replicated as many times as
Activation of IP multicast capabilities in networks yields the there are receivers. Activation of IP multicast
establishment and the maintenance of multicast distribution trees capabilities in networks yields the establishment and the
that are receiver-initiated by nature: multicast-formatted data are maintenance of multicast distribution trees that 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 potential or videoconferencing raise the issue of making sure that
customers are fully entitled to access the corresponding contents. potential customers are fully entitled to access the
There is indeed a need for service and content providers to identify corresponding contents.
(if not authenticate, especially within the context of enforcing There is indeed a need for service and content providers to
electronic payment schemes) and to invoice such customers in a identify (if not authenticate, especially within the
reliable and efficient manner. This memo describes the framework for context of enforcing electronic payment schemes) and to
specifying the Authorization, Authentication and Accounting (AAA) invoice such customers in a reliable and efficient manner.
capabilities that could be activated within the context of the Solutions should consider a wide range of possible content
deployment and the operation of IP multicast-based services. delivery applications: content delivered over the multicast
network may include video, audio, images, games, software
and information such as financial data, etc.
This memo describes a framework for specifying the
Authorization, Authentication and Accounting (AAA)
capabilities that could be activated within the context of
the deployment and the operation of IP multicast-based
services. This memo also describes a framework to realize
high-quality multicast transport using a Resource and
Admission Control System (RACS) with multicast
Authorization.
Specifically, this framework addresses the requirements Specifically, this framework addresses the requirements
presented in draft-ietf-mboned-maccnt-req-04.txt, "Requirements for presented in draft-ietf-mboned-maccnt-req-04.txt,
Accounting, Authentication and Authorization in Well Managed IP "Requirements for Accounting, Authentication and
Multicasting Services" MACCNT-REQ-draft describes the requirements Authorization in Well Managed IP Multicasting Services"
in CDN services using IP multicast[1]. The requirements are derived MACCNT-REQ-draft describes the requirements in CDN services
from: using IP 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 requirements - need for network access control to satisfy the
of the Network Service Provider (NSP) and/or content access control requirements of the Network Service Provider (NSP) and/or
to satisfy the requirements of the Content Provider (CP) content access control to satisfy the requirements of the
- methods for sharing information between the network service Content Provider (CP)
provider and content provider to make it possible to fulfill the - methods for sharing information between the network
above two requirements. service provider and content provider to make it possible
to fulfill the above two requirements.
Detailed requirements are presented in MACCNT-REQ-draft. These Detailed requirements are presented in MACCNT-REQ-draft.
requirements include mechanisms for recording end-user requests and These requirements include mechanisms for recording end-
provider responses for content-delivery, sharing user information user requests and provider responses for content-delivery,
(possibly anonymously depending on the trust model) between content sharing user information (possibly anonymously depending on
provider and network service provider, and protecting resources the trust model) between content provider and network
through the prevention of network and content access by unauthorized service provider, and protecting resources through the
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 framework for The purpose of this memo is to provide a generalized framework
specifying multicast-inferred AAA capabilities that can meet these for specifying multicast-inferred AAA capabilities that can
requirements. This framework is to provide a basis for future work meet these requirements. This framework is to provide a
of investigating the applicability of existing AAA protocols to basis for future work of investigating the applicability of
provide these AAA capabilities in IP multicast specific context existing AAA protocols to provide these AAA capabilities in
and/or if deemed necessary, the refining or defining of protocols to IP multicast specific context and/or if deemed necessary,
provide these capabilities. the refining or defining of protocols to provide these
capabilities.
This draft's scope is limited to discussing SSM, 1-to-n IP
multicasting exclusively.
2. Definitions and Abbreviations 2. Definitions and Abbreviations
2.1 Definitions 2.1 Definitions
For the purpose of this memo the following definitions apply: For the purpose of this memo the following definitions
apply:
Accounting: The set of capabilities that allow the retrieval of a Accounting: The set of capabilities that allow the
set of statistical data that can be defined on a per customer and/or retrieval of a set of statistical data that can be defined
a per service basis, within the context of the deployment of on a per customer and/or a per service basis, within the
multicast-based services. Such data are retrieved for billing context of the deployment of multicast-based services. Such
purposes, and can be retrieved on a regular basis or upon data are retrieved for billing purposes, and can be
unsolicited requests. Such data include (but are not necessarily retrieved on a regular basis or upon unsolicited requests.
limited to) the volume of multicast-formatted data that have been Such data include (but are not necessarily limited to) the
forwarded to the receiver over a given period of time, the volume of volume of multicast-formatted data that have been forwarded
multicast-formatted data that have been exchanged between a receiver to the receiver over a given period of time, the volume of
(or set of) and a given source over a given period of time (e.g. the multicast-formatted data that have been exchanged between a
duration of a multicast session), etc. receiver (or set of) and a given source over a given period
of time (e.g. the duration of a multicast session), etc.
Authentication: action for identifying a user as a genuine one. Authentication: action for identifying a user as a genuine
one.
Authorization: The set of capabilities that need to be activated to Authorization: The set of capabilities that need to be
make sure a given requesting customer is (1) what he claims to be activated to make sure a given requesting customer is (1)
(identification purposes), and (2) is fully entitled to access a set what he claims to be (identification purposes), and (2) is
of services (authentication purposes). fully entitled to access a set of services (authentication
purposes).
Receiver: an end-host or end-client which receives content. A Receiver: an end-host or end-client which receives content.
receiver may be identified by a network ID such as MAC address or IP A receiver may be identified by a network ID such as MAC
address. address or IP address.
User: a human with a user account. A user may possibly use multiple User: a human with a user account. A user may possibly use
reception devices. Multiple users may use the same reception multiple reception devices. Multiple users may use the
device. same reception device.
Note: The definition of a receiver (device) and a user (human) Note: The definition of a receiver (device) and a user
should not be confused. (human) should not be confused.
2.2 Abbreviations 2.2 Abbreviations
For the purpose of this draft the following abbreviations apply: For the purpose of this draft the following abbreviations
apply:
ACL: Access Control List ACL: Access Control List
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
mRACF: Multicast Resource and Admission Control Function
NSP: Network Service Provider NSP: Network Service Provider
TP: Transit Provider 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 for a In some cases a single entity may design and be responsible
system that covers the various common high-level requirements of a for a system that covers the various common high-level
multicasting system such as 1) content serving, 2) the requirements of a multicasting system such as 1) content
infrastructure to multicast it, 3) network and content access serving, 2) the infrastructure to multicast it, 3) network
control mechanisms. In many cases however the content provision and and content access control mechanisms. In many cases
network provision roles are divided between separate entities. The however the content provision and network provision roles
MACCNT-REQ-draft provides more detail of the multiple versus single are divided between separate entities. The MACCNT-REQ-
draft provides more detail of the multiple versus single
entity CDS network models. entity CDS network models.
As such it should not be assumed that the entity responsible for the As such it should not be assumed that the entity
multicasting structure and the entity responsible for content responsible for the multicasting structure and the entity
serving are the same. Indeed because the infrastructure for responsible for content serving are the same. Indeed
multicasting is expensive and many content holders are not likely to because the infrastructure for multicasting is expensive
be competent at building and maintaining complicated infrastructures and many content holders are not likely to be competent at
necessary for multicasting, many content holders would prefer to building and maintaining complicated infrastructures
purchase transport and management services from a network service necessary for multicasting, many content holders would
provider and thus share the infrastructure costs with other content prefer to purchase transport and management services from a
holders. network service provider and thus share the infrastructure
costs with other content holders.
Similarly network service providers in many cases do not specialize Similarly network service providers in many cases do not
in providing content and are unlikely to build and maintain such a specialize in providing content and are unlikely to build
resource-intensive system without a certain level of demand from and maintain such a resource-intensive system without a
content holders. certain level of demand from content holders.
The use model of a single NSP providing multicasting services to The use model of a single NSP providing multicasting
multiple CPs the following general requirements from MACCNT-REQ- services to multiple CPs the following general requirements
draft apply: from MACCNT-REQ-draft apply:
-Need for user tracking and billing capabilities -Need for user tracking and billing capabilities
-Need for network access control and/or content access control -Need for QoS control such as resource management and
admission control
-Need for conditional content access control
satisfactory to the requirements of the CP satisfactory to the requirements of the CP
-Methods for sharing information between the NSP and CP to make -Methods for sharing information between the NSP and
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 level the -Need for access control and/or content protection at
entity deems appropriate level the entity deems appropriate
4. Framework and Roles of Entities 4. Framework and Roles of Entities
4.1 Framework for multicast AAA 4.1 Framework for multicast AAA
A general high-level framework can be represented as follows.
A general high-level framework can be represented as
follows.
+------------------------------+ +------------------------------+
| user | | user |
| | | |
+------------------------------+ +------------------------------+
| Access ^ Response | Access ^ Response
| Request | & Multicast Data | Request | & Multicast Data
V | V |
+------------------------------+ +------------------------------+
| NSP | | NSP |
| | | |
+------------------------------+ +------------------------------+
| Access ^ Response | Access ^ Response
| Request | (Success) | Request | (Success)
v | v |
+------------------------------+ +------------------------------+
| CP | | CP |
| | | |
+------------------------------+ +------------------------------+
Figure 1
For the sake of simplicity, the above diagram portrays a case where For the sake of simplicity, the above diagram portrays a
there is a single NSP entity and a single CP entity, but multiple case where there is a single NSP entity and a single CP
CPs can be connected to the same NSP. It is also possible for the entity, but multiple CPs can be connected to the same NSP.
same CP to be connected to multiple NSP networks (e.g. network It is also possible for the same CP to be connected to
selection). In other words the relationship of NSP:CP can be multiple NSP networks (e.g. network selection). In other
described as 1:1, 1:N or M:N. Furthermore it is possible that the words the relationship of NSP:CP can be described as 1:1,
NSP and CP could be the same entity. 1:N or M:N. Furthermore it is possible that the NSP and CP
could be the same entity.
Description of Roles: Description of Roles:
The user (or the user's device) selects a CP and a NSP when the user The user (or the user's device) selects a CP and a NSP when
requests content. The NSP may be automatically selected by a user the user requests content. The NSP may be automatically
terminal: e.g. a fixed line NSP for STB or a mobile NSP for mobile selected by a user terminal: e.g. a fixed line NSP for STB
phone. In some usage cases it is possible that the NSP used by the or a mobile NSP for mobile phone. In some usage cases it
user terminal will not always be the same. For example a user may is possible that the NSP used by the user terminal will not
have contracted with different NSPs for fixed line or mobile roaming always be the same. For example a user may have contracted
access. with different NSPs for fixed line or mobile roaming access.
The CP is responsible for Authentication and Authorization of users' The CP is responsible for Authentication and Authorization
access to content that the CP manages. The CP hopes to collect of users' access to content that the CP manages. The CP
accounting information related to the access of their content. The hopes to collect accounting information related to the
CP may choose to authenticate and authorize NSPs which are eligible access of their content. The CP may choose to authenticate
to provide users access to its contents. When the CP cannot (e.g. and authorize NSPs which are eligible to provide users
error or resource issues) or decides not (e.g. policy issues) to access to its contents. When the CP cannot (e.g. error or
deliver content, the CP is responsible for notifying the NSP of the resource issues) or decides not (e.g. policy issues) to
reason. It is up to the NSP how to relay or translate the messages deliver content, the CP is responsible for notifying the
to the user. NSP of the reason. It is up to the NSP how to relay or
translate the messages to the user.
The NSP is responsible for managing its network resources. The NSP The NSP is responsible for managing its network resources.
may perform admission control. It is also responsible for relaying The NSP may perform admission control. It is also
the AAA messages from the CP whether the user is eligible to receive responsible for relaying the AAA messages from the CP
content (authentication by proxy), and the NSPs relevant AAA server whether the user is eligible to receive content
will make the final decision of whether the connection can be (authentication by proxy), and the NSP's relevant AAA
established. When the NSP cannot or decides not to multicast to server will allow access to the network and contents
users, the NSP is responsible for notifying the users of the reason. conditional to both the CP AAA server's content
authorization result and the NSPs network utilization
authorization result. In certain cases the CP and NSP may
have a contractual relationship in which the NSP is
authorized to make the content authorization decision based
on mutually predetermined criteria: in such cases the NSP-
AAA may also make the content authorization decision
without querying the CP-AAA. When the NSP cannot or
decides not to multicast to users, the NSP may notify the
users of the reason. It is recommended that the NSP notify
eligible users of the reason for not multicasting content
when it is due network or content unavailability, for
example. The NSP may choose not to notify ineligible users
of the reason for any case.
4.2 Multiple User IDs 4.2 Multiple User IDs
Users may hold multiple user IDs: IDs which have been separately Users may hold multiple user IDs: IDs which have been
assigned for each subscription they may have for various NSPs and separately assigned for each subscription they may have for
CPs. The NSPs and CPs control the user IDs for their respective various NSPs and CPs. The NSPs and CPs control the user
domains. The user IDs are only meaningful in the context of each IDs for their respective domains. The user IDs are only
domain. meaningful in the context of each domain.
When the user wants to access content, the user registers the When the user wants to access content, the user registers
corresponding user ID (including its CP domain information) with a the corresponding user ID (including its CP domain
request for content, etc: web authentication is one possible method. information) with a request for content, etc: web
authentication is one possible method.
Each CP may identify users by the user IDs that it has issued to Each CP may identify users by the user IDs that it has
them. issued to them.
Terminal portability can be realized if the NSP authenticates a user Terminal portability can be realized if the NSP
using a NSP-domained user ID. This allows the user to access the authenticates a user using a NSP-assigned user ID. A NSP-
content from various network access points. assigned user ID is an access-line independent unique ID
assigned to users which allows user identification from any
access point within the network and possibly roaming to
other networks. This allows the user to access the content
from various network access points.
The NSP and CP do not need to know the corresponding user id for the The NSP and CP do not need to know the corresponding user
same user in the other provider's domain, and it is not necessary id for the same user in the other provider's domain, and it
that there is a one to one relationship. It is quite possible for is not necessary that there is a one to one relationship.
one person to hold multiple user ids for the same provider. It is quite possible for one person to hold multiple user
ids for the same provider.
The actual mapping rules for NSPs and CPs to map user IDs with the The actual mapping rules for NSPs and CPs to map user IDs
IDs in other provider domains is a matter for the providers. A with the IDs in other provider domains is a matter for the
solution should provide an API between the providers to flexibly providers. A solution should provide an API between the
support various mapping methods. providers to flexibly support various mapping methods.
4.3 Accounting 4.3 Accounting
MACCNT-REQ-draft defines requirements for Accounting and Billing. MACCNT-REQ-draft defines requirements for Accounting and
These include the requirement for the NSP to log user behavior such Billing. These include the requirement for the NSP to log
as the join action and the leave action, as well as the result of user behavior such as the join action and the leave action,
the access-control decision. (MACCNT-REQ-draft, 4.5) MACCNT-REQ- as well as the result of the access-control decision.
draft also specifies that there should be a standardized format for (MACCNT-REQ-draft, 4.5) MACCNT-REQ-draft also specifies
sharing with the CP the user behavior and content reception that there should be a standardized way to sharing with the
information which the NSP is logging.(MACCNT-REQ-draft, 4.5.1) CP the user behavior and content reception information
In order to provide the granularity of user-behavior and actual which the NSP is logging.(MACCNT-REQ-draft, 4.5.1)
content reception information as specified in MACCNT-REQ-draft, the Standardization of the logs or messages to share content
NSP should not manage multicast states on a subnet basis, but on a usage information is important to support a single NSP
user basis (see in MACCNT-REQ-draft, 4.1 "User identification") sharing accounting information with multiple CPs or a
because the NSP needs to be able to notify the CP of a user's start single CP receiving from multiple NSPs.
and stop times for accounting purposes. This means that the NSP
sends to the CP AAA an indication for Join and Leave on a user
basis.
This framework specifies an accounting API provided by the NSP and In order to provide the granularity of user-behavior and
accessed by the CP to allow for sharing user-behavior and content- actual content reception information as specified in
reception information between the NSP AAA and CP AAA. This MACCNT-REQ-draft, the NSP should not manage multicast
accounting API should be configurable to allow the CP to request states on a subnet basis, but on a user basis (see in
only the logging information it actually requires. Such an API MACCNT-REQ-draft, 4.1 "User identification") because the
would allow for realtime accounting information sharing by the NSP NSP needs to be able to notify the CP of a user's start and
to the CP. When logging information is shared through the accounting stop times for accounting purposes. This means that the NSP
API, it is important that the CP be able to match the user as sends to the CP AAA an indication for Join and Leave on a
described in the database operated by the NSP to the user as user basis. User-based multicast state management is
described in the database operated by the CP. equivalent to explicit membership tracking in RFC3376 and
per-host tracking in RFC3810.
This framework specifies an accounting API provided by the
NSP and accessed by the CP to allow for sharing user-
behavior and content-reception information between the NSP
AAA and CP AAA. This accounting API should be configurable
to allow the CP to request only the logging information it
actually requires. Such an API would allow for realtime
accounting information sharing by the NSP to the CP. When
logging information is shared through the accounting API,
it is important that the CP be able to match the user as
described in the database operated by the NSP to the user
as described in the database operated by the CP.
The NSP requires the capability to log both user and host The NSP requires the capability to log both user and host
information for each join and leave, indicating the corresponding information for each join and leave, indicating the
multicast source for each action. When either a CP source stops corresponding multicast source for each action. When either
sending, or the NSP stops multicasting, in an unsolicited manner, a CP source stops sending, or the NSP stops multicasting,
there is also a need to notify the AAA servers accordingly about the in an unsolicited manner, there is also a need to notify
users who are impacted by this event. the AAA servers accordingly about the users who are
impacted by this event.
Also, intermittent logs between the join and leave would allow for Also, intermittent logs between the join and leave would
finer diagnostics and therefore could serve useful in billing allow for finer diagnostics and therefore could serve
discrepancies, and provide for a better estimation of the time span useful in billing discrepancies, and provide for a better
that content was multicasted in the even that users disconnect estimation of the time span that content was multicasted in
without sending leave messages. the even that users disconnect without sending leave
messages.
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, it is necessary When a NSP receives an access request from a user, it is
for the NSP to determine to which CP the request is to be directed. necessary for the NSP to determine to which CP the request
It is necessary for the NSP to ensure that it is not spoofed by an is to be directed. It is necessary for the NSP to ensure
inappropriate CP or user. that it is not spoofed by an inappropriate CP or user.
4.5 API for Admission Control Information by NSP 4.5 API for 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. MACCNT- conditions for determining its admission control decision.
REQ-draft defines requirements for providing the network capability MACCNT-REQ-draft defines requirements for providing the
to conduct admission control based on the network bandwidth usage network capability to conduct admission control based on
status and bandwidth management policy. (MACCNT-REQ-draft, 4.2.2, the network bandwidth usage status and bandwidth management
4.2.3 & 4.9) Such QoS measurement and policy mechanisms themselves policy. (MACCNT-REQ-draft, 4.2.2, 4.2.3 & 4.9) Such QoS
are out of the scope of this memo. However the NSP's AAA Server measurement and policy mechanisms themselves are out of the
should be provided with an Admission control API that allows for scope of this memo. However the NSP's AAA Server should be
interfacing so that additional conditions can be added to the provided with an Admission control API that allows for
admission control decision. interfacing so that additional conditions can be added to
the admission control decision.
4.6 Access Control and Distinguishing of Users by CP 4.6 Access Control and Distinguishing of Users by CP
The user ID and authentication information are forwarded The user ID and authentication information are forwarded
transparently by the NSP so that the CP can distinguish the user, as transparently by the NSP so that the CP can distinguish the
well as authenticate and authorize the request. user, as well as authenticate and authorize the request.
4.7 Caching of AAA results 4.7 Caching of AAA results
An NSP should be able to cache AAA results based upon an agreement An NSP should be able to cache AAA results based upon an
between the NSP and a CP. The AAA cache would store information agreement between the NSP and a CP. The AAA cache would
about permissions of a specific user to receive multicast data from store information about permissions of a specific user to
specified channel(s) up to specified expiration date(s) and time(s). receive multicast data from specified channel(s) up to
If such caching is implemented, a method must exist for the CP to specified expiration date(s) and time(s).
communicate this permission information to the NSP. The NSP refers If such caching is implemented, a method must exist for the
to the AAA cache and if the cache indicates that the user has CP to communicate this permission information to the NSP.
permission to receive multicast data from a specific channel at that The NSP refers to the AAA cache and if the cache indicates
time, the NSP may forward the data without querying the CP. that the user has permission to receive multicast data from
a specific channel at that time, the NSP may forward the
data without querying the CP.
It should be possible for a CP to send unsolicited requests to the It should be possible for a CP to send unsolicited requests
NSP to refresh or change the permissions for a user for specific to the NSP to refresh or change the permissions for a user
channel(s). for specific channel(s).
When a user is receiving multicast content and the permission is When a user is receiving multicast content and the
about to expire, the NSP may send a notification to the user client permission is about to expire, the NSP may send a
that his session is about to expire, and that he will need to re- notification to the user client that his session is about
connect. The user will have to reestablish a connection. In the to expire, and that he will need to re-connect. The user
case that the user still has permission to the content, they should will have to reestablish a connection. In the case that
be able to continue to receive the content without interruption. the user still has permission to the content, they should
be able to continue to receive the content without
interruption.
5. Network Connection Model and Functional Components 5. Network Connection Model and Functional Components
Section 3.1 introduces the high-level AAA framework for multicasting. Section 3.1 introduces the high-level AAA framework for
This section provides more detail on the network connection model multicasting. This section provides more detail on the
and constituent functional components. network connection model and constituent functional
components.
5.1 Basic Connection Model 5.1 Basic Connection Model
+-------------+ In the simple case represented in Figure 1 the NSP is the
| user | sole entity providing network resources including network
| | access to the User. First a user that requests content
+-------------+ sends an Access request to an NSP which then forwards it on
^ Access & Resource to the appropriate CP for Authentication and Authorization
| Request purposes. The CP responds with either "success" or
v "failure". If "success", the NSP may forward a success
+-------------+ response and stream multicast data to the user.
| NSP= NAP |
| |
+-------------+
^ Access
| Request
v
+-------------+
| CP |
| |
+-------------+
In this case the NSP is the sole entity providing Network Service
Provision including Network Access Provision to the User. First a
user that requests content sends an Access request to an NSP which
then forwards it on to the appropriate CP for Authentication and
Authorization purposes. The CP responds with either "success" or
"failure". If "success", the NSP may forward a success response and
stream multicast data to the user.
In this model the user selects the NSP to which to send its content
request. Based on this request the NSP selects an appropriate CP to
which it forwards the request. The CP responds to the NSP's request:
it may not respond to another NSP in regards to the request.
In this model, as described in section 3.1, the relationship between
NSP and CP can be 1:1, 1:N or M:N. Users may connect to multiple
networks, and networks have multiple users.
5.2 Transit Provision
The diagram below shows that Network Service Provision may include
both Network Access Provision to the User and also Transit Provision
(request relay) between the Network Access Provider (NAP) and the CP.
Transit Provision is the responsibility of the NSP which may or may
not contract out this service to a separate NSP that acts as the
Transit Provider. The existence of the Transit Provider is
transparent to the user.
+-------------+
| user |
| |
+-------------+
^ Access & Resource
| Request
v
+- - - - - - - - - - - - - - +
|+----------------+
| Network Access | |
|| Provision | Network Service
+----------------+ | Provision
| ^ Access & Resource
| Request |
| v
+-------------+ |
|| Transit |
| Provision | |
|+-------------+
+- - - - - - - - - - - - - - +
^ Access
| Request
v
+-------------+
| CP |
| |
+-------------+
For the sake of simplification the above diagram shows a 1-1
relationship between an NAP and a TP. However it is also possible
for a single NAP to connect to multiple TPs, and a single TP to
multiple NAPs.
A single TP may connect to one or more CPs. Similarly just as a In this model the user selects the NSP to which to send its
single CP may connect to multiple NAPs (as described in the general content request. Based on this request the NSP selects an
high-level framework, section 3.1), a single CP may connect to one appropriate CP to which it forwards the request. The CP
or more TPs. responds to the NSP's request: it may not respond to
another NSP in regards to the request.
A solution will include a mechanism through which the NAPs know In this model, as described in section 3.1, the
which TP(s) are to be used to communicate with which CP(s), and CPs relationship between NSP and CP can be 1:1, 1:N or M:N.
know which TP(s) to use for which NAP(s). When a TP receives an
access or resource request from an NAP or CP, it must relay the
request to the correct CP or NSP, respectively. Minimally, this
means that it must reconstruct the request with translated address
information. In this model therefore a TP must understand the
format and meaning of the requests.
There may be multiple TPs between a NAP and CP so that a TP is Users may connect to multiple networks, and networks have
actually receiving from and/or sending requests to another TP and multiple users.
not directly from/to a NAP or CP.
5.3 Transit with Tunnels 5.2 Constituent Logical Functional Components of the fully
enabled AAA Framework
In addition to the above model of request relaying, a TP may MACCNT-REQ-draft defined requirements for "well managed"
communicate requests through tunneling based on the contract between multicasting which this memo calls "AAA enabled"
the TP and the NAP and/or between the TP and the CP. So in this multicasting. "Fully enabled AAA" multicasting in this memo
case the TP will not directly need to process the contents of the means "AAA enabled" with added QoS functions.
access and resource request (such as, header information), but
instead pass the request directly to the correct NSP or CP, using a
separate protocol to wrap the original requests.
Below is a diagram, representing how a TP can provide tunneling Section 3.1 introduces the high-level AAA framework for
between NAP(s) and CP(s). multicasting. Below is a diagram of a AAA enabled
multicasting network with AAA, including the logical
components within the various entities.
+-----------------+ AAA enabled framework (basic model)
+-------------------------------+
| user | | user |
| | |+- - - - - - - - - - - - - - -+|
+-----------------+ || CPE ||
^ Access & Resource || ||
| Request |+- - - - - | - - - - - - - - -+|
v +-----------|-------------------+
+ - - - - - - - - - - + |
+------------------+ -------|------ IFa
|| NAP | | |
| | +-----------|-------------------+
|+------------------+ | Network | NSP | |
|^| |+- - - - - |- -_+ |
| |:| | Service ||TS | | |
|:| | +------|-+ |
|+-|:|--------------+ | Provision || | AN | | |
| |:| TP | | | | |
|| |:| | | || +------|-+ | |
+-|:|--------------+ | | IFb |
+ -|:|- - - - - - - - + || +------|-+ | | +---------+|
|:| Tunnel | | |----|-|mAAA ||
|:| || | NAS | | | | (CAPCF*)|| * optional
|V| | +--------+ +---------+|
+------------------+ ||+- - - - - - - + | |
| CP | +-----------------------|--------+
| | |
+------------------+ -------|------ IFc
|
+-----------------------|-------+
| CP +---------+ |
| | CP-AAA | |
| +---------+ |
+-------------------------------+
Figure 2
The user entity includes the CPE (Customer Premise
Equipment) which includes the user host(s) and optionally a
multicast proxy (not shown in the Figure 2.)
In this model too, the relationship between NAP and TP and between The NSP (Network Service Provider) in the basic model
TP and CP can be 1:1, 1:N or M:N. includes the transport system and a logical element for
multicast AAA functionality. The transport system is
comprised of the access node and NAS (network access
server.) Descriptions of AN and its interfaces are out of
scope for this memo. The multicast AAA function may be
provided by a multicast AAA server (mAAA) which may include
a function by which the access policy is downloaded to the
NAS (conditional access policy control function.) The
interface between mAAA and NAS is labeled IFb in Figure 2.
Over IFb the NAS makes an access request to the NSP-mAAA
and the mAAA replies. The mAAA may push conditional access
policy to the NAS.
5.4 Constituent Logical Functional Components of the fully enabled AAA The content provider may have its own AAA server which has
Framework the authority over access policy for its contents.
Section 3.1 introduces the high-level AAA framework for multicasting. The interface between the user and the NSP is labeled IFa
Below is a diagram of a fully enabled multicasting network with AAA, in Figure 2. Over IFa the user makes a multicasting
including the logical components within the various entities. request to the NSP. The NSP may in reply send multicast
traffic depending on the NSP and CP's policy decisions.
The interface between the NSP and CP is labeled IFc. Over
IFc the NSP requests to the CP-AAA for access to contents
and the CP replies. CP may also send conditional access
policy over this interface for AAA-caching.
Fully enabled framework (c)
+-------------------------------+ +-------------------------------+
| user | | user |
| | |+- - - - - - - - - - - - - - -+|
+-------------------------------+ || CPE ||
^ || ||
| Access & resource request |+- - - - - | - - - - - - - - -+|
v +-----------|-------------------+
+-------------------------------+ |
| NSP | -------|------ IFa
| | |
|+--------------+ +---------+| +-----------|-----------------------+
||NR Management |<-->|AAA Proxy|| (NR= network resource) |+- - - - - |- - _+ + - - - - - + |
|+--------------+ RR +---------+| (RR= resource request) ||TS | | | | | |
+-------------------------------+ | +------|-+ | +--------+ |
^ || | AN | | | | | mRACF || |
| Access request | | | | | | |
v || +------|-+ | | | +---|----+| |
+------------------------------+ | | | | | |
| CP | | | | | IFd----- | |
| | | | | IFb | | |
| +---------+ | || +------|---+ | | | +---|----+| |
| | AAA | | | | |---|---| mAAA | |
|| | NAS | | | | |(CAPCF*)|| | * optional
| +----------+ | +--------+ |
||+- - - - - - - -+ - - |- - - - -+ |
+-----------------------|-----------+
|
-------|------ IFc
|
+-----------------------|-------+
| CP +---------+ |
| | CP-AAA | |
| +---------+ | | +---------+ |
+------------------------------+ +-------------------------------+
Figure 3
In the fully enabled model the NSP provides proxying of In the fully enabled model the NSP also includes a
authentication and authorization between the NSP and CP, as well as component that provides network resource management (e.g.
user-based accounting. The AAA proxy server of the NSP communicates QoS management), as described in section 3.4, "Network
with the CP's AAA server. Although not shown in the above diagram Resource Management by NSP". In the fully enabled model
for the sake of simplicity, in addition to direct proxying between a (Figure 3) resource management and admission control is
NSP and CP, this proxying may be done through a TP. This means that provided by mRACF (multicast resource and admission control
the transit provider is also cable of supporting AAA proxying. function.) This means that mRACF and Authorization portion
of mAAA comprise RACS. Before replying to the user's
multicast request the mAAA queries the mRACF for a network
resource access decision over the interface IFd. The mRACF
is responsible for allocating network resources for multicast
traffic. So that mRACF has the necessary network resource
availability information, NAS notifies mRACF via mAAA of the
stopping of multicast traffic.
In the fully enabled model the NSP also includes a component that 5.3 Modularity of the framework
provides network resource management (e.g. QoS management), as
described in section 3.4, "Network Resource Management by NSP".
When a transit provider is used it may also provide Network Resource
management of its own resources.
5.5 Modularity of the framework In the interest of flexibility, this framework is modular
In the interest of flexibility, this framework is modular so that it so that it is possible that partially enabled versions of
is possible that partially enabled versions of the models are the models are supported. A AAA-enabled version provides
supported. A AAA-enabled version provides AAA functionality without AAA functionality without Network Resource management. A
Network Resource management. A Network-Resource-Management-enabled Network-Resource-Management-enabled (QoS-enabled) version
(QoS-enabled) version provides Network Resource management without provides Network Resource management without AAA
AAA functionality. Similarly, the possibility of one or more layers functionality. Similarly, the possibility of one or more
of transit provision between an NSP and CP is in the interest of layers of transit provision between an NSP and CP is in the
modularity and extendibility. interest of modularity and extendibility.
6. IANA considerations 6. IANA considerations
This memo does not raise any IANA consideration issues. This memo does not raise any IANA consideration issues.
7. Security considerations 7. Security considerations
Refer to section 3.3. Also the user information related to Refer to section 3.3. Also the user information related to
authentication with the CP must be protected in some way. authentication with the CP must be protected in some way.
Otherwise, this memo does not raise any new security issues which Otherwise, this memo does not raise any new security issues
are not already addressed by the original protocols. Enhancement of which are not already addressed by the original protocols.
multicast access control capabilities should enhance security Enhancement of multicast access control capabilities should
performance. enhance security performance.
8. Conclusion 8. Conclusion
This memo provides a generalized framework for solution standards to This memo provides a generalized framework for solution
meet the requirements presented in MACCNT-REQ-draft. Further work standards to meet the requirements presented in MACCNT-REQ-
should be done to break down the content provider and network draft. Further work should be done to specify the
service provider entities into their functional objects such as edge interfaces between the user and NSP, NAS and mAAA, mAAA and
devices, AAA servers, etc. mRACF and NSP-mAAA and CP-AAA (presented in 5.2.)
Normative References Normative References
[1] Hayashi, et. al., "Accounting, Authentication and Authorization [1] Hayashi, et. al., "Accounting, Authentication and
Issues in Well Managed IP Multicasting Services", draft-ietf- Authorization Issues in Well Managed IP Multicasting
mboned-maccnt-req-04.txt, February 2006, Work in Progress. Services", draft-ietf-mboned-maccnt-req-04.txt,
February 2006, Work in Progress.
[2] RFC-3810, Vida, R. and L. Costa, "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", June 2004.
[3] RFC-3376, Cain B., et.al., "Internet Group Management
Protocol, Version 3", October 2002.
Authors' Addresses 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 Japan 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585
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 Japan 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585
Japan
Phone : +81 422 59 3617 Phone : +81 422 59 3617
Email: ohta.hiroshi@lab.ntt.co.jp Email: ohta.hiroshi@lab.ntt.co.jp
Christian Jacquenet Christian Jacquenet
France Telecom France Telecom
3, avenue Francois Chateau 3, avenue Francois Chateau
CS 36901, 35069 Rennes Cedex, France CS 36901, 35069 Rennes Cedex, France
Phone: +33 2 99 87 63 31 Phone: +33 2 99 87 63 31
Email: christian.jacquenet@francetelecom.com Email: christian.jacquenet@francetelecom.com
Tsunemasa Hayashi Tsunemasa Hayashi
NTT Network Innovation Laboratories NTT Network Innovation Laboratories
1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 Japan 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847
Japan
Phone: +81 46 859 8790 Phone: +81 46 859 8790
Email: tsunemasa@gmail.com Email: tsunemasa@gmail.com
Haixiang He Haixiang He
Nortel Nortel
600 Technology Park Drive 600 Technology Park Drive
Billerica, MA 01801, USA Billerica, MA 01801, USA
Phone: +1 978 288 7482 Phone: +1 978 288 7482
Email: haixiang@nortel.com Email: haixiang@nortel.com
Comments Comments
Comments are solicited and should be addressed to the mboned working Comments are solicited and should be addressed to the
group's mailing list at mboned@lists.uoregon.edu_and/or the authors. mboned working group's mailing list at
mboned@lists.uoregon.edu_and/or the authors.
Intellectual Property Statement Full Copyright Statement
The IETF takes no position regarding the validity or scope of any Copyright (C) The IETF Trust (2007).
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 This document is subject to the rights, licenses and
assurances of licenses to be made available, or the result of an restrictions contained in BCP 78, and except as set forth
attempt made to obtain a general license or permission for the use of therein, the authors retain all their rights.
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 "This document and the information contained herein are
copyrights, patents or patent applications, or other proprietary provided on an "AS IS" basis and THE CONTRIBUTOR, THE
rights that may cover technology that may be required to implement ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY),
this standard. Please address the information to the IETF at THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET
ietf-ipr@ietf.org. 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.".
Disclaimer of Validity Intellectual Property
This document and the information contained herein are provided on an The IETF takes no position regarding the validity or scope
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS of any Intellectual Property Rights or other rights that
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND might be claimed to pertain to the implementation or use
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS of the technology described in this document or the extent
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF to which any license under such rights might or might not
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED be available; nor does it represent that it has made any
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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.
Copyright Statement 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.
Copyright (C) The IETF Trust (2007). This document is subject to the The IETF invites any interested party to bring to its
rights, licenses and restrictions contained in BCP 78, and except as attention any copyrights, patents or patent applications,
set forth therein, the authors retain all their rights. 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.
Acknowledgment Expiration
Funding for the RFC Editor function is currently provided by the This Internet-Draft will expire on January 10, 2008.
Internet Society.
Acknowledgement
Funding for the RFC Editor function is currently provided
by the Internet Society.
 End of changes. 93 change blocks. 
491 lines changed or deleted 561 lines changed or added

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