[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Internet Engineering Task Force                                  IDMR WG
INTERNET-DRAFT                                          Bill Fenner/AT&T
draft-ietf-idmr-msnip-01.txt                         Hugh Holbrook/Cisco
                                                   Isidor Kouvelas/Cisco
                                                        21 November 2001
                                                       Expires: 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.





Fenner/Holbrook/Kouvelas                                        [Page 1]


INTERNET-DRAFT              Expires: May 2002              November 2001


                           Table of Contents


     1. Introduction. . . . . . . . . . . . . . . . . . . . . .   3
     2. Routing Protocol Support. . . . . . . . . . . . . . . .   3
     3. API for Requesting Membership Notification. . . . . . .   4
     4. MSNIP Managed Address Range Negotiation . . . . . . . .   5
      4.1. Router Coordination. . . . . . . . . . . . . . . . .   6
       4.1.1. MSNIP Capability Discovery Option . . . . . . . .   6
       4.1.2. SSM Range Discovery Option. . . . . . . . . . . .   7
      4.2. Communicating Range to Source Systems. . . . . . . .   7
       4.2.1. MSNIP Range Map Messages. . . . . . . . . . . . .   8
     5. Requesting and Receiving Notifications. . . . . . . . .   9
      5.1. Host Interest Solicitation . . . . . . . . . . . . .  10
      5.2. Router Receiver Membership Reports . . . . . . . . .  10
     6. Routerless Operation. . . . . . . . . . . . . . . . . .  11
     7. Application Notification. . . . . . . . . . . . . . . .  12
     8. Router Processing . . . . . . . . . . . . . . . . . . .  14
     9. Message Formats . . . . . . . . . . . . . . . . . . . .  16
      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
























Fenner/Holbrook/Kouvelas                                        [Page 2]


INTERNET-DRAFT              Expires: May 2002              November 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] ). 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 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
the first-hop link. Using a higher level control protocol to determine
the existence of receivers for particular flows may not be practical as
there may be many potential receivers in each active session.

     Information on which multicast destination addresses have receivers
for a particular sender is typically available to the multicast routing
protocol on the first hop router 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
destination address specific state on the first-hop router for potential
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
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 periodically transmits on all potential destination
addresses and the first-hop routers prune the traffic back. Such a



Fenner/Holbrook/Kouvelas                            Section 2.  [Page 3]


INTERNET-DRAFT              Expires: May 2002              November 2001


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

     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
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, source-address, multicast-address)
    IPMulticastsSourceDeregister (socket, source-address, multicast-address)

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

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

source-address
     is the IP unicast source address that the application wishes to 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



Fenner/Holbrook/Kouvelas                            Section 3.  [Page 4]


INTERNET-DRAFT              Expires: May 2002              November 2001


     implementation may allow a special "unspecified" value to be passed
     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
     source address.

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


     Applications wising to use MSNIP to control their multicast data
transmission to destination G from source address S operate as follows.

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



Fenner/Holbrook/Kouvelas                            Section 4.  [Page 5]


INTERNET-DRAFT              Expires: May 2002              November 2001


subset of the address space that is used by source-specific multicast
(SSM) [4]. 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 transmission that does
require the application to be aware of the SSM address range. MSNIP
supports this by allowing applications to use the 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.






Fenner/Holbrook/Kouvelas                        Section 4.1.1.  [Page 6]


INTERNET-DRAFT              Expires: May 2002              November 2001


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



Fenner/Holbrook/Kouvelas                          Section 4.2.  [Page 7]


INTERNET-DRAFT              Expires: May 2002              November 2001


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.




Fenner/Holbrook/Kouvelas                        Section 4.2.1.  [Page 8]


INTERNET-DRAFT              Expires: May 2002              November 2001


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
  (described in section 5.1 ) from an IP system that was not previously
  registered with MSNIP or was registered with a different GenID (see
  section 9.2 ).

o the configured SSM address range on the querier changes.


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

     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:

     (interface, range prefix, range mask)

