Internet Engineering Task Force                                  IDMR WG
INTERNET-DRAFT                                          Bill Fenner/AT&T
draft-ietf-idmr-msnip-00.txt
draft-ietf-idmr-msnip-01.txt                         Hugh Holbrook/Cisco
                                                   Isidor Kouvelas/Cisco
                                                        23 February
                                                        21 November 2001
                                                       Expires: August 2001 May 2002

       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.

                           Table of Contents

     1. Introduction. . . . . . . . . . . . . . . . . . . . . .   3
     2. Routing Protocol Support. . . . . . . . . . . . . . . .   3
     3. API for Requesting Membership Notification. . . . . . .   3
     3. Protocol Description.   4
     4. MSNIP Managed Address Range Negotiation . . . . . . . .   5
      4.1. Router Coordination. . . . . . . . . .   4
      3.1. Group . . . . . . .   6
       4.1.1. MSNIP Capability Discovery Option . . . . . . . .   6
       4.1.2. SSM Range Negotiation. Discovery Option. . . . . . . . . . . .   7
      4.2. Communicating Range to Source Systems. . . . .   5
      3.2. . . .   7
       4.2.1. MSNIP Range Map Messages. . . . . . . . . . . . .   8
     5. Requesting and Receiving Notifications. . . . . . . . .   9
      5.1. Host Interest Solicitation . . . . . . . . . . . . .   6
      3.3.  10
      5.2. Router Receiver Membership Reports . . . . . . . . .   6
     4.  10
     6. Routerless Operation. . . . . . . . . . . . . . . . . .  11
     7. Application Notification. . . . . . . . . . . . . . . .   7
     5.  12
     8. Router Processing . . . . . . . . . . . . . . . . . . .   9
     6.  14
     9. Message Formats . . . . . . . . . . . . . . . . . . . .  11
      6.1. Group  16
      9.1. Range Map Packet . . . . . . . . . . . . . . . . . .  11
      6.2.  16
      9.2. Interest Solicitation Packet . . . . . . . . . . . .  13
      6.3. Group  18
      9.3. Receiver Membership Report Packet . Packet. . . . . . . . . . .  14
     7.  19
     10. Constants Timers and Default Values . Values. . . . . . . . . .  15
     8.  20
     11. Todo list.... list... . . . . . . . . . . . . . . . . . . . . .  16
     9. Authors' Addresses.  21
     12. Acknowledgements . . . . . . . . . . . . . . . . . .  16
     10. Acknowledgments. .  21
     13. Authors' Addresses . . . . . . . . . . . . . . . . . .  17
     11.  21
     14. References . . . . . . . . . . . . . . . . . . . . . .  17  22

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 ). MSNIP operates between multicast sources and their first-
hop routers to provide information on the presence of receivers to the
source systems. Using the services offered by MSNIP an application on an
IP system wishing to source multicast data can register to be notified
when receivers join and leave the session. This enables multicast
sources to avoid the work of
sending transmitting packets onto their first-hop
link when there are no joined receivers. The

     A common scenario where MSNIP may be useful is one where there is a
multicast server sourcing offering a large number of multicast flows from
a much larger pool of potential multicast flows that map onto
separate multicast group addresses. destination addresses but receivers exist only for a
small subset of the flows. If the source were to continuously transmit
data on for all the groups flows 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 may not be practical as
there may be many potential receivers. receivers in each active session.

     Information on which multicast groups destination addresses have receivers
for a particular sender is typically maintained by available to the multicast routing
protocol on the first hop router to the for a 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-
destination address specific state on the first-hop router for potential
sources without receivers.

     Many currently deployed multicast routing protocols, require data
from

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
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. 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
as PIM-SM [3] ). In order to provide receiver interest notification for
such protocols, the default mode of operation would require that the
source IP system always periodically transmits on all potential groups destination
addresses and the first-hop routers prune the traffic back. Such a

flood-and-prune behaviour on the first-hop link significantly diminishes
the benefits of managing source transmission.

     In order to avoid this complication MSNIP only supports contrast, with source-specific sparse-mode
