[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/