draft-ietf-mboned-multiaaa-framework-00.txt   draft-ietf-mboned-multiaaa-framework-01.txt 
Hiroaki Satou, NTT Hiroaki Satou, NTT
Internet Draft Hiroshi Ohta, NTT Internet Draft Hiroshi Ohta, NTT
Expires: October 6, 2006 Tsunemasa Hayashi, NTT Expires: December 25, 2006 Tsunemasa Hayashi, NTT
Haixiang He, Nortel Networks Haixiang He, Nortel Networks
April 4, 2006 June 23, 2006
AAA Framework for Multicasting AAA Framework for Multicasting
<draft-ietf-mboned-multiaaa-framework-00.txt> <draft-ietf-mboned-multiaaa-framework-01.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- other groups may also distribute working documents as Internet-Drafts.
Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
at any time. It is inappropriate to use Internet-Drafts as time. It is inappropriate to use Internet-Drafts as reference
reference material or to cite them other than as "work in progress." 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 October 6, 2006. This Internet-Draft will expire on December 25, 2006.
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 This memo provides a generalized framework for solution standards to
meet the requirements presented in draft-ietf-mboned-maccnt-req- meet the requirements presented in draft-ietf-mboned-maccnt-req-
04.txt, "Requirements for Accounting, Authentication and 04.txt, "Requirements for Accounting, Authentication and
Authorization in Well Managed IP Multicasting Services". In this Authorization in Well Managed IP Multicasting Services". In this
framework a user sends a request for multicast data to a network framework a user sends a request for multicast data to a network
service provider. The network service provider selects the service provider. The network service provider selects the
appropriate content provider to send the user's request. The appropriate content provider to send the user's request. The request
request is sent by the network service provider to the content is sent by the network service provider to the content provider
provider transparently in a way so that the network service provider transparently in a way so that the network service provider and
and content provider do not need to know the corresponding user id content provider do not need to know the corresponding user id for
for the same user in the other provider's domain. The content the same user in the other provider's domain. The content provider
provider then responds with an indication of "success" or "failure" then responds with an indication of "success" or "failure" to the
to the network provider and in the case of "success", the network network provider and in the case of "success", the network provider
provider may delivery the requested data to the user. The network may delivery the requested data to the user. The network service may
service may base its decision to deliver such data to the user based base its decision to deliver such data to the user based on its
on its bandwidth management policy. The framework is designed to be bandwidth management policy. The framework is designed to be
flexible and extendible, so it will be possible to implement flexible and extendible, so it will be possible to implement
partially enabled versions as well as fully enabled versions of the partially enabled versions as well as fully enabled versions of the
model. Also an additional entity may provide transit of requests model. Also an additional entity may provide transit of requests
between network service providers and content providers, either between network service providers and content providers, either
through relaying or tunneling. through relaying or tunneling.
1. Introduction 1. Introduction
1.1 Purpose and Background 1.1 Purpose and Background
skipping to change at page 3, line 4 skipping to change at page 2, line 40
model. Also an additional entity may provide transit of requests model. Also an additional entity may provide transit of requests
between network service providers and content providers, either between network service providers and content providers, either
through relaying or tunneling. 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 where a single source of IP multicasting is designed to serve cases where a single source of
data content is to be concurrently streamed to multiple recipients. data content is to be concurrently streamed to multiple recipients.
In these types of cases, multicasting provides resource efficiencies In these types of cases, multicasting provides resource efficiencies
(both for the overall network and the content server) relative to (both for the overall network and the content server) relative to
unicasting. These efficiencies are possible because of the unicasting. These efficiencies are possible because of the avoidance
avoidance of unnecessary duplication of streams, video/audio of unnecessary duplication of streams, video/audio processing, etc.
processing, etc. Multicasting also provides resource efficiencies Multicasting also provides resource efficiencies relative to IP
relative to IP broadcasting in that content data is only delivered broadcasting in that content data is only delivered to end hosts
to end hosts which request it. which request it.
There are many real-life situations where IP multicasting is There are many real-life situations where IP multicasting is selected
selected as the technology used for concurrent content delivery of as the technology used for concurrent content delivery of identical
identical content data to multiple end-hosts. "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", (draft-ietf-mboned-maccnt-req-04.txt, Services", (draft-ietf-mboned-maccnt-req-04.txt, hereafter MACCNT-
hereafter MACCNT-REQ-draft) describes the requirements in CDN REQ-draft) describes the requirements in CDN services using IP
services using IP multicast[1]. "Issues Related to Receiver Access multicast[1]. "Issues Related to Receiver Access Control in the
Control in the Current Multicast Protocols" (draft-ietf-mboned-rac- Current Multicast Protocols" (draft-ietf-mboned-rac-issues-03.txt,
issues-02.txt, hereafter RAC-ISSUES-draft) discusses the hereafter RAC-ISSUES-draft) discusses the requirements and existing
requirements and existing support for commercial, large-scale support for large-scale, multi-entity content delivery services[2].
content delivery[2]. The requirements are derived from: 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 and/or content access control
to satisfy the requirements of the CP to satisfy the requirements of the 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
skipping to change at page 4, line 17 skipping to change at page 4, line 15
Authorization: action for giving permission to access the content or Authorization: action for giving permission to access the content or
network to a user. network to a user.
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 distinguishable by a network ID such as MAC address
or IP 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 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) Note: The definition of a receiver (device) and a user (human) should
should not be confused. not be confused.
2.2 Abbreviations 2.2 Abbreviations
For the purposes of this draft the following abbreviations apply: For the purposes 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. Issues in multicasting related to commercial and large-scale 3. Framework and Roles of Entities
implementations
This section lists issues related to receiver access control in
current multicasting protocols which are especially important to
commercial, large-scale multicasting. More details concerning the
requirements related to these issues are provided in MACCNT-REQ-
draft. References to that memo are provided as applicable below.
3.1 Framework for multicast AAA allowing bandwidth Management 3.1 Framework for multicast AAA allowing bandwidth Management
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
skipping to change at page 5, line 45 skipping to change at page 5, line 47
entity. entity.
Description of Roles: Description of Roles:
The user selects a CP and a NSP when the user requests content. The The user selects a CP and a NSP when the user requests content. The
NSP may be automatically selected by a user terminal: e.g. a fixed NSP may be automatically selected by a user terminal: e.g. a fixed
line NSP for STB or a mobile NSP for mobile phone. line NSP for STB or a mobile NSP for mobile phone.
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. accounting information related to the access of their content. The CP
may choose to authenticate and authorize NSPs which are eligible to
provide users access to its contents. When the CP cannot or decides
not to provide content to be multicast to users, the CP is
responsible for notifying the NSP of the reason.
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 may perform admission control to protect bandwidth resource and needs
needs authorized information regarding user access for bandwidth authorized information regarding user access for bandwidth
management. It is also responsible for confirming (authentication by management.
proxy) with the CP whether the user is eligible to receive content. It is also responsible for confirming (authentication by proxy) with
the CP whether the user is eligible to receive content. When the NSP
In addition to the three basic entities of user, NSP and CP, this cannot or decides not to multicast to users, the NSP is responsible
AAA framework for multicasting supports transit provision which for notifying the users of the reason.
transfers multicast streams from the CP to the NSP. 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 3.2 Multiple User IDs
Users may be assigned separate user IDs for each subscription for Users may be assigned separate user IDs for each subscription for
various NSPs and CPs. When the user wants to access content or various NSPs and CPs. When the user wants to access content or
otherwise use the network, the user registers the corresponding user otherwise use the network, the user registers the corresponding user
ID with a request for content, etc: web authentication is one ID with a request for content, etc: web authentication is one
possible method. 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 that it has issued to Each CP may identify users by the user IDs it has issued to them.
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 Access Control and CP selection by NSP 3.3 Accounting
The NSP should not manage multicast states on a subnet basis, but on
a user basis because the NSP needs to notify start and stop times for
accounting purposes. This means that the NSP sends an indication for
Join and Leave on a user basis.
The NSP should log both user and host information for each join and
leave, indicating the corresponding multicast source for each action.
It is important that such log use a standard format so that it can be
shared with the CP. Intermittent logs between the join and leave
also could serve useful in billing discrepancies, and disconnects
without leaves. Ideally a solution would also provide standard ways
for the NSP to share logged information with the CP. When shared it
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
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 directed. It is
necessary for the NSP to ensure that it is not spoofed by an necessary for the NSP to ensure that it is not spoofed by an
inappropriate CP. inappropriate CP.
3.4 Network Resource Management by NSP 3.5 Network Resource Management by NSP
After authorizing a user request, the NSP may conduct admission After authorizing a user request, the NSP may conduct admission
control based on its bandwidth management policy. For example, if control based on its bandwidth management policy. For example, if the
the NSP manages the shared bandwidth of access lines, the NSP might NSP manages the shared bandwidth of access lines, the NSP might
calculate available bandwidth and necessary bandwidth, and based on calculate available bandwidth and necessary bandwidth, and based on
these calculations determine to accept or reject a user request. these calculations determine to accept or reject a user request.
3.5 Access Control and Distinguishing of Users by CP 3.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.6 Multicast Session Management for Accounting 3.7 Caching of AAA results
The NSP should not manage multicast states on a subnet basis, but on An NSP should be able to cache AAA results based an understanding
a user basis because the NSP needs to notify start and stop times between the NSP and a CP. The AAA cache would store information
for accounting purposes. This means that the NSP sends an indication about permissions of a specific user to receive multicast data from
for Join and Leave on a user basis. 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
communicate this permission information to the NSP. The NSP refers
to the AAA cache and if the cache indicates 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 a directive to the NSP to
refresh or change 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
proactively push permission information to the cache even when not
specifically queried by the NSP.
4. Network Connection Model and Functional Components 4. 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 This section provides more detail on the network connection model and
and constituent functional components. constituent functional components.
4.1 Basic Connection Model 4.1 Basic Connection Model
+-------------+ +-------------+
| user | | user |
| | | |
+-------------+ +-------------+
^ Access & Resource ^ Access & Resource
| Request | Request
v v
+-------------+ +-------------+
| NSP | | NSP |
| | | |
skipping to change at page 8, line 26 skipping to change at page 8, line 23
| | | |
+-------------+ +-------------+
^ Access ^ Access
| Request | Request
v v
+-------------+ +-------------+
| CP | | CP |
| | | |
+-------------+ +-------------+
First a user desiring authorization sends an Access request to an First a user desiring authorization sends an Access request to an NSP
NSP which then forwards it on to the appropriate CP for which then forwards it on to the appropriate CP for Authentication
Authentication and Authorization. The CP responds with either and Authorization. The CP responds with either "success" or
"success" of "failure". If "success", the NSP may forward a success "failure". If "success", the NSP may forward a success response
response and stream multicast data to the user. and 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.
skipping to change at page 9, line 43 skipping to change at page 9, 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 high-level framework, section 3.1), a single CP may connect to one or
or more TPs. more TPs.
A solution will include a mechanism through which the NSPs know A solution will include a mechanism through which the NSPs know which
which TP(s) are to be used to communicate with which CP(s), and CPs TP(s) are to be used to communicate with which CP(s), and CPs know
know which TP(s) to use for which NSP(s). When a TP receives an which TP(s) to use for which NSP(s). When a TP receives an access or
access or resource request from an NSP or CP, it must relay the resource request from an NSP or CP, it must relay the request to the
request to the correct CP or NSP, respectively. Minimally, this correct CP or NSP, respectively. Minimally, this means that it must
means that it must reconstruct the request with translated address reconstruct the request with translated address information. In this
information. In this model therefore a TP must understand the model therefore a TP must understand the format and meaning of the
format and meaning of the requests. 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 actually receiving from and/or sending requests to another TP and not
not directly from/to a NSP or CP. directly from/to a NSP or CP.
4.3 Transit with Tunnels 4.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 the TP and the NSP and/or between the TP and the CP. So in this case
case the TP will not directly need to process the contents of the the TP will not directly need to process the contents of the access
access and resource request (such as, header information), but and resource request (such as, header information), but instead pass
instead pass the request directly to the correct NSP or CP, using a the request directly to the correct NSP or CP, using a separate
separate protocol to wrap the original requests. 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 provider tunneling
between NSP(s) and CP(s). between NSP(s) and CP(s).
+-----------------+ +-----------------+
| user | | user |
| | | |
+-----------------+ +-----------------+
^ Access & Resource ^ Access & Resource
| Request | Request
skipping to change at page 11, line 40 skipping to change at page 11, 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 with the CP's AAA server. Although not show in the above diagram for
for the sake of simplicity, in addition to direct proxying between a the sake of simplicity, in addition to direct proxying between a NSP
NSP and CP, this proxying may be done through a TP. This means that and CP, this proxying may be done through a TP. This means that the
the transit provider too is able to support AAA proxying. transit provider too is able to support 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". described in section 3.4, "Network Resource Management by NSP". When
When a transit provider is used it may also provide Network Resource 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 4.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 5. IANA considerations
This memo does not raise any IANA consideration issues. This memo does not raise any IANA consideration issues.
6. Security considerations 6. 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 should 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 which are
are not already existing in the original protocols. Enhancement of not already existing in the original protocols. Enhancement of
multicast access control capabilities may enhance security multicast access control capabilities may enhance security
performance. performance.
7. Conclusion 7. 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 should be done to break down the content provider and network service
service provider entities into their functional objects such as edge provider entities into their functional objects such as edge devices,
devices, AAA servers, etc. 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 [2] Hayashi, et. al., "Issues Related to Receiver Access Control in
the Current Multicast Protocols", draft-ietf-mboned-rac-issues- the Current Multicast Protocols", draft-ietf-mboned-rac-issues-
02.txt, March 2006, Work in Progress. 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
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: hayashi.tsunemasa@lab.ntt.co.jp 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
skipping to change at page 14, line 13 skipping to change at page 14, 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 This document and the information contained herein are provided on an
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 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 Intellectual Property Rights or other rights that might be claimed to
to pertain to the implementation or use of the technology described pertain to the implementation or use of the technology described in
in this document or the extent to which any license under such this document or the extent to which any license under such rights
rights might or might not be available; nor does it represent that might or might not be available; nor does it represent that it has
it has made any independent effort to identify any such rights. made any independent effort to identify any such rights. Information
Information on the procedures with respect to rights in RFC on the procedures with respect to rights in RFC documents can be
documents can be found in BCP 78 and BCP 79. 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 attempt made to obtain a general license or permission for the use of
of such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository at
at http://www.ietf.org/ipr. 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 October 6, 2006. This Internet-Draft will expire on December 25, 2006.
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. 38 change blocks. 
124 lines changed or deleted 151 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/