Where interface is the interface the Range Map message was received on
and prefix and mask are the definition of the address range.  If range
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 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 Range Map message, all multicast address range
records related to the 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.








Fenner/Holbrook/Kouvelas                            Section 5.  [Page 9]


INTERNET-DRAFT              Expires: May 2002              November 2001


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]
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



Fenner/Holbrook/Kouvelas                         Section 5.2.  [Page 10]


INTERNET-DRAFT              Expires: May 2002              November 2001


protocol changes for a specific source and multicast destination. Such
reports are only sent if the destination address 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 destination 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 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,
for each of the TRANSMIT records listed in the message it creates or
updates a transmission record of the form:

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

The router address is obtained from the source address on the IP header
of the received message. The source address is obtained from the
destination address in the of the IP 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 transmission records in an IP
systems state may cause local applications to be notified to start and
stop transmitting data (see section 7).

6.  Routerless Operation

     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



Fenner/Holbrook/Kouvelas                           Section 6.  [Page 11]


INTERNET-DRAFT              Expires: May 2002              November 2001


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 |
                    +-----------------------------------+

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
















Fenner/Holbrook/Kouvelas                           Section 7.  [Page 12]


INTERNET-DRAFT              Expires: May 2002              November 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 S and G.


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


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


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




Fenner/Holbrook/Kouvelas                           Section 7.  [Page 13]


INTERNET-DRAFT              Expires: May 2002              November 2001


Receive last HOLD or timeout
     We either received a Receiver Membership Report with S as the IP
     destination address that contains a HOLD record for G or a TRANSMIT
     record for S and G expired and there are no other TRANSMIT records
     for 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 S to 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 S and G.


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


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

8.  Router Processing

     This section describes the per-source system tracking 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














Fenner/Holbrook/Kouvelas                           Section 8.  [Page 14]


INTERNET-DRAFT              Expires: May 2002              November 2001


In tabular form, the state-machine is:

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


The state machine actions have the following meaning:




Fenner/Holbrook/Kouvelas                           Section 8.  [Page 15]


INTERNET-DRAFT              Expires: May 2002              November 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 record for each of the MSNIP managed
     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 record for the destination address G.


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

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



9.1.  Range Map Packet

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



Fenner/Holbrook/Kouvelas                         Section 9.1.  [Page 16]


INTERNET-DRAFT              Expires: May 2002              November 2001


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



Range Count
     The number of multicast destination address range records present
     in this message. Note that the actual maximum number of ranges that
     can be reported is limited by the maximum size of an IP packet. As
     each Range Map packet replaces the mapping at a receiving system, a
     router cannot split the range mapping into more than one 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 range map state
     alive, in seconds.


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






Fenner/Holbrook/Kouvelas                         Section 9.1.  [Page 17]


INTERNET-DRAFT              Expires: May 2002              November 2001


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


Reserved
     Transmitted as zero. Ignored upon receipt.


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




Fenner/Holbrook/Kouvelas                         Section 9.2.  [Page 18]


INTERNET-DRAFT              Expires: May 2002              November 2001


9.3.  Receiver Membership Report Packet

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



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


Checksum
     Calculated as for Range Map packet.


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


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



Reserved
     Transmitted as zero. Ignored upon receipt.



Fenner/Holbrook/Kouvelas                         Section 9.3.  [Page 19]


INTERNET-DRAFT              Expires: May 2002              November 2001


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

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


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


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



Fenner/Holbrook/Kouvelas                          Section 10.  [Page 20]


INTERNET-DRAFT              Expires: May 2002              November 2001


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


o Add GenID changes to router FSM.


12.  Acknowledgements

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













Fenner/Holbrook/Kouvelas                          Section 13.  [Page 21]


INTERNET-DRAFT              Expires: May 2002              November 2001


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



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.







Fenner/Holbrook/Kouvelas                          Section 14.  [Page 22]


INTERNET-DRAFT              Expires: May 2002              November 2001





















































Fenner/Holbrook/Kouvelas                          Section 14.  [Page 23]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/