draft-ietf-idmr-msnip-00.txt   draft-ietf-idmr-msnip-01.txt 
Internet Engineering Task Force IDMR WG Internet Engineering Task Force IDMR WG
INTERNET-DRAFT Bill Fenner/AT&T INTERNET-DRAFT Bill Fenner/AT&T
draft-ietf-idmr-msnip-00.txt Hugh Holbrook/Cisco draft-ietf-idmr-msnip-01.txt Hugh Holbrook/Cisco
Isidor Kouvelas/Cisco Isidor Kouvelas/Cisco
23 February 2001 21 November 2001
Expires: August 2001 Expires: May 2002
Multicast Source Notification of Interest Protocol (MSNIP) Multicast Source Notification of Interest Protocol (MSNIP)
Status of this Document Status of this Document
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
skipping to change at page 2, line 8 skipping to change at page 2, line 8
Abstract Abstract
This document discusses the Multicast Source Interest This document discusses the Multicast Source Interest
Notification Protocol (MSNIP). MSNIP is an extension to Notification Protocol (MSNIP). MSNIP is an extension to
IGMPv3 [1] that provides membership notification services for IGMPv3 [1] that provides membership notification services for
sources of multicast traffic. sources of multicast traffic.
Table of Contents Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 3
2. API for Requesting Membership Notification. . . . . . . 3 2. Routing Protocol Support. . . . . . . . . . . . . . . . 3
3. Protocol Description. . . . . . . . . . . . . . . . . . 4 3. API for Requesting Membership Notification. . . . . . . 4
3.1. Group Range Negotiation. . . . . . . . . . . . . . . 5 4. MSNIP Managed Address Range Negotiation . . . . . . . . 5
3.2. Host Interest Solicitation . . . . . . . . . . . . . 6 4.1. Router Coordination. . . . . . . . . . . . . . . . . 6
3.3. Router Receiver Membership Reports . . . . . . . . . 6 4.1.1. MSNIP Capability Discovery Option . . . . . . . . 6
4. Application Notification. . . . . . . . . . . . . . . . 7 4.1.2. SSM Range Discovery Option. . . . . . . . . . . . 7
5. Router Processing . . . . . . . . . . . . . . . . . . . 9 4.2. Communicating Range to Source Systems. . . . . . . . 7
6. Message Formats . . . . . . . . . . . . . . . . . . . . 11 4.2.1. MSNIP Range Map Messages. . . . . . . . . . . . . 8
6.1. Group Map Packet . . . . . . . . . . . . . . . . . . 11 5. Requesting and Receiving Notifications. . . . . . . . . 9
6.2. Interest Solicitation Packet . . . . . . . . . . . . 13 5.1. Host Interest Solicitation . . . . . . . . . . . . . 10
6.3. Group Membership Report Packet . . . . . . . . . . . 14 5.2. Router Receiver Membership Reports . . . . . . . . . 10
7. Constants Timers and Default Values . . . . . . . . . . 15 6. Routerless Operation. . . . . . . . . . . . . . . . . . 11
8. Todo list.... . . . . . . . . . . . . . . . . . . . . . 16 7. Application Notification. . . . . . . . . . . . . . . . 12
9. Authors' Addresses. . . . . . . . . . . . . . . . . . . 16 8. Router Processing . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgments. . . . . . . . . . . . . . . . . . . . 17 9. Message Formats . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Range Map Packet . . . . . . . . . . . . . . . . . . 16
9.2. Interest Solicitation Packet . . . . . . . . . . . . 18
9.3. Receiver Membership Report Packet. . . . . . . . . . 19
10. Constants Timers and Default Values. . . . . . . . . . 20
11. Todo list... . . . . . . . . . . . . . . . . . . . . . 21
12. Acknowledgements . . . . . . . . . . . . . . . . . . . 21
13. Authors' Addresses . . . . . . . . . . . . . . . . . . 21
14. References . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
The Multicast Source Notification of Interest Protocol (MSNIP) is The Multicast Source Notification of Interest Protocol (MSNIP) is
an extension to version 3 of the Internet Group Membership Protocol an extension to version 3 of the Internet Group Membership Protocol
(IGMPv3 [1] ) that enables multicast sources to avoid the work of (IGMPv3 [1] ). MSNIP operates between multicast sources and their first-
sending packets when there are no receivers. The scenario may be one hop routers to provide information on the presence of receivers to the
where there is a server sourcing a large number of multicast flows from source systems. Using the services offered by MSNIP an application on an
a much larger pool of potential multicast flows that map onto separate IP system wishing to source multicast data can register to be notified
multicast group addresses. If the source were to continuously transmit when receivers join and leave the session. This enables multicast
data on all the groups that could potentially have receivers, sources to avoid the work of transmitting packets onto their first-hop
link when there are no joined receivers.
A common scenario where MSNIP may be useful is one where there is a
multicast server offering a large pool of potential flows that map onto
separate multicast destination addresses but receivers exist only for a
small subset of the flows. If the source were to continuously transmit
data for all the flows that could potentially have receivers,
significant resources would be wasted in the system itself as well as 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 first-hop link. Using a higher level control protocol to determine
the existence of receivers for particular flows is not practical as the existence of receivers for particular flows may not be practical as
there may be many potential receivers. there may be many potential receivers in each active session.
Information on which multicast groups have receivers for a Information on which multicast destination addresses have receivers
particular sender is typically maintained by the multicast routing for a particular sender is typically available to the multicast routing
protocol on the first hop router to the source. MSNIP uses this protocol on the first hop router for a source. MSNIP uses this
information to notify the application in the sending system of when it information to notify the application in the sending system of when it
should start or stop transmitting. This is achieved without any group- should start or stop transmitting. This is achieved without any
specific state on the first-hop router for potential sources without destination address specific state on the first-hop router for potential
receivers. sources without receivers.
2. Routing Protocol Support
For reasons described in this section, MSNIP only supports
transmission control for applications that use multicast destination
addresses that are routed using Source Specific Multicast (SSM).
Many currently deployed multicast routing protocols, require data Many currently deployed multicast routing protocols, require data
from an active source to be propagated past the first-hop router before from an active source to be propagated past the first-hop router before
information on the existence of receivers becomes available on the information on the existence of receivers becomes available on the
first-hop. All dense-mode protocols fall under this category as well as first-hop. In addition, such protocols require that this activity is
repeated periodically to maintain source liveness state on remote
routers. All dense-mode protocols fall under this category as well as
sparse-mode protocols that use shared trees for source discovery (such sparse-mode protocols that use shared trees for source discovery (such
as PIM-SM [3] ). In order to provide receiver interest notification for as PIM-SM [3] ). In order to provide receiver interest notification for
such protocols, the default mode of operation would require that the such protocols, the default mode of operation would require that the
system always transmits on all potential groups and the first-hop source IP system periodically transmits on all potential destination
routers prune the traffic back. addresses and the first-hop routers prune the traffic back. Such a
In order to avoid this complication MSNIP only supports sparse-mode flood-and-prune behaviour on the first-hop link significantly diminishes
multicast routing protocols that build source-specific trees (such as the benefits of managing source transmission.
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 In contrast, with source-specific sparse-mode protocols such as
PIM-SSM [3] availability of receiver membership information on the
first-hop routers is independent of data transmission. Such protocols
use an external mechanism for source discovery (like source-specific
IGMPv3 membership reports) to build source-specific multicast trees.
Clearly these two classes of routing protocols require different
handling for the problem MSNIP is trying to solve. In addition the
second type covers the majority of applications that MSNIP is targeted
at. MSNIP avoids the extra complication in supporting routing protocols
that require a flood and prune behaviour.
3. API for Requesting Membership Notification
Applications within an IP system that wish to source multicast Applications within an IP system that wish to source multicast
packets and are interested in being notified on the existence of packets and are interested in being notified on the existence of
receivers must register with the IP layer of the system. MSNIP requires receivers must register with the IP layer of the system. MSNIP requires
that within the IP system, there is (at least conceptually) an that within the IP system, there is (at least conceptually) an
Application Programming Interface or API that can be used to register 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 with the IP layer for such notifications. A system's IP API must support
the following operation or any logical equivalent: the following operation or any logical equivalent:
IPMulticastsSourceRegister (socket, interface, multicast-address) IPMulticastsSourceRegister (socket, source-address, multicast-address)
IPMulticastsSourceDeregister (socket, interface, multicast-address) IPMulticastsSourceDeregister (socket, source-address, multicast-address)
In addition the application must provide the following API for In addition the application must provide the following API for
receiving notifications from the IP system: receiving notifications from the IP system:
IPMulticastSourceStart (socket, interface, multicast-address) IPMulticastSourceStart (socket, source-address, multicast-address)
IPMulticastSourceStop (socket, interface, multicast-address) IPMulticastSourceStop (socket, source-address, multicast-address)
where: where:
socket socket
is an implementation-specific parameter used to distinguish among is an implementation-specific parameter used to distinguish among
different requesting entities (e.g., programs or processes) within different requesting entities (e.g., programs or processes) within
the system; the socket parameter of BSD Unix system calls is a the system; the socket parameter of BSD Unix system calls is a
specific example. specific example.
interface source-address
is a local identifier of the network interface on which the is the IP unicast source address that the application wishes to use
application wishes to transmit data to the specified multicast in transmitting data to the specified multicast address. The
address. An implementation may allow a special "unspecified" value specified address must be one of the IP addresses associated with
to be passed as the interface parameter, in which case the request the network interfaces of the IP system. Note that an interface in
would apply to the "primary" or "default" interface of the system an IP system may be associated with more than one IP addresses. An
(perhaps established by system configuration). If transmission to implementation may allow a special "unspecified" value to be passed
the same multicast address is desired on more than one interface, as the source-address parameter, in which case the request would
apply to the "primary" IP address of the "primary" or "default"
interface of the system (perhaps established by system
configuration). If transmission to the same multicast address is
desired using more than one source IP address,
IPMulticastSourceRegister is invoked separately for each desired IPMulticastSourceRegister is invoked separately for each desired
interface. source address.
multicast-address multicast-address
is the IP multicast address to which the request pertains. If is the IP multicast destination address to which the request
transmission to more than one multicast address on a given pertains. If the application wishes to transmit data to more than
interface is desired, IPMulticastSourceRegister is invoked one multicast address for a given source address,
separately for each desired multicast address. IPMulticastSourceRegister is invoked separately for each desired
multicast address.
3. Protocol Description Applications wising to use MSNIP to control their multicast data
transmission to destination G from source address S operate as follows.
Like IGMP, MSNIP is an asymmetric protocol specifying different Initially the application contacts the IP system to obtain the
behaviors for systems wishing to source traffic and for multicast socket handle for use on all subsequent interactions. The application
routers. Note that a system may perform at the same time more than one invokes IPMulticastSourceRegister for the desired S and G and then waits
of the above functions. An example is a router that wishes to source without transmitting any packets for the IP system to notify that
traffic. receivers for the session exist.
3.1. Group Range Negotiation If and when the IP system notifies the application that receivers
exist using the IPMulticastSourceStart call, the application may start
transmitting data. After the application has been notified to send, if
all receivers for the session leave, the IP system will notify the
application using the IPMulticastSourceStop call. At this point the
application should stop transmitting data until it is notified again
that receivers have joined through another IPMulticastSourceStart call.
When the application no longer wishes to transmit data it should
invoke the IPMulticastsSourceDeregister call to let the IP system know
that it is no longer interested in notifications for this source and
destination. The IPMulticastsSourceDeregister call should be implicit in
the teardown of the associated socket state.
4. MSNIP Managed Address Range Negotiation
With current multicast deployment in the Internet, different With current multicast deployment in the Internet, different
multicast protocols coexist and operate under different parts of the multicast routing protocols coexist and operate under separate parts of
multicast-address space. Multicast routers are consistently configured the multicast address space. Multicast routers are consistently
with information that maps specific group ranges to multicast protocols. configured with information that maps specific multicast address ranges
Part of this configuration describes the subset of the multicast address to multicast routing protocols. Part of this configuration describes the
space that is used by source-specific multicast [4].
The default behavior of IP multicast, without MSNIP, is that a subset of the address space that is used by source-specific multicast
multicast application must assume that there are multicast receivers (SSM) [4]. As described in section 2 MSNIP only tries to control
present in the network. In order to allow hosts to avoid transmitting application transmission within the SSM address range.
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 It is desirable for applications within an IP system that supports
periodically multicasts a MSNIP Group Map message containing the MSNIP to have a consistent API for multicast transmission that does
definition of the group ranges over which MSNIP operates. This require the application to be aware of the SSM address range. MSNIP
destination address of the Group Map message is the ALLSYSTEMS group. supports this by allowing applications to use the API described in
The Group Map message is sent every [Group Map Interval] seconds. The section 3 for multicast destination addresses that are outside its
message also contains a holdtime which is set to [Group Map Holdtime] operating range. When an application registers for notifications for a
and instructs IP systems to maintain the group mapping state for the destination address that is not managed by MSNIP it is immediately
specified holdtime. notified to start transmitting. This complies with the default behaviour
of IP multicast without MSNIP support which forces multicast
applications to assume that there are multicast receivers present in the
network.
In addition Group Map messages are sent when either: 4.1. Router Coordination
In order for MSNIP to operate on a shared link where more than one
multicast routers may be present all multicast routers must be MSNIP
capable and have a consistent configuration for the SSM address range.
MSNIP enforces these requirements by using two new options in the IGMP
Multicast Router Discovery protocol [5].
4.1.1. MSNIP Capability Discovery Option
A multicast router advertises that it is MSNIP capable using the
MSNIP Capable Multicast Router Discovery protocol option. This option
MUST be included in all Multicast Router Advertisement messages. The
format of the option is as follows:
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=X | Length=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A multicast router uses received Multicast Router Advertisement
messages to determine if all live neighbour multicast routers on each
interface are MSNIP capable. If even one multicast router on a given
interface does not advertise the MSNIP Capable option in its Multicast
Router Advertisement messages then the interface is not considered as
MSNIP capable.
4.1.2. SSM Range Discovery Option
The SSM Range Discovery option SHOULD be included in all Multicast
Router Advertisement messages. It contains the list of multicast
destination address ranges that are configured to operate under source
specific multicast on this router. Note that the maximum length of a
Multicast Router Discovery option limits the number of ranges to 50 (Is
this an issue?). The format of the option is as follows:
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=Y | Length=var | Mask-Len-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Destination-Prefix-1 | Mask-Len-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination-Prefix-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Length
The length of the SSM Range Discovery option is variable and is
equal to five times the number of destination ranges present in the
option.
Destination-Prefix-n
The multicast destination address prefix of nth range present in
this option.
Mask-Len-n
The mask length for the nth address range.
A router receiving a Multicast Router Discovery message with an SSM
Range Discovery Option must compare the contents of the option with the
multicast address ranges ranges in the local SSM configuration and
signal any differences to the administrator.
4.2. Communicating Range to Source Systems
When an application in an IP system uses the MSNIP API to register
for notification, the IP system must behave differently depending on
whether or not the destination address for which the application
registered is operating under SSM. For SSM channels, the IP system
should only instruct the application to transmit when there are
receivers for the multicast destination. For non-SSM destination
addresses the IP system will not be able to determine if there are
receivers and should immediately instruct the application to transmit.
To be able to differentiate between SSM and non-SSM multicast
destination addresses a source IP system must know the SSM range which
is configured on the first-hop routers. One method for an IP system to
discover the SSM range would be to listen to Multicast Router
Advertisement messages and use the information in the SSM Range option.
However, as currently specified, IGMP Multicast Router Discovery
messages are sent to the ALL-Routers (224.0.0.2) multicast destination
address to which host IP systems do not normally subscribe.
Three options are under consideration for the mechanism to distribute
the MSNIP managed range (SSM range) to host IP systems:
o Make hosts listen to the ALL-Routers multicast destination for IGMP
Multicast Router Discovery messages.
o Use a separate MSNIP control message and nominate a router as
responsible for communicating the range to hosts. This option is
presented in more detail below using the IGMP querier as the router
responsible for distributing the MSNIP / SSM range.
o Do not use the IGMP Multicast Router Discovery SSM Range option to
distribute the information between routers. Instead use an MSNIP
message that hosts receive as well. Note that such a separate
mechanism would not have the size limitations of the router discovery
option.
4.2.1. MSNIP Range Map Messages
This section describes the option of using a separate MSNIP control
message for communicating the SSM multicast address range to host IP
systems. Communicating the range is left up to the IGMP querying
router. The querier periodically multicasts a MSNIP Range Map message
containing the definition of the address ranges over which MSNIP
operates. The destination of the Range Map message is the ALL-SYSTEMS
multicast address. The Range Map message is sent every [Range Map
Interval] seconds. The message also contains a holdtime which is set to
[Range Map Holdtime] and instructs IP systems to maintain the range
mapping state for the specified holdtime.
In addition to the periodic transmission, triggered Range Map messages
are sent when either:
o the IGMP querier on a link receives an Interest Solicitation message 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 (described in section 5.1 ) from an IP system that was not previously
registered with MSNIP or was registered with a different GenID (see registered with MSNIP or was registered with a different GenID (see
section 6.2. section 9.2 ).
o the configured ranges over which MSNIP operated change.
When either of the above two events occur the querier initiates a set of o the configured SSM address range on the querier changes.
[Robustness Variable] Group Map messages.
Upon receipt of a Group Map message, an IP system builds or updates When either of these two events occur the querier initiates transmission
a set of group range records as follows. For each group range present in of a set of [Robustness Variable] Range Map messages.
the message, the system either creates or updates a record of the form:
(interface, group prefix, group mask) Upon receipt of a Range Map message, an IP system builds or updates
a set of range records as follows. For each multicast address range
present in the message, the system either creates or updates a record of
the form:
Where interface is the interface the Group Map message was received on (interface, range prefix, range mask)
and prefix and mask are the definition of the group range.
Each previously existing range record with an interface equal to Where interface is the interface the Range Map message was received on
the interface the message was received on which is not reported in the and prefix and mask are the definition of the address range. If range
received message is deleted. records which were created by a previous Range Map message received on
this interface are not present in the current message, these records are
deleted.
In addition to the group range records, the IP system maintains a In addition to the address range records, the IP system maintains a
holdtime timer associated with the interface which is initialised to the holdtime timer associated with the interface which is initialised to the
holdtime in the received message. If the timer expires before 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 receipt of the next Range Map message, all multicast address range
interface are deleted. records related to the interface are deleted.
3.2. Host Interest Solicitation 5. Requesting and Receiving Notifications
Hosts that wish to be managed by MSNIP periodically transmit an Like IGMP, MSNIP is an asymmetric protocol specifying different
Interest Solicitation message. This message is multicast with a group behaviours for systems wishing to source traffic and for multicast
destination address of ALL_IGMPv3_ROUTERS (224.0.0.22) and is routers. Host IP systems multicast Host Interest Solicitation messages
transmitted every [Interest Solicitation Interval] seconds. The Interest to register for notification with their first-hop routers. Routers
Solicitation message contains a holdtime which is set to [Interest unicast Router Receiver Membership Reports to IP system to notify them
Solicitation Holdtime] and instructs the routers to maintain MSNIP state of the arrival of the first or departure of the last receivers for a
for this system for the specified period. A generation ID is also session. Note that a system may perform at the same time both of the
included in the Interest Solicitation message to provide support for above functions. An example is a router that wishes to source traffic.
routers to detect system crashes (see section 6.2).
5.1. Host Interest Solicitation
Source systems that wish to be managed by MSNIP periodically
transmit an Interest Solicitation message. This message is multicast
with a multicast 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 multicast first-hop
routers to maintain MSNIP state for this IP system for the specified
period. A generation ID is also included in the Interest Solicitation
message to provide support for routers to detect IP system crashes (see
section 9.2).
When an IP system first comes up it transmits [Robustness Variable] When an IP system first comes up it transmits [Robustness Variable]
Interest Solicitation messages randomly spaced over [Initial Interest Interest Solicitation messages randomly spaced over [Initial Interest
Solicitation Interval] seconds. Solicitation Interval] seconds.
All MSNIP capable routers on the link that receive an Interest All MSNIP capable routers that receive an Interest Solicitation
Solicitation message from an IP system, maintain a system interest message from an IP system, maintain a system interest record of the
record of the form: form:
(IP system address, holdtime timer) (IP system address, holdtime timer)
Each time an Interest Solicitation message is received from the IP Each time an Interest Solicitation message is received from the IP
system, the holdtime timer is reset to the holdtime in the received system, the holdtime timer is reset to the holdtime in the received
message. In addition the router responds to the solicitation message message. In addition the router responds to the solicitation message
with a Receiver Membership Report message described in section 3.3. The with a Receiver Membership Report message described in section 5.2. The
message contains a TRANSMIT group record for each of the group addresses message contains a TRANSMIT record for each of the multicast destination
within the MSNIP managed range for which the routing protocol indicates addresses within the MSNIP managed range for which the routing protocol
there are receivers for this source system. indicates there are receivers for this source system.
When the holdtime timer of a specific system interest record When the holdtime timer of a specific system interest record
expires, the record is deleted. expires, the record is deleted.
3.3. Router Receiver Membership Reports 5.2. Router Receiver Membership Reports
Receiver Membership Report messages are used by routers to Receiver Membership Report messages are used by routers to
communicate the receiver membership status of particular groups to a communicate the receiver membership status of particular multicast
specific IP system. Each message contains a list of group records of destination addresses to a specific IP system. Each message contains a
either TRANSMIT or HOLD type that instruct a system to respectively list of transmission control records of either TRANSMIT or HOLD type
start or stop sending traffic on this link to the specified group that instruct a system to respectively start or stop sending traffic on
this link to the specified multicast destination address. Receiver
address. Receiver Membership Report messages are unicast to the target Membership Report messages are unicast to the target system.
system.
In addition to the receipt of an Interest Solicitation message, In addition to the receipt of an Interest Solicitation message,
routers send Receiver Membership Reports to IP systems when the receiver routers send unsolicited Receiver Membership Reports to IP systems when
membership status reported by the multicast routing protocol changes for the receiver membership status reported by the multicast routing
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 protocol changes for a specific source and multicast destination. Such
a previously received Interest Solicitation message with a IP system reports are only sent if the destination address is managed by MSNIP and
address equal to the source address. If the source group pair satisfy the router has a system interest record created by a previously received
these conditions then [Robustness Variable] Receiver Membership Reports Interest Solicitation message with a IP system address equal to the
are sent out within [Unsolicited Membership Report Interval] seconds. If source address. If the source destination pair satisfy these conditions
during the [Unsolicited Membership Report Interval] an additional then [Robustness Variable] Receiver Membership Reports are sent out
membership change occurs for the same group and source system, within [Unsolicited Membership Report Interval] seconds. If during the
transmission of any related pending Receiver Membership Report messages [Unsolicited Membership Report Interval] an additional membership change
is canceled and a new set of [Robustness Variable] messages is occurs for the same destination address and source system, transmission
scheduled. of any related pending Receiver Membership Report messages is cancelled
and a new set of [Robustness Variable] messages is scheduled.
When an IP system receives a Receiver Membership Report message, When an IP system receives a Receiver Membership Report message,
for each of the TRANSMIT group records listed in the message it creates for each of the TRANSMIT records listed in the message it creates or
or updates a group record of the form: updates a transmission record of the form:
(interface, router address, group address, holdtime timer) (router address, source address, multicast address, holdtime timer)
Where the interface is the one the message was received on, the outer The router address is obtained from the source address on the IP header
address is obtained from the source address on the IP header of the of the received message. The source address is obtained from the
received message and the holdtime timer is set to [Interest Solicitation destination address in the of the IP header. The holdtime timer is set
Holdtime] seconds. to [Interest Solicitation Holdtime] seconds.
For each group HOLD group record present in the message, the system For each HOLD record present in the message, the system deletes the
deletes the relevant group record from its state. matching previously created transmission record from its state.
4. Application Notification Note that creation and deletion of transmission records in an IP
systems state may cause local applications to be notified to start and
stop transmitting data (see section 7).
This section describes how protocol events trigger notifications to 6. Routerless Operation
source applications within an IP system.
As defined in this specification MSNIP provides receiver membership
notification services for multicast networks operating an SSM routing
protocol. The protocol operates between the source IP system and the
first-hop routers. Although not obvious, local receivers on the same
link as the multicast source do not require special handling. Local
receivers use the usual process of joining the SSM channel through
IGMPv3 source specific joins. IGMP makes the local membership
information available to the routing protocol on all routers on the
link. The routing protocol is then responsible for electing the router
that will be responsible for acting on behalf of the local receivers (in
PIM this is the Designated Router or the PIM Assert winner). Normal
operation then results in MSNIP being notified and the source signalled
to start transmitting.
A special case that is not handled by default is that of a link not
connected to a routed multicast network. On a link with only senders and
receivers but no routers MSNIP capable sources do not have a mechanism
for being notified about the existence of local receivers. However,
since there is no router to send out Range Map messages, IP systems
assume that there are no MSNIP managed address ranges and all
applications default to transmitting immediately. Therefore expected
behaviour (without MSNIP) is preserved.
In order to prevent source flooding in a routerless link when there
are no local receivers for the data, MSNIP requires that one of the IP
systems on the link acts as an MSNIP server. This server must implement
the router side of the IGMPv3 and MSNIP protocols. The MSNIP server
must be configured with a multicast address range that is to be managed
which will then be advertised in the Range Map messages. When IGMPv3
Source Specific reports are received for sources on the link, the IGMP
component in the server must notify the MSNIP component. If the
multicast destination address for which the report was received is a
managed address then MSNIP can perform its usual functions to control
the source.
7. Application Notification
This section describes the relation between protocol events and
notifications to source applications within an IP system. The state
machine below is specific to each source address of the IP system and
each multicast destination address. The initial state is the No Info
state.
+-----------------------------------+ +-----------------------------------+
| Figures omitted from text version | | Figures omitted from text version |
+-----------------------------------+ +-----------------------------------+
Figure 1: Per Interface (I) and Group (G) state machine at an IP system Figure 1: Per source-address (S) and multicast destination address (G) state
machine at an IP system
In tabular form, the state-machine is: In tabular form, the state-machine is:
+-----------+-----------------------------------------------------------+ +-----------+-----------------------------------------------------------+
| | Event | | | Event |
| +----------+-----------+------------+-----------+-----------+ | +----------+-----------+------------+-----------+-----------+
|Prev State |New |Start |Stop |Recv |Recv last | |Prev State |New |Start |Stop |Recv |Recv last |
| |Register |Manage |Manage |TRANSMIT |HOLD or | | |Register |Manage |Manage |TRANSMIT |HOLD or |
| | | | | |timeout | | | | | | |timeout |
+-----------+----------+-----------+------------+-----------+-----------+ +-----------+----------+-----------+------------+-----------+-----------+
skipping to change at page 8, line 32 skipping to change at page 13, line 32
+-----------+----------+-----------+------------+-----------+-----------+ +-----------+----------+-----------+------------+-----------+-----------+
| |Start new |- |-> No Info |- |-> Hold | | |Start new |- |-> No Info |- |-> Hold |
|Transmit | | | | |Stop ALL | |Transmit | | | | |Stop ALL |
| | | | | |registered | | | | | | |registered |
+-----------+----------+-----------+------------+-----------+-----------+ +-----------+----------+-----------+------------+-----------+-----------+
The events in state machine above have the following meaning: The events in state machine above have the following meaning:
New register New register
A new application has registered through a call to A new application has registered through a call to
IPMulticastsSourceRegister for this G and I. IPMulticastsSourceRegister for this S and G.
Start manage Start manage
We received a Group Map packet on I that changed the status of G We received a Range Map packet on the interface that S belongs to
from a non-managed to a MSNIP managed group. that changed the status of G from a non-managed to a MSNIP managed
destination address.
Stop manage Stop manage
We received a Group Map packet on I that changed the status of G We received a Range Map packet on the interface that S belongs to
from a MSNIP managed to a non-managed group or the mapping that that changed the status of G from a MSNIP managed to a non-managed
caused this group to be managed expired. destination address or the mapping state that caused this
destination address to be managed expired.
Receive TRANSMIT Receive TRANSMIT
We received a Receiver Membership Report on I that contains a We received a Receiver Membership Report with S as the IP
TRANSMIT group record for G. destination address that contains a TRANSMIT record for G.
Receive last HOLD or timeout Receive last HOLD or timeout
We either received a Receiver Membership Report on I that contains We either received a Receiver Membership Report with S as the IP
a HOLD group record for G or a TRANSMIT group record gor G on I destination address that contains a HOLD record for G or a TRANSMIT
expired and there are no other transmit records for G on I. This record for S and G expired and there are no other TRANSMIT records
means that there are no routers left wishing to receive traffic for S and G. This means that the last router that was reporting
from this system to group G on I. receivers no longer does so and there are no routers left wishing
to receive traffic from this S to destination address G.
The state machine actions have the following meaning: The state machine actions have the following meaning:
Start new Start new
Send an IPMulticastSourceStart notification to the application that Send an IPMulticastSourceStart notification to the application that
just registered for this G and I. just registered for this S and G.
Start ALL registered Start ALL registered
Send an IPMulticastSourceStart notification to all applications Send an IPMulticastSourceStart notification to all applications
that are registered for this G and I. that are registered for this S and G.
Stop ALL registered Stop ALL registered
Send an IPMulticastSourceStop notification to all applications that Send an IPMulticastSourceStop notification to all applications that
are registered for this G and I. are registered for this S and G.
5. Router Processing 8. Router Processing
This section describes the per-source system tracking that takes This section describes the per-source system tracking state machine
place within a router. operated by each first-hop router. The initial state is No Info.
+-----------------------------------+ +-----------------------------------+
| Figures omitted from text version | | Figures omitted from text version |
+-----------------------------------+ +-----------------------------------+
Figure 2: Per IP source system (S) state machine at a router Figure 2: Per IP source system (S) state machine at a router
In tabular form, the state-machine is: In tabular form, the state-machine is:
+------------++---------------------------------------------------------+ +------------+----------------------------------------------------------+
| || Event | | | Event |
| ++------------+-----------+-------------+------------------+ | +------------+-----------+--------------+------------------+
|Prev State || Receive | HIS | Receivers | Receivers | |Prev State | Receive | HIS | Receivers | Receivers |
| || HIS | timeout | for new | of G leave | | | HIS | timeout | for new | of G leave |
| || | | group G | | | | | | destination | |
+------------++------------+-----------+-------------+------------------+ | | | | G | |
| || -> | - | - | - | +------------+------------+-----------+--------------+------------------+
| || Tracking | | | | | | -> | - | - | - |
| || Set HT to | | | | | | Tracking | | | |
|Not || message | | | | | | Set HT to | | | |
|tracking || holdtime | | | | |Not | message | | | |
| || Send ALL | | | | |tracking | holdtime | | | |
| || existing | | | | | | Send ALL | | | |
| || TRANSMITs | | | | | | existing | | | |
+------------++------------+-----------+-------------+------------------+ | | TRANSMITs | | | |
|Tracking || Set HT to | -> Not | Send | Send HOLD | +------------+------------+-----------+--------------+------------------+
| || message | tracking | TRANSMIT | for G | |Tracking | Set HT to | -> Not | Send | Send HOLD |
| || holdtime | | for G | | | | message | tracking | TRANSMIT | for G |
+------------++------------+-----------+-------------+------------------+ | | holdtime | | for G | |
+------------+------------+-----------+--------------+------------------+
The events in state machine above have the following meaning: The events in state machine above have the following meaning:
Receive HIS Receive HIS
The router has received a Host Interest Solicitation from S. The router has received a Host Interest Solicitation from S.
HIS timeout HIS timeout
The holdtime timer (HT) associated with S has expired. The holdtime timer (HT) associated with S has expired.
Receivers for new group G Receivers for new destination G
The routing protocol has informed MSNIP that it now has receivers The routing protocol has informed MSNIP that it now has receivers
for the MSNIP managed group G and system S. for the MSNIP managed destination address G and source IP system S.
Receivers of G leave Receivers of G leave
The routing protocol has informed MSNIP that all receivers for the The routing protocol has informed MSNIP that all receivers for the
MSNIP managed group G and system S have left. MSNIP managed destination address G and source IP system S have
left the channel.
The state machine actions have the following meaning: The state machine actions have the following meaning:
Set HT to message holdtime Set HT to message holdtime
The holdtime timer associated with S is restarted to the value of The holdtime timer associated with S is restarted to the value of
the holdtime in the received Host Interest Solicitation message. the holdtime in the received Host Interest Solicitation message.
Send ALL existing TRANSMITs Send ALL existing TRANSMITs
The router builds and transmits Receiver Membership Reports to S The router builds and transmits Receiver Membership Reports to S
that contain a TRANSMIT group block for each of the MSNIP managed that contain a TRANSMIT record for each of the MSNIP managed
groups that have receivers for S. destination addresses that have receivers for S.
Send TRANSMIT for G Send TRANSMIT for G
The router builds and transmits a Receiver Membership Report to S The router builds and transmits a Receiver Membership Report to S
that contains a TRANSMIT group block for the group G. that contains a TRANSMIT record for the destination address G.
Send HOLD for G Send HOLD for G
The router builds and transmits a Receiver Membership Report to S The router builds and transmits a Receiver Membership Report to S
that contains a HOLD group block for the group G. that contains a HOLD record for the destination address G.
6. Message Formats 9. Message Formats
Like all other IGMP messages, MSNIP messages are encapsulated in Like all other IGMP messages, MSNIP messages are encapsulated in
IPv4 datagrams, with an IP protocol number of 2. Every MSNIP message 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 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. carries an IP Router Alert option [RFC-2113] in its IP header.
There are three IGMP message types of concern to the MSNIP protocol There are three IGMP message types of concern to the MSNIP protocol
described in this document: described in this document:
+-------------------+----------------------------+ +-------------------+----------------------------+
| Type Number (hex) | Message Name | | Type Number (hex) | Message Name |
+-------------------+----------------------------+ +-------------------+----------------------------+
| 0x23 | Group Map | | 0x23 | Range Map |
+-------------------+----------------------------+ +-------------------+----------------------------+
| 0x24 | Interest Solicitation | | 0x24 | Interest Solicitation |
+-------------------+----------------------------+ +-------------------+----------------------------+
| 0x25 | Receiver Membership Report | | 0x25 | Receiver Membership Report |
+-------------------+----------------------------+ +-------------------+----------------------------+
6.1. Group Map Packet 9.1. Range Map Packet
A Group Map packet is periodically multicast by the IGMP querier to A Range Map packet is periodically multicast by the IGMP querier to
declare the multicast group ranges manages by MSNIP. The Group Map declare the multicast destination address ranges managed by MSNIP. The
message is multicast with a group destination address of Range Map message is multicast with a destination address of ALL_SYSTEMS
ALL_IGMPv3_ROUTERS (224.0.0.22). (224.0.0.1).
0 1 2 3 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 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 | | Type = 0x23 | Range Count | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Holdtime | | Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group-Prefix-1 | | Destination-Prefix-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask-Len-1 | Reserved | | Mask-Len-1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Group Count Range Count
The number of group range records present in this message. Note The number of multicast destination address range records present
that the actual maximum number of group ranges that can be reported in this message. Note that the actual maximum number of ranges that
is limited by the maximum size of an IP packet. As each Group Map can be reported is limited by the maximum size of an IP packet. As
packet replaces the mapping at a receiving system, a router cannot each Range Map packet replaces the mapping at a receiving system, a
split a group mapping into more than one Group Map packets. router cannot split the range mapping into more than one Range Map
packets.
Checksum Checksum
The Checksum is the 16-bit one's complement of the one's complement 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 sum of the whole MSNIP message (the entire IP payload). For
computing the checksum, the Checksum field is set to zero. When computing the checksum, the Checksum field is set to zero. When
receiving packets, the checksum MUST be verified before processing receiving packets, the checksum MUST be verified before processing
a packet. a packet.
Holdtime Holdtime
The amount of time a receiving system must keep the group map state The amount of time a receiving system must keep the range map state
alive, in seconds. alive, in seconds.
Group-Prefix-1 Destination-Prefix-1
The group prefix of the first group record present in this message. The destination address range prefix of the first range record
present in this message.
Mask-Len-1 Mask-Len-1
The mask length for the group range in the first group record The mask length for the destination address range in the first
present in this message. record present in this message.
Reserved Reserved
Transmitted as zero. Ignored upon receipt. Transmitted as zero. Ignored upon receipt.
6.2. Interest Solicitation Packet 9.2. Interest Solicitation Packet
A Interest Solicitation packet is periodically multicast by MSNIP A Interest Solicitation packet is periodically multicast by MSNIP
capable systems to declare interest in Receiver Membership Reports from capable systems to declare interest in Receiver Membership Reports from
multicast routers on the link. The Interest Solicitation message is multicast routers on the link. The Interest Solicitation message is
multicast with a group destination address of ALL_IGMPv3_ROUTERS multicast with a destination address of ALL_IGMPv3_ROUTERS (224.0.0.22).
(224.0.0.22).
0 1 2 3 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 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 | | Type = 0x24 | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Holdtime | GenID | | Holdtime | GenID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved Reserved
Transmitted as zero. Ignored upon receipt. Transmitted as zero. Ignored upon receipt.
Checksum Checksum
Calculated as for Group Map packet. Calculated as for Range Map packet.
Holdtime Holdtime
The amount of time a receiving router must keep the system interest The amount of time a receiving router must keep the system interest
state alive, in seconds. state alive, in seconds.
GenID GenID
Generation ID of the IP system. A number that is selected randomly Generation ID of the IP system. A number that is selected randomly
for each of the [Robustness Variable] initial Interest Solicitation for each of the [Robustness Variable] initial Interest Solicitation
messages when the system comes up and afterwards remains fixed to messages when the system comes up and afterwards remains fixed to
the value used in the last of the initial messages throughout the the value used in the last of the initial messages throughout the
system lifetime. The GenID is used by routers to detect system system lifetime. The GenID is used by routers to detect system
crashes. crashes.
6.3. Group Membership Report Packet 9.3. Receiver Membership Report Packet
A Group Membership Report packet is unicast by first-hop multicast A Receiver Membership Report packet is unicast by first-hop multicast
routers and targeted at potential sources to inform them of the routers and targeted at potential sources to inform them of the
existence or not of receivers for the listed multicast groups. existence or not of receivers for the listed multicast destination
addresses.
0 1 2 3 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 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 | | Type = 0x25 | Dest Count | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record-Type-1 | Reserved | | Record-Type-1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group-Address-1 | | Destination-Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Group Count Dest Count
The number of group records present in this message. The number of multicast destination address records present in this
message.
Checksum Checksum
Calculated as for Group Map packet. Calculated as for Range Map packet.
Record-Type-1 Record-Type-1
The type of the first group record in this message. Valid values The type of the first transmission control record in this message.
are: Valid values are:
+-------------+-------------------------------------+-------+ +-------------+----------------------------------------------+-------+
| Record Type | Description | Value | | Record Type | Description | Value |
+-------------+-------------------------------------+-------+ +-------------+----------------------------------------------+-------+
| TRANSMIT | Request to start transmitting group | 1 | | TRANSMIT | Request to start transmitting to destination | 1 |
+-------------+-------------------------------------+-------+ +-------------+----------------------------------------------+-------+
| HOLD | Request to stop transmitting group | 2 | | HOLD | Request to stop transmitting to destination | 2 |
+-------------+-------------------------------------+-------+ +-------------+----------------------------------------------+-------+
Reserved Reserved
Transmitted as zero. Ignored upon receipt. Transmitted as zero. Ignored upon receipt.
Group-Address-1 Destination-Address-1
The multicast address of the first group record in the message. The multicast destination address of the first record in the
message.
7. Constants Timers and Default Values 10. Constants Timers and Default Values
Robustness Variable Robustness Variable
The Robustness Variable allows tuning for the expected packet loss The Robustness Variable allows tuning for the expected packet loss
on a network. If a network is expected to be lossy, the Robustness on a network. If a network is expected to be lossy, the Robustness
Variable may be increased. MSNIP is robust to (Robustness Variable Variable may be increased. MSNIP is robust to (Robustness Variable
- 1) packet losses. The Robustness Variable MUST NOT be zero, and - 1) packet losses. The Robustness Variable MUST NOT be zero, and
SHOULD NOT be one. Default: 2 SHOULD NOT be one. Default: 2
Group Map Interval Range Map Interval
The interval used by the IGMP querier between transmissions of The interval used by the IGMP querier between transmissions of
Group Map messages. Default: 60 secs Range Map messages. Default: 60 secs
Group Map Holdtime Range Map Holdtime
The interval inserted in Group Map messages that indicates to The interval inserted in Range Map messages that indicates to
systems how long they should use the included mapping information systems how long they should use the included mapping information
before they time it out. This MUST be ((the Robustness Variable) before they time it out. This MUST be ((the Robustness Variable)
times (the Group Map Interval) plus (one second)). times (the Range Map Interval) plus (one second)).
Interest Solicitation Interval Interest Solicitation Interval
The interval used by MSNIP capable systems between transmissions of The interval used by MSNIP capable systems between transmissions of
Interest Solicitation messages. Default: 60 secs Interest Solicitation messages. Default: 60 secs
Interest Solicitation Holdtime Interest Solicitation Holdtime
The interval inserted in Interest Solicitation messages by systems The interval inserted in Interest Solicitation messages by systems
to instruct routers how long they should maintain system interest to instruct routers how long they should maintain system interest
state for. This MUST be ((the Robustness Variable) times (the state for. This MUST be ((the Robustness Variable) times (the
Interest Solicitation Interval) plus (one second)). Interest Solicitation Interval) plus (one second)).
Initial Interest Solicitation Interval Initial Interest Solicitation Interval
The interval used by systems to send out the initial Interest The interval used by systems to send out the initial Interest
Solicitation messages when they first come up. Default: 1 second. Solicitation messages when they first come up. Default: 1 second.
Unsolicited Membership Report Interval Unsolicited Membership Report Interval
The interval used by routers to send out a set of Membership Report The interval used by routers to send out a set of Membership Report
messages when the group membership changes for a specific system. messages when the receiver membership changes for a specific
Default: 1 second. system. Default: 1 second.
8. Todo list... 11. Todo list...
o Add security considerations section. o Add security considerations section.
o Cover IPv6.
o If application ignores or does not ask for notification in managed o If application ignores or does not ask for notification in managed
range host OS should filter packets. range host OS should filter packets.
o Maybe provide masks for registration / notification API. o Maybe provide masks for registration / notification API.
o Case where host and app starts before MSNIP range is available. 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 When we hear out-of-order IGMP query resend interest registration.
o Only send interest registration when application is interested. This o Only send interest registration when application is interested. This
is not possible if we do host filtering... is not possible if we do host filtering...
o Maybe add API to ask the kernel for the state of a particular group. o Maybe add API to ask the kernel for the state of a particular
bool IpMulticastSourceHasInterest (socket, interface, multicast- destination. bool IpMulticastSourceHasInterest (socket, source-
address). address, multicast-address).
o Add GenID changes to router FSM. o Add GenID changes to router FSM.
9. Authors' Addresses 12. Acknowledgements
The authors would like to thank Dave Thaler and Jon Crowcroft for their
contribution to this specification.
13. Authors' Addresses
Bill Fenner Bill Fenner
AT&T Labs - Research AT&T Labs - Research
75 Willow Road 75 Willow Road
Menlo Park, CA 94025 Menlo Park, CA 94025
fenner@research.att.com fenner@research.att.com
Hugh Holbrook Hugh Holbrook
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
skipping to change at page 17, line 4 skipping to change at page 22, line 18
AT&T Labs - Research AT&T Labs - Research
75 Willow Road 75 Willow Road
Menlo Park, CA 94025 Menlo Park, CA 94025
fenner@research.att.com fenner@research.att.com
Hugh Holbrook Hugh Holbrook
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
holbrook@cisco.com holbrook@cisco.com
Isidor Kouvelas Isidor Kouvelas
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
kouvelas@cisco.com kouvelas@cisco.com
10. Acknowledgments 14. References
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 [1] B. Cain, S Deering, W. Fenner, I Kouvelas, A. Thyagarajan, "Internet
Group Management Protocol, Version 3", Work In Progress, <draft- Group Management Protocol, Version 3", Work In Progress, <draft-
ietf-idmr-igmp-v3-05.txt>, 2000. ietf-idmr-igmp-v3-05.txt>, 2000.
[2] S. Kent, R. Atkinson, "Security Architecture for the Internet [2] S. Kent, R. Atkinson, "Security Architecture for the Internet
Protocol.", RFC 2401. Protocol.", RFC 2401.
[3] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol [3] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol
Independent Multicast - Sparse Mode (PIM-SM): Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)", Work In Progress, <draft-ietf-pim-sm- Specification (Revised)", Work In Progress, <draft-ietf-pim-sm-
v2-new-01.txt>, 2000. v2-new-01.txt>, 2000.
[4] Z. Albanna, K. Almeroth, D. Meyer, "IANA Guidelines for IPv4 [4] Z. Albanna, K. Almeroth, D. Meyer, "IANA Guidelines for IPv4
Multicast Address Allocation", Best Current Practices, <draft-ietf- Multicast Address Allocation", Best Current Practices, <draft-ietf-
iana-IPv4-mcast-guidelines-00.txt>, 2001. iana-IPv4-mcast-guidelines-00.txt>, 2001.
[5] S. Biswas, B. Haberman, "IGMP Multicast Router Discovery", Work In
Progress, <draft-ietf-idmr-igmp-mrdisc-07.txt>, 2001.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/