draft-ietf-mboned-maccnt-req-01.txt   draft-ietf-mboned-maccnt-req-02.txt 
Tsunemasa Hayashi, NTT Tsunemasa Hayashi, NTT
Internet Draft Haixiang He, Nortel Internet Draft Haixiang He, Nortel
Document:draft-ietf-mboned-maccnt-req-01.txt Hiroaki Satou, NTT Document:draft-ietf-mboned-maccnt-req-02.txt Hiroaki Satou, NTT
Expires: April 15, 2006 Hiroshi Ohta, NTT Expires: June 18, 2006 Hiroshi Ohta, NTT
Susheela Vaidya, Cisco Systems Susheela Vaidya, Cisco Systems
October 12, 2005 December 15, 2005
Accounting, Authentication and Authorization Issues in Well Managed Requirements for Accounting, Authentication and Authorization in
IP Multicasting Services Well Managed IP Multicasting Services
<draft-ietf-mboned-maccnt-req-01.txt> <draft-ietf-mboned-maccnt-req-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- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 38
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." 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 April 15, 2006. This Internet-Draft will expire on June 18, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005) Copyright (C) The Internet Society (2005)
Abstract Abstract
This Internet Draft (I-D) describes problems in the area of
accounting and access control for multicasting. General This memo presents requirements in the area of accounting and
requirements for accounting capabilities including quality-of- access control for multicasting. General requirements for
service (QoS) related issues are listed. This I-D assumes that accounting capabilities including quality-of-service (QoS) related
these capabilities can be realized by functions implemented at issues are listed. This I-D assumes that these capabilities can be
edges of a network based on IGMP or MLD. By such functions, realized by functions implemented at edges of a network based on
information obtained from edge routers would be logged in a IGMP or MLD. Finally, cases for Content Delivery Services (CDS)
dedicated database. Finally, cases for Content Delivery Services are described as application examples which could benefit from
(CDS) are described as application examples which could benefit multicasting accounting and access control capabilities as
from multicasting accounting and access control capabilities as
described in the I-D. It is proposed that this I-D be used as a described in the I-D. It is proposed that this I-D be used as a
starting point for further discussion on these issues. starting point for further discussion on these issues.
Table of contents Table of contents
Copyright Notice.................................................1 Copyright Notice.................................................1
1. Introduction..................................................3 1. Introduction..................................................2
2. Definitions and Abbreviations.................................4 2. Definitions and Abbreviations.................................4
2.1 Definitions..................................................4 2.1 Definitions..................................................4
2.2 Abbreviations................................................4 2.2 Abbreviations................................................4
3. Problem statement.............................................5 3. Problem statement.............................................5
3.1 Accounting issues...........................................5 3.1 Accounting issues...........................................5
3.2 Relationship with secure multicasting (MSEC)................6 3.2 Relationship with secure multicasting (MSEC)................6
4. Functional general requirements for well managed IP multicasting 4. General functional requirements for well managed IP
.................................................................6 multicasting..................................................6
5. Application example and its specific requirements............10 5. Application example and its specific requirements............10
5.1 IP Multicast-based Content Delivery Service (CDS): CP and NSP 5.1 IP Multicast-based Content Delivery Service (CDS): CP and
are different entities (companies)..............................10 NSP are different entities (companies)......................10
5.1.1 Network model for Multicast Content Delivery Service......10 5.1.1 Network model for Multicast Content Delivery Service......10
5.1.2 Content Delivery Service Requirements.....................12 5.1.2 Content Delivery Service Requirements.....................12
5.1.2.1 Accounting Requirements.................................12 5.1.2.1 Accounting Requirements.................................12
5.1.2.2 Authorization Requirements..............................13 5.1.2.2 Authorization Requirements..............................13
5.1.2.3 Authentication Requirements.............................13 5.1.2.3 Authentication Requirements.............................13
5.2 IP Multicast-based Content Delivery Service (CDS): CP and NSP 5.2 IP Multicast-based Content Delivery Service (CDS): CP and
are the same entities (companies)...............................14 NSP are the same entities (companies).......................14
6. IANA considerations..........................................15 6. Acknowledgements.............................................15
7. Security considerations......................................15 7. IANA considerations..........................................15
8. Conclusion...................................................15 8. Security considerations......................................15
Normative References............................................16 9. Conclusion...................................................15
Normative References............................................15
Full Copyright Statement........................................17 Full Copyright Statement........................................17
Intellectual Property...........................................17 Intellectual Property...........................................17
Acknowledgement.................................................17 Acknowledgement.................................................17
1. Introduction 1. Introduction
The intention of this Internet Draft (I-D) is to initiate a The intention of this memo is to define requirements related to
discussion focused on accounting, authentication and authorization accounting, authentication and authorization issues for "well-
issues for "well-managed IP multicasting" services ("well-managed" managed IP multicasting" services ("well-managed" defined at the
defined at the end of this introduction). This I-D intends to end of this introduction).
develop an informational RFC on requirements for "well-managed IP
multicasting".
IP multicasting is becoming widely used as a method to save network IP multicasting is becoming widely used as a method to save network
resources such as bandwidth or CPU processing power of the sender's resources such as bandwidth or CPU processing power of the sender's
server for cases where a large volume of information needs to be server for cases where a large volume of information needs to be
distributed to a large number of receivers. This trend can be distributed to a large number of receivers. This trend can be
observed both in enterprise use and in broadband services provided observed both in enterprise use and in broadband services provided
by network operator/service providers. by network operator/service providers.
Distance learning within a university and in-house (in-company) Distance learning within a university and in-house (in-company)
sharing of multimedia information are examples of enterprise use. sharing of multimedia information are examples of enterprise use.
skipping to change at page 3, line 49 skipping to change at page 3, line 43
current standards (e.g., IGMPv3[1] and MLDv2[2]) has drawbacks current standards (e.g., IGMPv3[1] and MLDv2[2]) has drawbacks
compared to unicasting when one applies it to commercial services. compared to unicasting when one applies it to commercial services.
Accounting of each user's actions is not possible with multicasting Accounting of each user's actions is not possible with multicasting
as it is with unicasting. Accounting consists of grasping each as it is with unicasting. Accounting consists of grasping each
user's behavior, when she/he starts/stops to receive a channel, user's behavior, when she/he starts/stops to receive a channel,
which channel she/he receives, etc. which channel she/he receives, etc.
IP multicasting can be used to distribute free material efficiently, IP multicasting can be used to distribute free material efficiently,
but there are limitations to multicasting in usage models where but there are limitations to multicasting in usage models where
usage accounting is necessary, such as many commercial applications. usage accounting is necessary, such as many commercial applications.
Although multicasting has already been used in several applications, These limitations have prevented the widespread deployment of
in many cases it is used in such a way that accounting is not multicasting. Alternatively, one could develop and use a
necessary. Alternatively, one could develop and use a proprietary proprietary solution to address this issue. However, non-standard
solution to address this issue. However, non-standard solutions solutions have drawbacks in terms of interoperability or cost of
have drawbacks in terms of interoperability or cost of development development and maintenance.
and maintenance.
Without accounting capability in multicasting, information Without accounting capability in multicasting, information
providers desiring accounting capability are forced to use providers desiring accounting capability are forced to use
unicasting even when multicasting would otherwise be desirable from unicasting even when multicasting would otherwise be desirable from
a bandwidth/server resource perspective. If multicasting could be a bandwidth/server resource perspective. If multicasting could be
used with user-based accounting capabilities, its applicability used with user-based accounting capabilities, its applicability
would be greatly widened. would be greatly widened.
This I-D first describes problems on accounting issues in This I-D first describes problems on accounting issues in
multicasting. Then the general requirements for this capability multicasting. Then the general requirements for this capability
including QoS related issues are listed. This I-D assumes that including QoS related issues are listed. Finally, application
these capabilities can be realized by functions implemented at examples which could benefit from multicasting with accounting
edges of a network based on IGMP or MLD. Such functions would capabilities are shown. It is proposed that this I-D be used as a
record into dedicated database information obtained from edge starting point for a discussion on these issues.
routers. Finally, application examples which could benefit from
multicasting with accounting capabilities are shown. It is
proposed that this I-D be used as a starting point for a discussion
on these issues.
This I-D will present general functional requirements related to This I-D will present general functional requirements related to
accounting, authentication and authorization issues in IP accounting, authentication and authorization issues in IP
multicasting networks, and a multicast network which fulfills these multicasting networks, and a multicast network which fulfills these
requirements will be called a "well managed" IP multicasting requirements will be called a "well managed" IP multicasting
network. network.
2. Definitions and Abbreviations 2. Definitions and Abbreviations
2.1 Definitions 2.1 Definitions
skipping to change at page 5, line 25 skipping to change at page 5, line 15
3.1 Accounting issues 3.1 Accounting issues
In unicast communications, the server (information source) can In unicast communications, the server (information source) can
identify the client (information receiver) and only permits identify the client (information receiver) and only permits
connection by an eligible client when this type of access control connection by an eligible client when this type of access control
is necessary. In addition, when necessary, the server can grasp is necessary. In addition, when necessary, the server can grasp
what the client is doing (e.g., connecting to the server, starting what the client is doing (e.g., connecting to the server, starting
reception, what information the client is receiving, terminating reception, what information the client is receiving, terminating
reception, disconnecting from the server). reception, disconnecting from the server).
On the other hand, in multicast communication as in Fig.1, the On the other hand, in multicast communication with current
server just feeds its information to the multicast router. Then, standards (e.g., IGMPv3[1] or MLDv2[1]) the server just feeds its
the multicast router replicates the information to distribute to information to the multicast router [as in Fig.1]. Then, the
the clients. According to current standards (e.g., IGMPv3[1] or multicast router replicates the data to any link which has at least
MLDv2[2]), the multicast router feeds the replicated information to one client requesting the information. In this process, no
any link which has at least one client requesting the information. eligibility check is conducted. Any client can receive information
In this process, no eligibility check is conducted. Any client can just by requesting it. In other words, the current standards do
receive information just by requesting it. In other words, the not provide multicasting with authorization or access control
current standards do not provide multicasting with authorization or capabilities sufficient to meet the requirements of accounting.
access control capabilities sufficient to meet the requirements of
accounting.
+--------+ +--------+
| user |\ | user |\
+--------+ \ +--------+ \
\+------+ +------+ +------+ +------+ \+------+ +------+ +------+ +------+
+--------+ |Multi-| |Multi-| |Multi-| | | +--------+ |Multi-| |Multi-| |Multi-| | |
| user |---|cast |----|cast |----|cast |----|Server| | user |---|cast |----|cast |----|cast |----|Server|
+--------+ |router| |router| |router| | | +--------+ |router| |router| |router| | |
/+------+ +------+ +------+ +------+ /+------+ +------+ +------+ +------+
+--------+ / +--------+ /
skipping to change at page 6, line 27 skipping to change at page 6, line 13
networks. networks.
3.2 Relationship with secure multicasting (MSEC) 3.2 Relationship with secure multicasting (MSEC)
In many cases, content encryption (e.g. MSEC) is an effective In many cases, content encryption (e.g. MSEC) is an effective
method for preventing unauthorized access to original content (in method for preventing unauthorized access to original content (in
other words, the ability to decode data to return it to its other words, the ability to decode data to return it to its
generally useable form.) This I-D presents requirements for generally useable form.) This I-D presents requirements for
multicasting networks in the areas of 1) access control to prevent multicasting networks in the areas of 1) access control to prevent
unauthorized access to the network, and 2) accounting to grasp user unauthorized access to the network, and 2) accounting to grasp user
activity. It is not the intention of this I-D to propose activity. The functional requirements do not require content
alternatives to encryption. Access control, accounting and encryption although it might solve some of the related problems.
encryption are separate technologies. The implementation of any of At this point, it is not yet clear whether encryption would be part
these technologies does not preclude the use of the others. of a solution and if so, what other components (if any) would also
be required.
4. Functional general requirements for well managed IP multicasting 4. General functional requirements for well managed IP multicasting
It seems beneficial to use IGMP or MLD for access controlling in In consideration of the issues presented in section 3, the
multicast networks. However, from the considerations presented in following requirements have been derived:
section 3, there are issues in the following areas:
(1) User identification (1) User identification
The network should be able to identify each user when they attempt The network should be able to identify each user when they attempt
to access the service so that necessary access controlling actions to access the service so that necessary access controlling actions
can be applied. Also, it is necessary to identify the source can be applied. Also, it is necessary to identify the source
(user) of each request (e.g., join/leave) for user accounting (user) of each request (e.g., join/leave) for user accounting
purposes. purposes.
With current protocols, the sender cannot distinguish which With current protocols (IGMP/MLD), the sender cannot distinguish
receivers (end hosts) are actually receiving its information with which receivers (end hosts) are actually receiving the information.
current protocols (IGMP/MLD.) The sender must rely on the The sender must rely on the information from the multicasting
information from the multicasting routers. This can be complicated routers. This can be complicated if the sender and routers are
if the sender and routers are maintained by different entities. maintained by different entities.
(2) Issue of network resource protection (2) Issue of network resource protection
In order to guarantee certain QoS it is important for network In order to guarantee certain QoS it is important for network
providers to be able to protect their network resources from being providers to be able to protect their network resources from being
wasted, (either maliciously or accidentally). wasted, (either maliciously or accidentally).
(2.1) Access control For comparisons sake, in the case of unicast this issue can be
resolved e.g. by using RSVP.
(2.1) Access control
The network should be able to apply necessary access controlling The network should be able to apply necessary access controlling
actions when an eligible user requests. The network should be able actions when an eligible user requests. The network should be able
to reject any action requested from an ineligible user. to reject any action requested from an ineligible user.
(2.2) Control mechanism to support bandwidth of multicast stream (2.2) Control mechanism to support bandwidth of multicast stream
from a physical port of edge router or switch from a physical port of edge router or switch
The network should be able to control the combined bandwidth for The network may need to control the combined bandwidth for all
all groups both at the physical port of the edge router or switch groups both at the physical port of the edge router or switch so
so that these given physical entities are not overflowed with that these given physical entities are not overflowed with traffic.
traffic.
(2.3) Control mechanism of number of groups delivered from a (2.3) Control mechanism of number of groups delivered from a
physical port of edge router and switch physical port of edge router and switch
In order to enable an NSP to guarantee a certain level of QoS to If an NSP desires to guarantee a certain level of QoS to CP and the
the CP and the receivers, it is important that the NSP can control receivers, it is necessary that the NSP be able to control the
the number of groups delivered from a physical port of an edge number of groups delivered from a physical port of an edge router
router and a switch so that the combined bandwidth between content and a switch so that the combined bandwidth between content servers
servers and multicast routers can be within the limit. and multicast routers can be within the limit.
For comparisons sake, in the case of unicast this issue can be
resolved e.g. by using RSVP.
(3) User authentication (3) User authentication
The network should be able to authenticate a user. The network should be able to authenticate a user.
(4) User authorization (4) User authorization
The network should be able to authorize a user's access to content The network, at its option, should be able to authorize a user's
or a multicast group, so as to meet any demands by a CP to prevent access to content or a multicast group, so as to meet any demands
content access by ineligible users. Also, the NSP does not want to by a CP to prevent content access by ineligible users. In the case
waste their network resources on ineligible users. Eligibility can that the NSP may wish to provide a service based on guaranteed
be defined in several ways. The definition of an "eligible user" delivery, the NSP would not want to waste its network resources on
should be discussed further. ineligible users. Eligibility can be defined in several ways. The
definition of an "eligible user" should be discussed further.
(5) Accounting and billing (5) Accounting and billing
In many commercial multicast situations, NSP would like to be able In many commercial multicast situations, NSPs would like to be able
to precisely grasp network resource consumption and CP would like to precisely grasp network resource consumption and CPs would like
to be able to precisely grasp the content consumption by end-users. to be able to precisely grasp the content consumption by end-users.
Such information might be used for "identifying highly viewed Such information might be used for identifying highly viewed
content" for advertising revenue, ratings calculations, programming content for advertising revenue, ratings calculations, programming
decisions, etc., as well as billing and auditing purposes. Also decisions, etc., as well as billing and auditing purposes. Also
content and network providers may wish to provide users with access content and network providers may wish to provide users with access
to their usage history. to their usage history.
To assemble such an understanding of end-user behavior, it is To assemble such an understanding of end-user behavior, it is
necessary to precisely log information such as who (host/user) is necessary to precisely log information such as who (host/user) is
accessing what content at what time (join action) until what time accessing what content at what time (join action) until what time
(leave action). The result of the access-control decision (e.g. (leave action). The result of the access-control decision (e.g.
results of authorization) would also be valuable information. The results of authorization) would also be valuable information. The
desired degree of logging precisions would depend on the desired degree of logging precisions would depend on the
application used. application used.
Networks need database functions to realize user-based accounting
through the accumulation of logs from edge routers.
(5.1) How to share user information (5.1) How to share user information
For commercial multicast applications it is important for NSP and For commercial multicast applications it is important for NSP and
CP to be able to share information regarding user's behaviour (as CP to be able to share information regarding user's behaviour (as
described in (5) in standardized ways. described in (5) in standardized ways.
(6) Notification to users of the result of the join request (6) Notification to users of the result of the join request
It should be possible to provide information to the user about the It should be possible to provide information to the user about the
status of his/her join request(granted/denied/other). status of his/her join request(granted/denied/other).
(7) Service and terminal portability (7) Service and terminal portability
Networks should allow for a user to receive a service from Depending on the service, networks should allow for a user to
different places and/or with a different terminal device. receive a service from different places and/or with a different
terminal device.
(8) Support of ASM and SSM (8) Support of ASM and SSM
Both ASM (G), and SSM (S,G) should be supported as multicast models. Both ASM (G), and SSM (S,G) should be supported as multicast models.
(9) Admission control for join action (9) Admission control for join action
In order to maintain a predefined QoS level, an edge router should In order to maintain a predefined QoS level, depending on the NSP's
not accept a consequent "join" after a "leave" until the policy, an edge router should be able to control the number of
termination of the stream of the multicast group which was "left". streams it serves to a user, and total bandwidth consumed to that
This is essential to protect against e.g., multicast denial of user. For example if the number of streams being served to a
service (DoS) attacks. certain user has reached the limit defined by the NSP's policy,
then the edge router should not accept a subsequent "join" until
one of the existing streams is terminated. Similarly, if the NSP
is controlling by per-user bandwidth consumption, then a subsequent
"join" should not be accepted if delivery of the requested stream
would push the consumed bandwidth over the NSP policy-defined limit.
(10) Channel Leave Latency (10) Channel Join Latency and Leave Latency
Commercial implementations of IP multicasting are likely to have Commercial implementations of IP multicasting are likely to have
strict requirements in terms of user experience. Leave latency is strict requirements in terms of user experience. Join latency is
the time between when a user sends a signal that he/she wishes to the time between when a user sends a "join" request and when the
"leave" a group and when the network recognizes the "leave." requested data streaming first reaches the user. Leave latency is
the time between when a user sends a "leave" signal and when the
Leave latency impacts : network stops streaming to the user.
i. Acceptable end-user experience for fast channel surfing.
In an IP-TV application, users are not going to be receptive to
slow response time when changing channels.
ii. Resource consumption Leave and Join latencies impact the acceptable end-user experience
for fast channel surfing. In an IP-TV application, users are not
going to be receptive to a slow response time when changing
channels. If there are policies for controlling the number of
simultaneous streams a user may access then channel surfing will be
determined by the join and leave latencies.
With a low "leave latency" network providers could minimize Furthermore, leave affects resource consumption: with a low "leave
streaming content when there are no audiences. latency" network providers could minimize streaming content when
there are no audiences.
It is important that any overhead for authentication, authorization, It is important that any overhead for authentication, authorization,
and access-control be minimized at the times of joining and leaving and access-control be minimized at the times of joining and leaving
multicast groups so as to achieve join and leave latencies multicast groups so as to achieve join and leave latencies
acceptable in terms of user experience. For example this is acceptable in terms of user experience. For example this is
important in an IP-TV application, because users are not going to important in an IP-TV application, because users are not going to
be receptive to a slow response time when changing channels. be receptive to a slow response time when changing channels.
(11) Scalability (11) Scalability
skipping to change at page 10, line 15 skipping to change at page 10, line 10
(13) Deployable as alternative to Unicast (13) Deployable as alternative to Unicast
IP Multicasting would ideally be available as an alternative to IP IP Multicasting would ideally be available as an alternative to IP
unicasting when the "on-demand" nature of unicasting is not unicasting when the "on-demand" nature of unicasting is not
required. Therefore interfaces to multicasting should allow for required. Therefore interfaces to multicasting should allow for
easy integration into CDS systems that support unicasting. easy integration into CDS systems that support unicasting.
Especially equivalent interfaces for authorization, access control Especially equivalent interfaces for authorization, access control
and accounting capabilities should be provided. and accounting capabilities should be provided.
(14) Multicast replication (14) Multicast replication
The above requirements should also apply if multicast replication The above requirements should also apply if multicast replication
is is being done on an access-node (e.g. DSLAMs or OLTs).
being done on an access-node (e.g. DSLAMs or OLTs).
Specific functional requirements for each application can be Specific functional requirements for each application can be
derived from the above general requirements. An example is shown derived from the above general requirements. An example is shown
in the section 5. in the section 5.
5. Application example and its specific requirements 5. Application example and its specific requirements
This section shows an application example which could benefit from This section shows an application example which could benefit from
multicasting. Then, specific functional requirements related to multicasting. Then, specific functional requirements related to
user-based accounting capabilities are derived. user-based accounting capabilities are derived.
skipping to change at page 15, line 30 skipping to change at page 15, line 4
+----------- / --- | --- \ ---------------------------+ +----------- / --- | --- \ ---------------------------+
/ | \ / | \
/ | \ <- user/network interface / | \ <- user/network interface
/ | \ / | \
+---------++ +-----+----+ ++---------+ +---------++ +-----+----+ ++---------+
|user #a | |user #b | |user #c | |user #a | |user #b | |user #c |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
End user A End user B End user C End user A End user B End user C
Fig.3 Example of CDS network configuration Fig.3 Example of CDS network configuration
6. Acknowledgements
6. IANA considerations The authors of this draft would like to express their appreciation
to Pekka Savola of Netcore Ltd., Daniel Alvarez and Toerless Eckert
of Cisco Systems, Sam Sambasivan of SBC, Sanjay Wadhwa of Juniper,
Tom Anschutz and Steven Wright of BellSouth, Nicolai Leymann of T-
Systems, as well as the participants of the MBONED WG in general.
7. IANA considerations
This I-D does not raise any IANA consideration issues. This I-D does not raise any IANA consideration issues.
7. Security considerations 8. Security considerations
Accounting capabilities can be used to enhance the security of Accounting capabilities can be used to enhance the security of
multicast networks by excluding ineligible clients from the multicast networks by excluding ineligible clients from the
networks. networks.
8. Conclusion 9. Conclusion
This I-D describes general requirements for providing "well This I-D describes general requirements for providing "well
managed" managed" IP multicasting services. It lists issues related to
IP multicasting services. It lists issues related to accounting, accounting, authentication, authorization and admission control for
authentication, authorization and admission control for multicast multicast content delivery, with the goal of finding a solution
content delivery, with the goal of finding a solution implemented implemented at edges of the network based on IGMP or MLD. Content
at edges of the network based on IGMP or MLD. This solution likely Delivery Services with different business models is cited as an
would assume the existence of a database in the network dedicated application which could benefit from the capabilities of "well
to accumulating logs obtained from edge routers. Content Delivery managed" IP multicasting described in this document.
Services with different business models is cited as an application
which could benefit from the capabilities of "well managed" IP
multicasting described in this document.
It is proposed that this document be used as a starting point for It is proposed that this document be used as a starting point for
discussing requirements for "well managed" IP multicasting services. discussing requirements for "well managed" IP multicasting services.
Normative References Normative References
[1] B. Cain, et. al., "Internet Group Management Protocol, Version [1] B. Cain, et. al., "Internet Group Management Protocol, Version
3", RFC3376, October 2002. 3", RFC3376, October 2002.
[2] R. Vida, et. al., "Multicast Listener Discovery Version 2 [2] R. Vida, et. al., "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC3810, June 2004. (MLDv2) for IPv6", RFC3810, June 2004.
 End of changes. 40 change blocks. 
132 lines changed or deleted 136 lines changed or added

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