draft-ietf-mboned-multiaaa-framework-01.txt   draft-ietf-mboned-multiaaa-framework-02.txt 
Hiroaki Satou, NTT Hiroaki Satou, NTT
Internet Draft Hiroshi Ohta, NTT Internet Draft Hiroshi Ohta, NTT
Expires: December 25, 2006 Tsunemasa Hayashi, NTT Expires: April 26, 2007 Christian Jacquenet, France Telecom
Tsunemasa Hayashi, NTT
Haixiang He, Nortel Networks Haixiang He, Nortel Networks
June 23, 2006 October 23, 2006
AAA Framework for Multicasting AAA Framework for Multicasting
<draft-ietf-mboned-multiaaa-framework-01.txt> <draft-ietf-mboned-multiaaa-framework-02.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 represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts. other groups may also 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 maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other documents
time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as
material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 25, 2006. This Internet-Draft will expire on April 26, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006) Copyright (C) The Internet Society (2006)
Abstract Abstract
This memo provides a generalized framework for solution standards to IP multicast-based services, such as TV broadcasting or
meet the requirements presented in draft-ietf-mboned-maccnt-req- videoconferencing raise the issue of making sure that potential
04.txt, "Requirements for Accounting, Authentication and customers are fully entitled to access the corresponding contents.
Authorization in Well Managed IP Multicasting Services". In this There is indeed a need for service and content providers to identify
framework a user sends a request for multicast data to a network (if not authenticate, especially within the context of enforcing
service provider. The network service provider selects the electronic payment schemes) and to invoice such customers in a
appropriate content provider to send the user's request. The request reliable and efficient manner. This memo describes the framework for
is sent by the network service provider to the content provider specifying the Authorization, Authentication and Accounting (AAA)
transparently in a way so that the network service provider and capabilities that could be activated within the context of the
content provider do not need to know the corresponding user id for deployment and the operation of IP multicast-based services. This
the same user in the other provider's domain. The content provider framework addresses the requirements presented in draft-ietf-mboned-
then responds with an indication of "success" or "failure" to the maccnt-req-04.txt, "Requirements for Accounting, Authentication and
network provider and in the case of "success", the network provider Authorization in Well Managed IP Multicasting Services".
may delivery the requested data to the user. The network service may
base its decision to deliver such data to the user based on its
bandwidth management policy. The framework is designed to be
flexible and extendible, so it will be possible to implement
partially enabled versions as well as fully enabled versions of the
model. Also an additional entity may provide transit of requests
between network service providers and content providers, either
through relaying or tunneling.
1. Introduction 1. Introduction
1.1 Purpose and Background 1.1 Purpose and Background
IP multicasting is designed to serve cases of group communication
schemes of any kind, such as 1-to-n (case of TV broadcasting
services for example) or n-to-p (case of videoconferencing services,
for example).
In these environments, IP multicast provides a better resource
optimization than using a unicast transmission scheme, where data
need to be replicated as many times as there are receivers.
Activation of IP multicast capabilities in networks yields the
establishment and the maintenance of multicast distribution trees
that are receiver-initiated by nature: multicast-formatted data are
forwarded to receivers who explicitly request them.
IP multicasting is designed to serve cases where a single source of IP multicast-based services, such as TV broadcasting or
data content is to be concurrently streamed to multiple recipients. videoconferencing raise the issue of making sure that potential
In these types of cases, multicasting provides resource efficiencies customers are fully entitled to access the corresponding contents.
(both for the overall network and the content server) relative to There is indeed a need for service and content providers to identify
unicasting. These efficiencies are possible because of the avoidance (if not authenticate, especially within the context of enforcing
of unnecessary duplication of streams, video/audio processing, etc. electronic payment schemes) and to invoice such customers in a
Multicasting also provides resource efficiencies relative to IP reliable and efficient manner. This memo describes the framework for
broadcasting in that content data is only delivered to end hosts specifying the Authorization, Authentication and Accounting (AAA)
which request it. capabilities that could be activated within the context of the
deployment and the operation of IP multicast-based services.
There are many real-life situations where IP multicasting is selected Specifically, this framework addresses the requirements
as the technology used for concurrent content delivery of identical presented in draft-ietf-mboned-maccnt-req-04.txt, "Requirements for
content data to multiple end-hosts. "Requirements for Accounting, Accounting, Authentication and Authorization in Well Managed IP
Authentication and Authorization in Well Managed IP Multicasting Multicasting Services" MACCNT-REQ-draft describes the requirements
Services", (draft-ietf-mboned-maccnt-req-04.txt, hereafter MACCNT- in CDN services using IP multicast[1]. The requirements are derived
REQ-draft) describes the requirements in CDN services using IP from:
multicast[1]. "Issues Related to Receiver Access Control in the
Current Multicast Protocols" (draft-ietf-mboned-rac-issues-03.txt,
hereafter RAC-ISSUES-draft) discusses the requirements and existing
support for large-scale, multi-entity content delivery services[2].
The requirements are derived from:
- 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 network access control to satisfy the requirements
to satisfy the requirements of the CP of the Network Service Provider (NSP) and/or content access control
to satisfy the requirements of the Content Provider (CP)
- methods for sharing information between the network service - methods for sharing information between the network service
provider and content provider to make it possible to fulfill the provider and content provider to make it possible to fulfill the
above two requirements. above two requirements.
Detailed requirements are presented in MACCNT-REQ-draft. These Detailed requirements are presented in MACCNT-REQ-draft. These
requirements include mechanisms for recording end-user requests and requirements include mechanisms for recording end-user requests and
provider responses for content-delivery, sharing user information provider responses for content-delivery, sharing user information
(possibly anonymously depending on the trust model) between content (possibly anonymously depending on the trust model) between content
provider and network service provider, and protecting resources provider and network service provider, and protecting resources
through the prevention of network and content access by unauthorized 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 for
solution standards to meet these requirements. This framework is to specifying multicast-inferred AAA capabilities that can meet these
provide a basis for defining protocols, but definition of the actual requirements. This framework is to provide a basis for future work
protocols is outside of the scope of this memo. of investigating the applicability of existing AAA protocols to
provide these AAA capabilities in IP multicast specific context
and/or if deemed necessary, the refining or defining of protocols to
provide these capabilities.
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 purposes of this memo the following definitions apply: For the purpose of this memo the following definitions apply:
Accounting: actions for grasping each user's behavior, when she/he Accounting: The set of capabilities that allow the retrieval of a
starts/stops to receive a channel, which channel she/he receives, set of statistical data that can be defined on a per customer and/or
etc. a per service basis, within the context of the deployment of
multicast-based services. Such data are retrieved for billing
purposes, and can be retrieved on a regular basis or upon
unsolicited requests. Such data include (but are not necessarily
limited to) the volume of multicast-formatted data that have been
forwarded to the receiver over a given period of time, the volume of
multicast-formatted data that have been exchanged between a receiver
(or set of) and a given source over a given period of time (e.g. the
duration of a multicast session), etc.
Authentication: action for identifying a user as a genuine one. Authentication: action for identifying a user as a genuine one.
Authorization: action for giving permission to access the content or Authorization: The set of capabilities that need to be activated to
network to a user. make sure a given requesting customer is (1) what he claims to be
(identification purposes), and (2) is 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. A
receiver may be distinguishable by a network ID such as MAC address receiver may be identified by a network ID such as MAC address or IP
or IP address. 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 multiple
reception devices. Multiple users may use the same reception device. reception devices. Multiple users may use the same reception device.
Note: The definition of a receiver (device) and a user (human) should Note: The definition of a receiver (device) and a user (human)
not be confused. should not be confused.
2.2 Abbreviations 2.2 Abbreviations
For the purposes 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
CDN: Content Delivery Network CDN: Content Delivery Network
CDS: Content Delivery Services CDS: Content Delivery Services
CP: Content Provider CP: Content Provider
NSP: Network Service Provider NSP: Network Service Provider
TP: Transit Provider TP: Transit Provider
3. Framework and Roles of Entities 3. Common use models and network architecture implications
3.1 Framework for multicast AAA allowing bandwidth Management In some cases a single entity may design and be responsible for a
system that covers the various common high-level requirements of a
multicasting system such as 1) content serving, 2) the
infrastructure to multicast it, 3) network and content access
control mechanisms. In many cases however the content provision and
network provision roles are divided between separate entities. The
MACCNT-REQ-draft provides more detail of the multiple versus single
entity CDS network model.
As such it should not be assumed that the entity responsible for the
multicasting structure and the entity responsible for content
serving are the same. Indeed because the infrastructure for
multicasting is expensive and many content holders are not likely to
be competent at building and maintaining complicated infrastructures
necessary for multicasting, many content holders would prefer to
purchase transport and management services from a network service
provider and thus share the infrastructure costs with other content
holders.
Similarly network service providers in many cases do not specialize
in providing content and are unlikely to build and maintain such a
resource-intensive system without a certain level of demand from
content holders.
The use model of a single NSP providing multicasting services to
multiple CPs the following general requirements from MACCNT-REQ-
draft apply:
-Need for user tracking and billing capabilities
-Need for network access control and/or content access control
satisfactory to the requirements of the CP
-Methods for sharing information between the NSP and CP to make
the above two possible
When the NSP and CP are the same single entity the general
requirements are as follows.
-Need for user tracking and user-billing capabilities
-Need for access control and/or content protection at level the
entity deems appropriate
4. Framework and Roles of Entities
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 |
+------------------------------+ +------------------------------+
skipping to change at page 5, line 31 skipping to change at page 6, line 26
+------------------------------+ +------------------------------+
| Access ^ Response | Access ^ Response
| Request | (Success) | Request | (Success)
v | v |
+------------------------------+ +------------------------------+
| CP | | CP |
| | | |
+------------------------------+ +------------------------------+
For the sake of simplicity, the above diagram portrays a case where For the sake of simplicity, the above diagram portrays a case where
there is a single NSP entity and a single CP entity. Under the there is a single NSP entity and a single CP entity, but multiple
framework it is possible for there to be multiple CPs connected to CPs can be connected to the same NSP. It is also possible for the
the same NSP. It is also possible for the same CP to be connected to same CP to be connected to multiple NSP networks (e.g. network
multiple NSP networks (e.g. network selection). In other words the selection). In other words the relationship of NSP:CP can be
relationship of NSP:CP can be described as 1:1, 1:N or M:N. described as 1:1, 1:N or M:N. Furthermore it is possible that the
Furthermore it is possible that the NSP and CP could be the same NSP and CP could be the same entity.
entity.
Description of Roles: Description of Roles:
The user selects a CP and a NSP when the user requests content. The The user (or the user's device) selects a CP and a NSP when the user
NSP may be automatically selected by a user terminal: e.g. a fixed requests content. The NSP may be automatically selected by a user
line NSP for STB or a mobile NSP for mobile phone. terminal: e.g. a fixed line NSP for STB or a mobile NSP for mobile
phone. In some usage cases it is possible that the NSP used by the
user terminal will not always be the same. For example a user may
have contracted 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 of users'
access to content that the CP manages. The CP hopes to collect access to content that the CP manages. The CP hopes to collect
accounting information related to the access of their content. The CP accounting information related to the access of their content. The
may choose to authenticate and authorize NSPs which are eligible to CP may choose to authenticate and authorize NSPs which are eligible
provide users access to its contents. When the CP cannot or decides to provide users access to its contents. When the CP cannot (e.g.
not to provide content to be multicast to users, the CP is error or resource issues) or decides not (e.g. policy issues) to
responsible for notifying the NSP of the reason. deliver content, the CP is responsible for notifying the 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. The NSP
may perform admission control to protect bandwidth resource and needs may perform admission control. It is also responsible for relaying
authorized information regarding user access for bandwidth the AAA messages from the CP whether the user is eligible to receive
management. content (authentication by proxy), and the NSPs relevant AAA server
It is also responsible for confirming (authentication by proxy) with will make the final decision of whether the connection can be
the CP whether the user is eligible to receive content. When the NSP established. When the NSP cannot or decides not to multicast to
cannot or decides not to multicast to users, the NSP is responsible users, the NSP is responsible for notifying the users of the reason.
for notifying the users of the reason.
In addition to the three basic entities of user, NSP and CP, this AAA
framework for multicasting supports transit provision which transfers
multicast streams from the CP to the NSP.
3.2 Multiple User IDs 4.2 Multiple User IDs
Users may be assigned separate user IDs for each subscription for Users may hold multiple user IDs: IDs which have been separately
various NSPs and CPs. When the user wants to access content or assigned for each subscription they may have for various NSPs and
otherwise use the network, the user registers the corresponding user CPs. When the user wants to access content or otherwise use the
ID with a request for content, etc: web authentication is one network, the user registers the corresponding user ID with a request
possible method. for content, etc: web authentication is one possible method.
Terminal portability can be realized if the NSP authenticates a user Terminal portability can be realized if the NSP authenticates a user
using a user ID. This allows the user to access the content from using a user ID. This allows the user to access the content from
various network access points. various network access points.
Each CP may identify users by the user IDs it has issued to them. Each CP may identify users by the user IDs that it has issued to
them.
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 id for the
same user in the other provider's domain, and it is not necessary same user in the other provider's domain, and it is not necessary
that there is a one to one relationship. It is quite possible for that there is a one to one relationship. It is quite possible for
one person to hold multiple user ids for the same provider. one person to hold multiple user ids for the same provider.
3.3 Accounting 4.3 Accounting
The NSP should not manage multicast states on a subnet basis, but on MACCNT-REQ-draft defines requirements for Accounting and Billing.
a user basis because the NSP needs to notify start and stop times for These include the requirement for the NSP to log user behavior such
accounting purposes. This means that the NSP sends an indication for as the join action and the leave action, as well as the result of
Join and Leave on a user basis. the access-control decision. (MACCNT-REQ-draft, 4.5) MACCNT-REQ-
draft also specifies that there should be a standardized format for
sharing with the CP the user behavior and content reception
information which the NSP is logging.(MACCNT-REQ-draft, 4.5.1)
The NSP should log both user and host information for each join and In order to provide the granularity of user-behavior and actual
leave, indicating the corresponding multicast source for each action. content reception information as specified in MACCNT-REQ-draft, the
It is important that such log use a standard format so that it can be NSP should not manage multicast states on a subnet basis, but on a
shared with the CP. Intermittent logs between the join and leave user basis (see in MACCNT-REQ-draft, 4.1 "User identification")
also could serve useful in billing discrepancies, and disconnects because the NSP needs to be able to notify the CP of a user's start
without leaves. Ideally a solution would also provide standard ways and stop times for accounting purposes. This means that the NSP
for the NSP to share logged information with the CP. When shared it sends to the CP AAA an indication for Join and Leave on a user basis.
is important that the CP be able to match the user to the user within
its domain.
3.4 Access Control and CP selection by NSP 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
information for each join and leave, indicating the corresponding
multicast source for each action. When either a CP source stops
sending, or the NSP stops multicasting, in an unsolicited manner,
there is also a need to notify the AAA servers accordingly about the
users who are impacted by this event.
Also, intermittent logs between the join and leave would allow for
finer diagnostics and therefore could serve useful in billing
discrepancies, and provide for a better estimation of the time span
that content was multicasted in the even that users disconnect
without sending leave messages.
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 necessary
for the NSP to determine to which CP the request is directed. It is for the NSP to determine to which CP the request is to be directed.
necessary for the NSP to ensure that it is not spoofed by an It is necessary for the NSP to ensure that it is not spoofed by an
inappropriate CP. inappropriate CP or user.
3.5 Network Resource Management by NSP 4.5 API for Admission Control Information by NSP
After authorizing a user request, the NSP may conduct admission After authorizing a user request, the NSP may have further
control based on its bandwidth management policy. For example, if the conditions for determining its admission control decision. MACCNT-
NSP manages the shared bandwidth of access lines, the NSP might REQ-draft defines requirements for providing the network capability
calculate available bandwidth and necessary bandwidth, and based on to conduct admission control based on the network bandwidth usage
these calculations determine to accept or reject a user request. status and bandwidth management policy. (MACCNT-REQ-draft, 4.2.2,
4.2.3 & 4.9) Such QoS measurement and policy mechanisms themselves
are out of the scope of this memo. However the NSP's AAA Server
should be provided with an Admission control API that allows for
interfacing so that additional conditions can be added to the
admission control decision.
3.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 user, as
well as authenticate and authorize the request. well as authenticate and authorize the request.
3.7 Caching of AAA results 4.7 Caching of AAA results
An NSP should be able to cache AAA results based an understanding An NSP should be able to cache AAA results based upon an agreement
between the NSP and a CP. The AAA cache would store information between the NSP and a CP. The AAA cache would store information
about permissions of a specific user to receive multicast data from about permissions of a specific user to receive multicast data from
specified channel(s) up to specified expiration date(s) and time(s). specified channel(s) up to specified expiration date(s) and time(s).
If such caching is implemented, a method must exist for the CP to If such caching is implemented, a method must exist for the CP to
communicate this permission information to the NSP. The NSP refers communicate this permission information to the NSP. The NSP refers
to the AAA cache and if the cache indicates that the user has to the AAA cache and if the cache indicates that the user has
permission to receive multicast data from a specific channel at that permission to receive multicast data from a specific channel at that
time, the NSP may forward the data without querying the CP. time, the NSP may forward the data without querying the CP.
It should be possible for a CP to send a directive to the NSP to It should be possible for a CP to send unsolicited requests to the
refresh or change permissions for a user for specific channel(s). NSP to refresh or change the permissions for a user for specific
channel(s).
It is necessary for the NSP to requery the CP for authorization
should a user be receiving content when the permission expires.
It would be desirable to have a mechanism by which CPs could When a user is receiving multicast content and the permission is
proactively push permission information to the cache even when not about to expire, the NSP may send a notification to the user client
specifically queried by the NSP. that his session is about to expire, and that he will need to re-
connect. The user will have to reestablish a connection. In the
case that the user still has permission to the content, they should
be able to continue to receive the content without interruption.
4. 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 multicasting.
This section provides more detail on the network connection model and This section provides more detail on the network connection model
constituent functional components. and constituent functional components.
5.1 Basic Connection Model
4.1 Basic Connection Model
+-------------+ +-------------+
| user | | user |
| | | |
+-------------+ +-------------+
^ Access & Resource ^ Access & Resource
| Request | Request
v v
+-------------+ +-------------+
| NSP | | NSP |
| | | |
+-------------+ +-------------+
^ Access ^ Access
| Request | Request
v v
+-------------+ +-------------+
| CP | | CP |
| | | |
+-------------+ +-------------+
First a user desiring authorization sends an Access request to an NSP First a user that requests content sends an Access request to an NSP
which then forwards it on to the appropriate CP for Authentication which then forwards it on to the appropriate CP for Authentication
and Authorization. The CP responds with either "success" or and Authorization purposes. The CP responds with either "success" or
"failure". If "success", the NSP may forward a success response "failure". If "success", the NSP may forward a success response and
and stream multicast data to the user. stream multicast data to the user.
In this model the user selects the NSP to which to send its content 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 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: 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. it may not respond to another NSP in regards to the request.
In this model, as described in section 3.1, the relationship between 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 NSP and CP can be 1:1, 1:N or M:N. Users may connect to multiple
networks, and networks have multiple users. networks, and networks have multiple users.
4.2 Transit Provision 5.2 Transit Provision
The diagram below shows that a Transit Provider(hereafter, TP) may The diagram below shows that a Transit Provider(hereafter, TP) may
relay requests between NSPs and CPs. relay requests between NSPs and CPs.
+-------------+ +-------------+
| user | | user |
| | | |
+-------------+ +-------------+
^ Access & Resource ^ Access & Resource
| Request | Request
skipping to change at page 9, line 43 skipping to change at page 11, line 43
| | | |
+-------------+ +-------------+
For the sake of simplification the above diagram shows a 1-1 For the sake of simplification the above diagram shows a 1-1
relationship between an NSP and a TP. However it is also possible relationship between an NSP and a TP. However it is also possible
for a single NSP to connect to multiple TPs, and a single TP to for a single NSP to connect to multiple TPs, and a single TP to
multiple NSPs. multiple NSPs.
A single TP may connect to one or more CPs. Similarly just as a A single TP may connect to one or more CPs. Similarly just as a
single CP may connect to multiple NSPs (as described in the general single CP may connect to multiple NSPs (as described in the general
high-level framework, section 3.1), a single CP may connect to one or high-level framework, section 3.1), a single CP may connect to one
more TPs. or more TPs.
A solution will include a mechanism through which the NSPs know which A solution will include a mechanism through which the NSPs know
TP(s) are to be used to communicate with which CP(s), and CPs know which TP(s) are to be used to communicate with which CP(s), and CPs
which TP(s) to use for which NSP(s). When a TP receives an access or know which TP(s) to use for which NSP(s). When a TP receives an
resource request from an NSP or CP, it must relay the request to the access or resource request from an NSP or CP, it must relay the
correct CP or NSP, respectively. Minimally, this means that it must request to the correct CP or NSP, respectively. Minimally, this
reconstruct the request with translated address information. In this means that it must reconstruct the request with translated address
model therefore a TP must understand the format and meaning of the information. In this model therefore a TP must understand the
requests. format and meaning of the requests.
There may be multiple TPs between a NSP and CP so that a TP is There may be multiple TPs between a NSP and CP so that a TP is
actually receiving from and/or sending requests to another TP and not actually receiving from and/or sending requests to another TP and
directly from/to a NSP or CP. not directly from/to a NSP or CP.
4.3 Transit with Tunnels 5.3 Transit with Tunnels
In addition to the above model of request relaying, a TP may In addition to the above model of request relaying, a TP may
communicate requests through tunneling based on the contract between communicate requests through tunneling based on the contract between
the TP and the NSP and/or between the TP and the CP. So in this case the TP and the NSP and/or between the TP and the CP. So in this
the TP will not directly need to process the contents of the access case the TP will not directly need to process the contents of the
and resource request (such as, header information), but instead pass access and resource request (such as, header information), but
the request directly to the correct NSP or CP, using a separate instead pass the request directly to the correct NSP or CP, using a
protocol to wrap the original requests. separate protocol to wrap the original requests.
Below is a diagram, representing how a TP can provider tunneling Below is a diagram, representing how a TP can provide tunneling
between NSP(s) and CP(s). between NSP(s) and CP(s).
+-----------------+ +-----------------+
| user | | user |
| | | |
+-----------------+ +-----------------+
^ Access & Resource ^ Access & Resource
| Request | Request
v v
+------------------+ +------------------+
skipping to change at page 11, line 5 skipping to change at page 13, line 5
|:| |:|
|V| |V|
+------------------+ +------------------+
| CP | | CP |
| | | |
+------------------+ +------------------+
In this model too, the relationship between NSP and TP and between In this model too, the relationship between NSP and TP and between
transit provider and CP can be 1:1, 1:N or M:N. transit provider and CP can be 1:1, 1:N or M:N.
4.4 Constituent Logical Functional Components of the fully enabled AAA 5.4 Constituent Logical Functional Components of the fully enabled AAA
Framework Framework
Section 3.1 introduces the high-level AAA framework for multicasting. Section 3.1 introduces the high-level AAA framework for multicasting.
Below is a diagram of a fully enabled multicasting network with AAA, Below is a diagram of a fully enabled multicasting network with AAA,
including the logical components within the various entities. including the logical components within the various entities.
+-------------------------------+ +-------------------------------+
| user | | user |
| | | |
+-------------------------------+ +-------------------------------+
skipping to change at page 11, line 40 skipping to change at page 13, line 40
| CP | | CP |
| | | |
| +---------+ | | +---------+ |
| | AAA | | | | AAA | |
| +---------+ | | +---------+ |
+------------------------------+ +------------------------------+
In the fully enabled model the NSP provides proxying of In the fully enabled model the NSP provides proxying of
authentication and authorization between the NSP and CP, as well as authentication and authorization between the NSP and CP, as well as
user-based accounting. The AAA proxy server of the NSP communicates user-based accounting. The AAA proxy server of the NSP communicates
with the CP's AAA server. Although not show in the above diagram for with the CP's AAA server. Although not shown in the above diagram
the sake of simplicity, in addition to direct proxying between a NSP for the sake of simplicity, in addition to direct proxying between a
and CP, this proxying may be done through a TP. This means that the NSP and CP, this proxying may be done through a TP. This means that
transit provider too is able to support AAA proxying. the transit provider is also cable of supporting AAA proxying.
In the fully enabled model the NSP also includes a component that In the fully enabled model the NSP also includes a component that
provides network resource management (e.g. QoS management), as provides network resource management (e.g. QoS management), as
described in section 3.4, "Network Resource Management by NSP". When described in section 3.4, "Network Resource Management by NSP".
a transit provider is used it may also provide Network Resource When a transit provider is used it may also provide Network Resource
management of its own resources. management of its own resources.
4.5 Modularity of the framework 5.5 Modularity of the framework
In the interest of flexibility, this framework is modular so that it In the interest of flexibility, this framework is modular so that it
is possible that partially enabled versions of the models are is possible that partially enabled versions of the models are
supported. A AAA-enabled version provides AAA functionality without supported. A AAA-enabled version provides AAA functionality without
Network Resource management. A Network-Resource-Management-enabled Network Resource management. A Network-Resource-Management-enabled
(QoS-enabled) version provides Network Resource management without (QoS-enabled) version provides Network Resource management without
AAA functionality. Similarly, the possibility of one or more layers AAA functionality. Similarly, the possibility of one or more layers
of transit provision between an NSP and CP is in the interest of of transit provision between an NSP and CP is in the interest of
modularity and extendibility. modularity and extendibility.
5. IANA considerations 6. IANA considerations
This memo does not raise any IANA consideration issues. This memo does not raise any IANA consideration issues.
6. 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 should be protected in some way. authentication with the CP must be protected in some way. Otherwise,
Otherwise, this memo does not raise any new security issues which are this memo does not raise any new security issues which are not
not already existing in the original protocols. Enhancement of already addressed by the original protocols. Enhancement of
multicast access control capabilities may enhance security multicast access control capabilities should enhance security
performance. performance.
7. Conclusion 8. Conclusion
This memo provides a generalized framework for solution standards to This memo provides a generalized framework for solution standards to
meet the requirements presented in MACCNT-REQ-draft. Further work meet the requirements presented in MACCNT-REQ-draft. Further work
should be done to break down the content provider and network service should be done to break down the content provider and network
provider entities into their functional objects such as edge devices, service provider entities into their functional objects such as edge
AAA servers, etc. devices, AAA servers, etc.
Normative References Normative References
[1] Hayashi, et. al., "Accounting, Authentication and Authorization [1] Hayashi, et. al., "Accounting, Authentication and Authorization
Issues in Well Managed IP Multicasting Services", draft-ietf- Issues in Well Managed IP Multicasting Services", draft-ietf-
mboned-maccnt-req-04.txt, February 2006, Work in Progress. mboned-maccnt-req-04.txt, February 2006, Work in Progress.
[2] Hayashi, et. al., "Issues Related to Receiver Access Control in
the Current Multicast Protocols", draft-ietf-mboned-rac-issues-
03.txt, April 2006, 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 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
France Telecom
3, avenue Francois Chateau
CS 36901, 35069 Rennes Cedex, France
Phone: +33 2 99 87 63 31
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
skipping to change at page 14, line 13 skipping to change at page 16, line 13
group's mailing list at mboned@lists.uoregon.edu_and/or the authors. group's mailing list at mboned@lists.uoregon.edu_and/or the authors.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed
pertain to the implementation or use of the technology described in to pertain to the implementation or use of the technology described
this document or the extent to which any license under such rights in this document or the extent to which any license under such
might or might not be available; nor does it represent that it has rights might or might not be available; nor does it represent that
made any independent effort to identify any such rights. Information it has made any independent effort to identify any such rights.
on the procedures with respect to rights in RFC documents can be Information on the procedures with respect to rights in RFC
found in BCP 78 and BCP 79. documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use
such proprietary rights by implementers or users of this of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository
http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Expiration Expiration
This Internet-Draft will expire on December 25, 2006. This Internet-Draft will expire on April 26, 2007.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 66 change blocks. 
203 lines changed or deleted 300 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/