[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]
Versions: 00 01
Internet Engineering Task Force IDMR WG
INTERNET-DRAFT Bill Fenner/AT&T
draft-ietf-idmr-msnip-00.txt Hugh Holbrook/Cisco
Isidor Kouvelas/Cisco
23 February 2001
Expires: August 2001
Multicast Source Notification of Interest Protocol (MSNIP)
Status of this Document
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This document is a product of the IETF IDMR WG. Comments should be
addressed to the authors, or the WG's mailing list at
pim@catarina.usc.edu.
Abstract
This document discusses the Multicast Source Interest
Notification Protocol (MSNIP). MSNIP is an extension to
IGMPv3 [1] that provides membership notification services for
sources of multicast traffic.
Fenner/Holbrook/Kouvelas [Page 1]
INTERNET-DRAFT Expires: August 2001 February 2001
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . 3
2. API for Requesting Membership Notification. . . . . . . 3
3. Protocol Description. . . . . . . . . . . . . . . . . . 4
3.1. Group Range Negotiation. . . . . . . . . . . . . . . 5
3.2. Host Interest Solicitation . . . . . . . . . . . . . 6
3.3. Router Receiver Membership Reports . . . . . . . . . 6
4. Application Notification. . . . . . . . . . . . . . . . 7
5. Router Processing . . . . . . . . . . . . . . . . . . . 9
6. Message Formats . . . . . . . . . . . . . . . . . . . . 11
6.1. Group Map Packet . . . . . . . . . . . . . . . . . . 11
6.2. Interest Solicitation Packet . . . . . . . . . . . . 13
6.3. Group Membership Report Packet . . . . . . . . . . . 14
7. Constants Timers and Default Values . . . . . . . . . . 15
8. Todo list.... . . . . . . . . . . . . . . . . . . . . . 16
9. Authors' Addresses. . . . . . . . . . . . . . . . . . . 16
10. Acknowledgments. . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . 17
Fenner/Holbrook/Kouvelas [Page 2]
INTERNET-DRAFT Expires: August 2001 February 2001
1. Introduction
The Multicast Source Notification of Interest Protocol (MSNIP) is
an extension to version 3 of the Internet Group Membership Protocol
(IGMPv3 [1] ) that enables multicast sources to avoid the work of
sending packets when there are no receivers. The scenario may be one
where there is a server sourcing a large number of multicast flows from
a much larger pool of potential multicast flows that map onto separate
multicast group addresses. If the source were to continuously transmit
data on all the groups that could potentially have receivers,
significant resources would be wasted in the system itself as well as
the first-hop link. Using a higher level control protocol to determine
the existence of receivers for particular flows is not practical as
there may be many potential receivers.
Information on which multicast groups have receivers for a
particular sender is typically maintained by the multicast routing
protocol on the first hop router to the source. MSNIP uses this
information to notify the application in the sending system of when it
should start or stop transmitting. This is achieved without any group-
specific state on the first-hop router for potential sources without
receivers.
Many currently deployed multicast routing protocols, require data
from an active source to be propagated past the first-hop router before
information on the existence of receivers becomes available on the
first-hop. All dense-mode protocols fall under this category as well as
sparse-mode protocols that use shared trees for source discovery (such
as PIM-SM [3] ). In order to provide receiver interest notification for
such protocols, the default mode of operation would require that the
system always transmits on all potential groups and the first-hop
routers prune the traffic back.
In order to avoid this complication MSNIP only supports sparse-mode
multicast routing protocols that build source-specific trees (such as
PIM-SSM [3] ). With such protocols, the first-hop router can obtain
information on the existence of receivers without forwarding any data
from the source. Support for this type of protocols covers the majority
of applications that MSNIP is targeted at.
2. API for Requesting Membership Notification
Applications within an IP system that wish to source multicast
packets and are interested in being notified on the existence of
receivers must register with the IP layer of the system. MSNIP requires
that within the IP system, there is (at least conceptually) an
Application Programming Interface or API that can be used to register
with the IP layer for such notifications. A system's IP API must support
Fenner/Holbrook/Kouvelas Section 2. [Page 3]
INTERNET-DRAFT Expires: August 2001 February 2001
the following operation or any logical equivalent:
IPMulticastsSourceRegister (socket, interface, multicast-address)
IPMulticastsSourceDeregister (socket, interface, multicast-address)
In addition the application must provide the following API for
receiving notifications from the IP system:
IPMulticastSourceStart (socket, interface, multicast-address)
IPMulticastSourceStop (socket, interface, multicast-address)
where:
socket
is an implementation-specific parameter used to distinguish among
different requesting entities (e.g., programs or processes) within
the system; the socket parameter of BSD Unix system calls is a
specific example.
interface
is a local identifier of the network interface on which the
application wishes to transmit data to the specified multicast
address. An implementation may allow a special "unspecified" value
to be passed as the interface parameter, in which case the request
would apply to the "primary" or "default" interface of the system
(perhaps established by system configuration). If transmission to
the same multicast address is desired on more than one interface,
IPMulticastSourceRegister is invoked separately for each desired
interface.
multicast-address
is the IP multicast address to which the request pertains. If
transmission to more than one multicast address on a given
interface is desired, IPMulticastSourceRegister is invoked
separately for each desired multicast address.
3. Protocol Description
Like IGMP, MSNIP is an asymmetric protocol specifying different
behaviors for systems wishing to source traffic and for multicast
routers. Note that a system may perform at the same time more than one
of the above functions. An example is a router that wishes to source
traffic.
Fenner/Holbrook/Kouvelas Section 3. [Page 4]
INTERNET-DRAFT Expires: August 2001 February 2001
3.1. Group Range Negotiation
With current multicast deployment in the Internet, different
multicast protocols coexist and operate under different parts of the
multicast-address space. Multicast routers are consistently configured
with information that maps specific group ranges to multicast protocols.
Part of this configuration describes the subset of the multicast address
space that is used by source-specific multicast [4].
The default behavior of IP multicast, without MSNIP, is that a
multicast application must assume that there are multicast receivers
present in the network. In order to allow hosts to avoid transmitting
when there are no receivers, MSNIP communicates a range of MSNIP managed
groups to source systems.
This task is left up to the IGMP querying router. The querier
periodically multicasts a MSNIP Group Map message containing the
definition of the group ranges over which MSNIP operates. This
destination address of the Group Map message is the ALLSYSTEMS group.
The Group Map message is sent every [Group Map Interval] seconds. The
message also contains a holdtime which is set to [Group Map Holdtime]
and instructs IP systems to maintain the group mapping state for the
specified holdtime.
In addition Group Map messages are sent when either:
o the IGMP querier on a link receives an Interest Solicitation message
(described in section 3.2 ) from an IP system that was not previously
registered with MSNIP or was registered with a different GenID (see
section 6.2.
o the configured ranges over which MSNIP operated change.
When either of the above two events occur the querier initiates a set of
[Robustness Variable] Group Map messages.
Upon receipt of a Group Map message, an IP system builds or updates
a set of group range records as follows. For each group range present in
the message, the system either creates or updates a record of the form:
(interface, group prefix, group mask)
Where interface is the interface the Group Map message was received on
and prefix and mask are the definition of the group range.
Each previously existing range record with an interface equal to
the interface the message was received on which is not reported in the
received message is deleted.
Fenner/Holbrook/Kouvelas Section 3.1. [Page 5]
INTERNET-DRAFT Expires: August 2001 February 2001
In addition to the group range records, the IP system maintains a
holdtime timer associated with the interface which is initialised to the
holdtime in the received message. If the timer expires before the
receipt of the next Group Map message, all range records related to the
interface are deleted.
3.2. Host Interest Solicitation
Hosts that wish to be managed by MSNIP periodically transmit an
Interest Solicitation message. This message is multicast with a group
destination address of ALL_IGMPv3_ROUTERS (224.0.0.22) and is
transmitted every [Interest Solicitation Interval] seconds. The Interest
Solicitation message contains a holdtime which is set to [Interest
Solicitation Holdtime] and instructs the routers to maintain MSNIP state
for this system for the specified period. A generation ID is also
included in the Interest Solicitation message to provide support for
routers to detect system crashes (see section 6.2).
When an IP system first comes up it transmits [Robustness Variable]
Interest Solicitation messages randomly spaced over [Initial Interest
Solicitation Interval] seconds.
All MSNIP capable routers on the link that receive an Interest
Solicitation message from an IP system, maintain a system interest
record of the form:
(IP system address, holdtime timer)
Each time an Interest Solicitation message is received from the IP
system, the holdtime timer is reset to the holdtime in the received
message. In addition the router responds to the solicitation message
with a Receiver Membership Report message described in section 3.3. The
message contains a TRANSMIT group record for each of the group addresses
within the MSNIP managed range for which the routing protocol indicates
there are receivers for this source system.
When the holdtime timer of a specific system interest record
expires, the record is deleted.
3.3. Router Receiver Membership Reports
Receiver Membership Report messages are used by routers to
communicate the receiver membership status of particular groups to a
specific IP system. Each message contains a list of group records of
either TRANSMIT or HOLD type that instruct a system to respectively
start or stop sending traffic on this link to the specified group
Fenner/Holbrook/Kouvelas Section 3.3. [Page 6]
INTERNET-DRAFT Expires: August 2001 February 2001
address. Receiver Membership Report messages are unicast to the target
system.
In addition to the receipt of an Interest Solicitation message,
routers send Receiver Membership Reports to IP systems when the receiver
membership status reported by the multicast routing protocol changes for
a specific source and group. Such reports are only sent if the group is
managed by MSNIP and the router has a system interest record created by
a previously received Interest Solicitation message with a IP system
address equal to the source address. If the source group pair satisfy
these conditions then [Robustness Variable] Receiver Membership Reports
are sent out within [Unsolicited Membership Report Interval] seconds. If
during the [Unsolicited Membership Report Interval] an additional
membership change occurs for the same group and source system,
transmission of any related pending Receiver Membership Report messages
is canceled and a new set of [Robustness Variable] messages is
scheduled.
When an IP system receives a Receiver Membership Report message,
for each of the TRANSMIT group records listed in the message it creates
or updates a group record of the form:
(interface, router address, group address, holdtime timer)
Where the interface is the one the message was received on, the outer
address is obtained from the source address on the IP header of the
received message and the holdtime timer is set to [Interest Solicitation
Holdtime] seconds.
For each group HOLD group record present in the message, the system
deletes the relevant group record from its state.
4. Application Notification
This section describes how protocol events trigger notifications to
source applications within an IP system.
+-----------------------------------+
| Figures omitted from text version |
+-----------------------------------+
Figure 1: Per Interface (I) and Group (G) state machine at an IP system
Fenner/Holbrook/Kouvelas Section 4. [Page 7]
INTERNET-DRAFT Expires: August 2001 February 2001
In tabular form, the state-machine is:
+-----------+-----------------------------------------------------------+
| | Event |
| +----------+-----------+------------+-----------+-----------+
|Prev State |New |Start |Stop |Recv |Recv last |
| |Register |Manage |Manage |TRANSMIT |HOLD or |
| | | | | |timeout |
+-----------+----------+-----------+------------+-----------+-----------+
| |Start new |-> Hold |- |- |- |
|No Info | |Stop ALL | | | |
| | |registered | | | |
+-----------+----------+-----------+------------+-----------+-----------+
| |- |- |-> No Info |-> |- |
|Hold | | | |Transmit | |
| | | |Stop ALL |Start ALL | |
| | | |registered |registered | |
+-----------+----------+-----------+------------+-----------+-----------+
| |Start new |- |-> No Info |- |-> Hold |
|Transmit | | | | |Stop ALL |
| | | | | |registered |
+-----------+----------+-----------+------------+-----------+-----------+
The events in state machine above have the following meaning:
New register
A new application has registered through a call to
IPMulticastsSourceRegister for this G and I.
Start manage
We received a Group Map packet on I that changed the status of G
from a non-managed to a MSNIP managed group.
Stop manage
We received a Group Map packet on I that changed the status of G
from a MSNIP managed to a non-managed group or the mapping that
caused this group to be managed expired.
Receive TRANSMIT
We received a Receiver Membership Report on I that contains a
TRANSMIT group record for G.
Fenner/Holbrook/Kouvelas Section 4. [Page 8]
INTERNET-DRAFT Expires: August 2001 February 2001
Receive last HOLD or timeout
We either received a Receiver Membership Report on I that contains
a HOLD group record for G or a TRANSMIT group record gor G on I
expired and there are no other transmit records for G on I. This
means that there are no routers left wishing to receive traffic
from this system to group G on I.
The state machine actions have the following meaning:
Start new
Send an IPMulticastSourceStart notification to the application that
just registered for this G and I.
Start ALL registered
Send an IPMulticastSourceStart notification to all applications
that are registered for this G and I.
Stop ALL registered
Send an IPMulticastSourceStop notification to all applications that
are registered for this G and I.
5. Router Processing
This section describes the per-source system tracking that takes
place within a router.
+-----------------------------------+
| Figures omitted from text version |
+-----------------------------------+
Figure 2: Per IP source system (S) state machine at a router
Fenner/Holbrook/Kouvelas Section 5. [Page 9]
INTERNET-DRAFT Expires: August 2001 February 2001
In tabular form, the state-machine is:
+------------++---------------------------------------------------------+
| || Event |
| ++------------+-----------+-------------+------------------+
|Prev State || Receive | HIS | Receivers | Receivers |
| || HIS | timeout | for new | of G leave |
| || | | group G | |
+------------++------------+-----------+-------------+------------------+
| || -> | - | - | - |
| || Tracking | | | |
| || Set HT to | | | |
|Not || message | | | |
|tracking || holdtime | | | |
| || Send ALL | | | |
| || existing | | | |
| || TRANSMITs | | | |
+------------++------------+-----------+-------------+------------------+
|Tracking || Set HT to | -> Not | Send | Send HOLD |
| || message | tracking | TRANSMIT | for G |
| || holdtime | | for G | |
+------------++------------+-----------+-------------+------------------+
The events in state machine above have the following meaning:
Receive HIS
The router has received a Host Interest Solicitation from S.
HIS timeout
The holdtime timer (HT) associated with S has expired.
Receivers for new group G
The routing protocol has informed MSNIP that it now has receivers
for the MSNIP managed group G and system S.
Receivers of G leave
The routing protocol has informed MSNIP that all receivers for the
MSNIP managed group G and system S have left.
The state machine actions have the following meaning:
Fenner/Holbrook/Kouvelas Section 5. [Page 10]
INTERNET-DRAFT Expires: August 2001 February 2001
Set HT to message holdtime
The holdtime timer associated with S is restarted to the value of
the holdtime in the received Host Interest Solicitation message.
Send ALL existing TRANSMITs
The router builds and transmits Receiver Membership Reports to S
that contain a TRANSMIT group block for each of the MSNIP managed
groups that have receivers for S.
Send TRANSMIT for G
The router builds and transmits a Receiver Membership Report to S
that contains a TRANSMIT group block for the group G.
Send HOLD for G
The router builds and transmits a Receiver Membership Report to S
that contains a HOLD group block for the group G.
6. Message Formats
Like all other IGMP messages, MSNIP messages are encapsulated in
IPv4 datagrams, with an IP protocol number of 2. Every MSNIP message
described in this document is sent with an IP Time-to-Live of 1, and
carries an IP Router Alert option [RFC-2113] in its IP header.
There are three IGMP message types of concern to the MSNIP protocol
described in this document:
+-------------------+----------------------------+
| Type Number (hex) | Message Name |
+-------------------+----------------------------+
| 0x23 | Group Map |
+-------------------+----------------------------+
| 0x24 | Interest Solicitation |
+-------------------+----------------------------+
| 0x25 | Receiver Membership Report |
+-------------------+----------------------------+
6.1. Group Map Packet
A Group Map packet is periodically multicast by the IGMP querier to
declare the multicast group ranges manages by MSNIP. The Group Map
message is multicast with a group destination address of
Fenner/Holbrook/Kouvelas Section 6.1. [Page 11]
INTERNET-DRAFT Expires: August 2001 February 2001
ALL_IGMPv3_ROUTERS (224.0.0.22).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x23 | Group Count | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group-Prefix-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask-Len-1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Group Count
The number of group range records present in this message. Note
that the actual maximum number of group ranges that can be reported
is limited by the maximum size of an IP packet. As each Group Map
packet replaces the mapping at a receiving system, a router cannot
split a group mapping into more than one Group Map packets.
Checksum
The Checksum is the 16-bit one's complement of the one's complement
sum of the whole MSNIP message (the entire IP payload). For
computing the checksum, the Checksum field is set to zero. When
receiving packets, the checksum MUST be verified before processing
a packet.
Holdtime
The amount of time a receiving system must keep the group map state
alive, in seconds.
Group-Prefix-1
The group prefix of the first group record present in this message.
Mask-Len-1
The mask length for the group range in the first group record
present in this message.
Fenner/Holbrook/Kouvelas Section 6.1. [Page 12]
INTERNET-DRAFT Expires: August 2001 February 2001
Reserved
Transmitted as zero. Ignored upon receipt.
6.2. Interest Solicitation Packet
A Interest Solicitation packet is periodically multicast by MSNIP
capable systems to declare interest in Receiver Membership Reports from
multicast routers on the link. The Interest Solicitation message is
multicast with a group destination address of ALL_IGMPv3_ROUTERS
(224.0.0.22).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x24 | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Holdtime | GenID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
Transmitted as zero. Ignored upon receipt.
Checksum
Calculated as for Group Map packet.
Holdtime
The amount of time a receiving router must keep the system interest
state alive, in seconds.
GenID
Generation ID of the IP system. A number that is selected randomly
for each of the [Robustness Variable] initial Interest Solicitation
messages when the system comes up and afterwards remains fixed to
the value used in the last of the initial messages throughout the
system lifetime. The GenID is used by routers to detect system
crashes.
Fenner/Holbrook/Kouvelas Section 6.2. [Page 13]
INTERNET-DRAFT Expires: August 2001 February 2001
6.3. Group Membership Report Packet
A Group Membership Report packet is unicast by first-hop multicast
routers and targeted at potential sources to inform them of the
existence or not of receivers for the listed multicast groups.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x25 | Group Count | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record-Type-1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group-Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Group Count
The number of group records present in this message.
Checksum
Calculated as for Group Map packet.
Record-Type-1
The type of the first group record in this message. Valid values
are:
+-------------+-------------------------------------+-------+
| Record Type | Description | Value |
+-------------+-------------------------------------+-------+
| TRANSMIT | Request to start transmitting group | 1 |
+-------------+-------------------------------------+-------+
| HOLD | Request to stop transmitting group | 2 |
+-------------+-------------------------------------+-------+
Reserved
Transmitted as zero. Ignored upon receipt.
Group-Address-1
The multicast address of the first group record in the message.
Fenner/Holbrook/Kouvelas Section 6.3. [Page 14]
INTERNET-DRAFT Expires: August 2001 February 2001
7. Constants Timers and Default Values
Robustness Variable
The Robustness Variable allows tuning for the expected packet loss
on a network. If a network is expected to be lossy, the Robustness
Variable may be increased. MSNIP is robust to (Robustness Variable
- 1) packet losses. The Robustness Variable MUST NOT be zero, and
SHOULD NOT be one. Default: 2
Group Map Interval
The interval used by the IGMP querier between transmissions of
Group Map messages. Default: 60 secs
Group Map Holdtime
The interval inserted in Group Map messages that indicates to
systems how long they should use the included mapping information
before they time it out. This MUST be ((the Robustness Variable)
times (the Group Map Interval) plus (one second)).
Interest Solicitation Interval
The interval used by MSNIP capable systems between transmissions of
Interest Solicitation messages. Default: 60 secs
Interest Solicitation Holdtime
The interval inserted in Interest Solicitation messages by systems
to instruct routers how long they should maintain system interest
state for. This MUST be ((the Robustness Variable) times (the
Interest Solicitation Interval) plus (one second)).
Initial Interest Solicitation Interval
The interval used by systems to send out the initial Interest
Solicitation messages when they first come up. Default: 1 second.
Unsolicited Membership Report Interval
The interval used by routers to send out a set of Membership Report
messages when the group membership changes for a specific system.
Default: 1 second.
Fenner/Holbrook/Kouvelas Section 7. [Page 15]
INTERNET-DRAFT Expires: August 2001 February 2001
8. Todo list...
o Add security considerations section.
o If application ignores or does not ask for notification in managed
range host OS should filter packets.
o Maybe provide masks for registration / notification API.
o Case where host and app starts before MSNIP range is available.
o When we hear out-of-order IGMP query resend interest registration.
o Only send interest registration when application is interested. This
is not possible if we do host filtering...
o Maybe add API to ask the kernel for the state of a particular group.
bool IpMulticastSourceHasInterest (socket, interface, multicast-
address).
o Add GenID changes to router FSM.
9. Authors' Addresses
Bill Fenner
AT&T Labs - Research
75 Willow Road
Menlo Park, CA 94025
fenner@research.att.com
Hugh Holbrook
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
holbrook@cisco.com
Fenner/Holbrook/Kouvelas Section 9. [Page 16]
INTERNET-DRAFT Expires: August 2001 February 2001
Isidor Kouvelas
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
kouvelas@cisco.com
10. Acknowledgments
The authors would like to thank Jon Crowcroft for his contribution to
this specification.
11. References
[1] B. Cain, S Deering, W. Fenner, I Kouvelas, A. Thyagarajan, "Internet
Group Management Protocol, Version 3", Work In Progress, <draft-
ietf-idmr-igmp-v3-05.txt>, 2000.
[2] S. Kent, R. Atkinson, "Security Architecture for the Internet
Protocol.", RFC 2401.
[3] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol
Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)", Work In Progress, <draft-ietf-pim-sm-
v2-new-01.txt>, 2000.
[4] Z. Albanna, K. Almeroth, D. Meyer, "IANA Guidelines for IPv4
Multicast Address Allocation", Best Current Practices, <draft-ietf-
iana-IPv4-mcast-guidelines-00.txt>, 2001.
Fenner/Holbrook/Kouvelas Section 11. [Page 17]
INTERNET-DRAFT Expires: August 2001 February 2001
Fenner/Holbrook/Kouvelas Section 11. [Page 18]
Html markup produced by rfcmarkup 1.129b, available from
https://tools.ietf.org/tools/rfcmarkup/