multicast routing protocols that build source-specific trees (such such as
PIM-SSM [3] ). With such protocols, the first-hop router can obtain availability of receiver membership information on the existence
first-hop routers is independent of receivers without forwarding any data
from the source. Support transmission. Such protocols
use an external mechanism for this type 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.

2. 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
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
the following operation or any logical equivalent:

    IPMulticastsSourceRegister (socket, interface, source-address, multicast-address)
    IPMulticastsSourceDeregister (socket, interface, source-address, multicast-address)

     In addition the application must provide the following API for
receiving notifications from the IP system:

    IPMulticastSourceStart (socket, interface, source-address, multicast-address)
    IPMulticastSourceStop (socket, interface, source-address, 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

source-address
     is a local identifier of the network interface on which IP unicast source address that the application wishes to transmit use
     in transmitting data to the specified multicast address. The
     specified address must be one of the IP addresses associated with
     the network interfaces of the IP system. Note that an interface in
     an IP system may be associated with more than one IP addresses.  An
     implementation may allow a special "unspecified" value to be passed
     as the interface 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 on using more than one interface, source IP address,
     IPMulticastSourceRegister is invoked separately for each desired
     interface.
     source address.

multicast-address
     is the IP multicast destination address to which the request
     pertains.  If
     transmission the application wishes to transmit data to more than
     one multicast address on for a given
     interface is desired, source address,
     IPMulticastSourceRegister is invoked separately for each desired
     multicast address.

3.  Protocol Description

     Like IGMP,

     Applications wising to use MSNIP is an asymmetric protocol specifying different
behaviors for systems wishing to source traffic and for control their multicast
routers. Note that a system may perform at the same time more than one
of data
transmission to destination G from source address S operate as follows.

     Initially the above functions. An example application contacts the IP system to obtain the
socket handle for use on all subsequent interactions. The application
invokes IPMulticastSourceRegister for the desired S and G and then waits
without transmitting any packets for the IP system to notify that
receivers for the session exist.

     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 a router 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
traffic.

3.1.  Group 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
multicast routing protocols coexist and operate under different separate parts of
the
multicast-address multicast address space. Multicast routers are consistently
configured with information that maps specific group multicast address ranges
to multicast routing protocols. Part of this configuration describes the

subset of the multicast address space that is used by source-specific multicast
(SSM) [4].

     The default behavior of IP multicast, without MSNIP, As described in section 2 MSNIP only tries to control
application transmission within the SSM address range.

     It is desirable for applications within an IP system that supports
MSNIP to have a consistent API for multicast application must assume transmission that there are multicast receivers
present in does
require the network.  In order to allow hosts application to avoid transmitting
when there are no receivers, MSNIP communicates a range be aware of MSNIP managed
groups to source systems.

     This task is left up to the IGMP querying router. The querier
periodically multicasts a SSM address range. MSNIP Group Map message containing the
definition of
supports this by allowing applications to use the group ranges API described in
section 3 for multicast destination addresses that are outside its
operating range. When an application registers for notifications for a
destination address that is not managed by MSNIP it is immediately
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.

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. This The destination address of the Group Range Map message is the ALLSYSTEMS group. ALL-SYSTEMS
multicast address. The Group Range Map message is sent every [Group [Range Map
Interval] seconds. The message also contains a holdtime which is set to [Group
[Range Map Holdtime] and instructs IP systems to maintain the group range
mapping state for the specified holdtime.

In addition Group to the periodic transmission, triggered Range Map messages
are sent when either:

o the IGMP querier on a link receives an Interest Solicitation message
  (described in section 3.2 5.1 ) from an IP system that was not previously
  registered with MSNIP or was registered with a different GenID (see
  section 6.2. 9.2 ).

o the configured ranges over which MSNIP operated change. SSM address range on the querier changes.

When either of the above these two events occur the querier initiates transmission
of a set of [Robustness Variable] Group Range Map messages.

     Upon receipt of a Group Range Map message, an IP system builds or updates
a set of group range records as follows. For each group multicast address range
present in the message, the system either creates or updates a record of
the form:

     (interface, group range prefix, group range mask)

Where interface is the interface the Group Range Map message was received on
and prefix and mask are the definition of the group address range.

     Each previously existing  If range record with an interface equal to
the interface the
records which were created by a previous Range Map message was received on which is
this interface are not reported present in the
received message is current message, these records are
deleted.

     In addition to the group address 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 Range Map message, all multicast address range
records related to the
interface are deleted.

3.2. interface are deleted.

5.  Requesting and Receiving Notifications

     Like IGMP, MSNIP is an asymmetric protocol specifying different
behaviours for systems wishing to source traffic and for multicast
routers. Host IP systems multicast Host Interest Solicitation messages
to register for notification with their first-hop routers. Routers
unicast Router Receiver Membership Reports to IP system to notify them
of the arrival of the first or departure of the last receivers for a
session. Note that a system may perform at the same time both of the
above functions. An example is a router that wishes to source traffic.

5.1.  Host Interest Solicitation

     Hosts

     Source systems that wish to be managed by MSNIP periodically
transmit an Interest Solicitation message. This message is multicast
with a group 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 6.2). 9.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 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 5.2. The
message contains a TRANSMIT record for each of the multicast destination
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.

5.2.  Router Receiver Membership Reports

     Receiver Membership Report messages are used by routers to
communicate the receiver membership status of particular multicast
destination addresses to a specific IP system. Each message contains a
list of transmission control records of either TRANSMIT or HOLD type
that instruct a system to respectively start or stop sending traffic on
this link to the specified multicast destination address.  Receiver
Membership Report messages are unicast to the target system.

     In addition to the receipt of an Interest Solicitation message,
routers send unsolicited Receiver Membership Reports to IP systems when
the receiver membership status reported by the multicast routing

protocol changes for a specific source and multicast destination. Such
reports are only sent if the destination address is managed by MSNIP and
the link that receive an Interest
Solicitation message from an IP system, maintain router has a system interest record of the form:

     (IP system address, holdtime timer)

Each time an created by a previously received
Interest Solicitation message is received from the with a IP
system, the holdtime timer is reset system address equal to the holdtime in
source address. If the received
message.  In addition source destination pair satisfy these conditions
then [Robustness Variable] Receiver Membership Reports are sent out
within [Unsolicited Membership Report Interval] seconds. If during the router responds to
[Unsolicited Membership Report Interval] an additional membership change
occurs for the solicitation message
with same destination address and source system, transmission
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 described message,
for each of the TRANSMIT records listed in section 3.3. The the message contains it creates or
updates a TRANSMIT group transmission record for each of the group addresses
within the MSNIP managed range for which form:

     (router address, source address, multicast address, holdtime timer)

The router address is obtained from the routing protocol indicates
there are receivers for this source system.

     When address on the holdtime timer IP header
of a specific system interest record
expires, the record received message. The source address is deleted.

3.3.  Router Receiver Membership Reports

     Receiver Membership Report messages are used by routers to
communicate obtained from the
destination address in the receiver membership status of particular groups to a
specific the IP system. Each message contains a list header. The holdtime timer is set
to [Interest Solicitation Holdtime] seconds.

     For each HOLD record present in the message, the system deletes the
matching previously created transmission record from its state.

     Note that creation and deletion of group transmission records of
either TRANSMIT or HOLD type that instruct a system in an IP
systems state may cause local applications to be notified to respectively start or and
stop sending traffic on transmitting data (see section 7).

6.  Routerless Operation

     As defined in this link to specification MSNIP provides receiver membership
notification services for multicast networks operating an SSM routing
protocol. The protocol operates between the specified group

address.  Receiver Membership Report messages are unicast to source IP system and the target
system.

     In addition to
first-hop routers. Although not obvious, local receivers on the receipt same
link as the multicast source do not require special handling.  Local
receivers use the usual process of an Interest Solicitation message,
routers send Receiver Membership Reports to IP systems when joining the receiver SSM channel through
IGMPv3 source specific joins. IGMP makes the local membership status reported by
information available to the multicast routing protocol changes on all routers on the
link. The routing protocol is then responsible for
a specific source and group. Such reports are only sent if electing the router
that will be responsible for acting on behalf of the group local receivers (in
PIM this is
managed by the Designated Router or the PIM Assert winner).  Normal
operation then results in MSNIP being notified and the router has a system interest record created source signalled
to start transmitting.

     A special case that is not handled by default is that of a previously received Interest Solicitation message 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 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 mechanism
for being notified about the same group and source system,
transmission existence of any related pending Receiver Membership Report messages local receivers.  However,
since there is canceled no router to send out Range Map messages, IP systems
assume that there are no MSNIP managed address ranges and a new set of [Robustness Variable] messages all
applications default to transmitting immediately. Therefore expected
behaviour (without MSNIP) is
scheduled.

     When an IP system receives preserved.

     In order to prevent source flooding in a Receiver Membership Report message, routerless link when there
are no local receivers for each of the TRANSMIT group records listed in the message it creates
or updates a group record data, MSNIP requires that one of the form:

     (interface, router address, group address, holdtime timer)

Where the interface is IP
systems on the one link acts as an MSNIP server. This server must implement
the message was received on, router side of the outer IGMPv3 and MSNIP protocols.  The MSNIP server
must be configured with a multicast address range that is obtained from to be managed
which will then be advertised in the source address Range Map messages.  When IGMPv3
Source Specific reports are received for sources on the IP header of the
received message and link, the holdtime timer is set to [Interest Solicitation
Holdtime] seconds.

     For each group HOLD group record present IGMP
component in the message, server must notify the system
deletes MSNIP component. If the relevant group record from
multicast destination address for which the report was received is a
managed address then MSNIP can perform its state.

4. usual functions to control
the source.

7.  Application Notification

     This section describes how the relation between protocol events trigger 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 |
                    +-----------------------------------+

     Figure 1: Per Interface (I) source-address (S) and Group multicast destination address (G) state
     machine at an IP system

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 S and I. G.

Start manage
     We received a Group Range Map packet on I the interface that S belongs to
     that changed the status of G from a non-managed to a MSNIP managed group.
     destination address.

Stop manage
     We received a Group Range Map packet on I the interface that S belongs to
     that changed the status of G from a MSNIP managed to a non-managed group
     destination address or the mapping state that caused this group
     destination address to be managed expired.

Receive TRANSMIT
     We received a Receiver Membership Report on I with S as the IP
     destination address that contains a TRANSMIT group record for G.

Receive last HOLD or timeout
     We either received a Receiver Membership Report on I with S as the IP
     destination address that contains a HOLD group record for G or a TRANSMIT group
     record gor for S and G on I expired and there are no other transmit TRANSMIT records
     for G on I. S and G. This means that the last router that was reporting
     receivers no longer does so and there are no routers left wishing
     to receive traffic from this system S to group G on I. destination address G.

The state machine actions have the following meaning:

Start new
     Send an IPMulticastSourceStart notification to the application that
     just registered for this G S and I. G.

Start ALL registered
     Send an IPMulticastSourceStart notification to all applications
     that are registered for this G S and I. G.

Stop ALL registered
     Send an IPMulticastSourceStop notification to all applications that
     are registered for this G S and I.

5. G.

8.  Router Processing

     This section describes the per-source system tracking that takes
place within a state machine
operated by each first-hop router. The initial state is No Info.

                    +-----------------------------------+
                    | Figures omitted from text version |
                    +-----------------------------------+

        Figure 2: Per IP source system (S) state machine at a router

In tabular form, the state-machine is:

+------------++---------------------------------------------------------+

+------------+----------------------------------------------------------+
|            |            ||                          Event                           |
|            ++------------+-----------+-------------+------------------+            +------------+-----------+--------------+------------------+
|Prev State  ||  | Receive    | HIS       | Receivers    | Receivers        |
|            ||            | HIS        | timeout   | for new      | of G leave       |
|            ||            |            |  group           | destination  |                  |
|            |            |           | 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 destination G
     The routing protocol has informed MSNIP that it now has receivers
     for the MSNIP managed group destination address G and source IP system S.

Receivers of G leave
     The routing protocol has informed MSNIP that all receivers for the
     MSNIP managed group destination address G and source IP system S have left.
     left the channel.

The state machine actions have the following meaning:

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 record for each of the MSNIP managed
     groups
     destination addresses 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 record for the group destination address G.

Send HOLD for G
     The router builds and transmits a Receiver Membership Report to S
     that contains a HOLD group block record for the group destination address G.

6.

9.  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 Range Map                  |
+-------------------+----------------------------+
| 0x24              | Interest Solicitation      |
+-------------------+----------------------------+
| 0x25              | Receiver Membership Report |
+-------------------+----------------------------+

6.1.  Group

9.1.  Range Map Packet

A Group Range Map packet is periodically multicast by the IGMP querier to
declare the multicast group destination address ranges manages managed by MSNIP. The Group
Range Map message is multicast with a group destination address of

ALL_IGMPv3_ROUTERS (224.0.0.22). ALL_SYSTEMS

(224.0.0.1).

 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  Range Count  |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Holdtime                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Group-Prefix-1                     Destination-Prefix-1                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Mask-Len-1   |                   Reserved                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               .                               |
|                               .                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Group

Range Count
     The number of group multicast destination address 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 Range Map packet replaces the mapping at a receiving system, a
     router cannot split a group the range mapping into more than one Group Range 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 range map state
     alive, in seconds.

Group-Prefix-1

Destination-Prefix-1
     The group destination address range prefix of the first group range record
     present in this message.

Mask-Len-1
     The mask length for the group destination address range in the first group
     record present in this message.

Reserved
     Transmitted as zero. Ignored upon receipt.

6.2.

9.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 Range 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.

6.3.  Group

9.3.  Receiver Membership Report Packet

A Group Receiver 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. destination
addresses.

 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   Dest Count  |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record-Type-1 |                  Reserved                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Group-Address-1                     Destination-Address-1                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Group
|                               .                               |
|                               .                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Dest Count
     The number of group multicast destination address records present in this
     message.

Checksum
     Calculated as for Group Range Map packet.

Record-Type-1
     The type of the first group transmission control record in this message.
     Valid values are:

     +-------------+-------------------------------------+-------+

     +-------------+----------------------------------------------+-------+
     | Record Type | Description                                  | Value |
     +-------------+-------------------------------------+-------+
     +-------------+----------------------------------------------+-------+
     | TRANSMIT    | Request to start transmitting group to destination | 1     |
     +-------------+-------------------------------------+-------+
     +-------------+----------------------------------------------+-------+
     | HOLD        | Request to stop transmitting group to destination  | 2     |
     +-------------+-------------------------------------+-------+
     +-------------+----------------------------------------------+-------+

Reserved
     Transmitted as zero. Ignored upon receipt.

Group-Address-1

Destination-Address-1
     The multicast destination address of the first group record in the
     message.

7.

10.  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

Range Map Interval
     The interval used by the IGMP querier between transmissions of
     Group
     Range Map messages. Default: 60 secs

Group

Range Map Holdtime
     The interval inserted in Group Range 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 Range 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 receiver membership changes for a specific
     system.  Default: 1 second.

8.

11.  Todo list...

o Add security considerations section.

o Cover IPv6.

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.
  destination.  bool IpMulticastSourceHasInterest (socket, interface, multicast-
  address). source-
  address, multicast-address).

o Add GenID changes to router FSM.

9.

12.  Acknowledgements

The authors would like to thank Dave Thaler and Jon Crowcroft for their
contribution to this specification.

13.  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

     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.

14.  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.

[5] S. Biswas, B. Haberman, "IGMP Multicast Router Discovery", Work In
     Progress, <draft-ietf-idmr-igmp-mrdisc-07.txt>, 2001.