One document matched: draft-ietf-magma-msnip-06.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<rfc category="std" ipr="trust200902"
docName="draft-ietf-magma-msnip-06.txt">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="MSNIP">Multicast Source Notification of Interest Protocol
(MSNIP)</title>
<author initials='B.' surname='Fenner' fullname='Bill Fenner'>
<organization>AT&T Labs--Research</organization>
<address><postal>
<street>1 River Oaks Place</street>
<city>San Jose</city> <region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>fenner@research.att.com</email></address>
</author>
<author initials='B.' surname='Haberman' fullname='Brian Haberman'>
<organization>Johns Hopkins University Applied Physics Lab</organization>
<address><postal>
<street>11100 Johns Hopkins Road</street>
<city>Laurel</city> <region>MD</region>
<code>20723-6099</code>
<country>USA</country>
</postal>
<email>brian@innovationslab.net</email></address>
</author>
<author initials='H.' surname='Holbrook' fullname='Hugh Holbrook'>
<organization>Arastra, Inc.</organization>
<address><postal>
<street>P.O. Box 10905</street>
<city>Palo Alto</city> <region>CA</region>
<code>94303</code>
<country>USA</country>
</postal>
<email>holbrook@arastra.com</email></address>
</author>
<author initials='I.' surname='Kouvelas' fullname='Isidor Kouvelas'>
<organization>cisco Systems</organization>
<address><postal>
<street>Tasman Drive</street>
<city>San Jose</city> <region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>kouvelas@cisco.com</email></address>
</author>
<author initials='S.' surname='Venaas' fullname='Stig Venaas'>
<organization>cisco Systems</organization>
<address><postal>
<street>Tasman Drive</street>
<city>San Jose</city> <region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>stig@cisco.com</email></address>
</author>
<date/>
<abstract>
<t>This document discusses the Multicast Source Interest
Notification Protocol (MSNIP). MSNIP is an extension to
IGMPv3 and MLDv2 that provides membership notification
services for sources of multicast traffic operating within the
SSM destination address range.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The Multicast Source Notification of Interest Protocol (MSNIP) is
an extension to version 3 of the Internet Group Membership Protocol
(IGMPv3 <xref target="RFC3376"/>) and version 2 of the Multicast Listener
Discovery Protocol (MLDv2 <xref target="RFC3810"/>). 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.</t>
<t>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 and first-hop router. 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.</t>
<t>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.</t>
</section>
<section title="Routing Protocol Support" anchor="routingsupport">
<t>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).
See <xref target="asm"/> for information on how MSNIP potentially
can be extended to also work with Any-Source Multicast (ASM).</t>
<t>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 <xref target="RFC4601"/>). 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 flood-and-prune behavior on the first-hop link significantly
diminishes the benefits of managing source transmission.</t>
<t>In contrast, with source-specific sparse-mode protocols such as
PIM-SSM <xref target="RFC4601"/>) 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.</t>
<t>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 behavior.</t>
</section>
<section title="Service Interface for Requesting Membership Notification">
<t>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) a service
interface that can be used to register with the IP layer for such
notifications. Dual stack systems supporting both IPv4 and IPv6 need to
provide separate service interfaces for each protocol.</t>
<t>A system's IPv4 or IPv6 service interface must support the
following operation or any logical equivalent:
<list style="empty">
<t>
IPMulticastSourceRegister (socket, source-address, multicast-address)
</t><t>
IPMulticastSourceDeregister (socket, source-address, multicast-address)
</t>
</list>
In addition the application must provide the following
interface for receiving notifications from the IP system:
<list style="empty">
<t>
IPMulticastSourceStart (socket, source-address, multicast-address)
</t><t>
IPMulticastSourceStop (socket, source-address, multicast-address)
</t>
</list>
where:
<list style="hanging">
<t hangText="socket: ">
is an implementation-specific parameter used to distinguish amongst
different requesting entities (e.g., programs or processes) within
the system; the socket parameter of BSD UNIX system calls is a
specific example.</t>
<t hangText="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 address. An
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 must be invoked separately for each
desired source address.</t>
<t hangText="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 addresses for a given source address,
IPMulticastSourceRegister must be invoked separately for each
desired multicast address.</t>
</list></t>
<section title="Application Operation">
<t>Applications wishing to use MSNIP to control their multicast data
transmission to destination G from source address S operate as follows.
</t>
<t>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.</t>
<t>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.
</t>
<t>When the application no longer wishes to transmit data it should
invoke the IPMulticastSourceDeregister call to let the IP system know
that it is no longer interested in notifications for this source and
destination. The IPMulticastSourceDeregister call should be implicit in
the teardown of the associated socket state.</t>
</section>
</section>
<section title="MSNIP Managed Address Range Negotiation">
<t>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
subset of the address space that is used by source-specific multicast
(SSM) <xref target="RFC5771"/>. As described in section 2, MSNIP only
tries to control application transmission within the SSM address range.
</t><t>
It is desirable for applications within an IP system that supports
MSNIP to have a consistent service interface for multicast transmission
that does not require the application to be aware of the SSM address
range. MSNIP supports this by allowing applications to use the service
interface 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 is equivalent to the
default behavior of IP multicast without MSNIP support which forces
multicast applications to assume that there are multicast receivers
present in the network.
</t>
<section title="Router Coordination">
<t>In order for MSNIP to operate on a shared link where two or more
multicast routers may be present, all the multicast routers must be
MSNIP-capable and have an identical configuration for the SSM address
range. MSNIP enforces these requirements by using two new options for
IPv4 in the Multicast Router Discovery protocol <xref target="RFC4286"/>
and one new option for IPv6 in the Neighbor Discovery / ICMPv6 protocol
<xref target="RFC4861"/>.
</t>
<section title="MSNIP Operation Option" anchor="msnipoo">
<t>A multicast router advertises that it is participating in MSNIP
using the MSNIP Operation option in either the Multicast Router
Discovery protocol for IPv4 or the Neighbor Discovery / ICMPv6
protocol for IPv6. This option MUST be included in all router
advertisement messages of a router that is configured for MSNIP.
The format of the option is as follows:
<figure>
<artwork><![CDATA[
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 | Length | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<list style="hanging">
<t hangText="Type: ">
The type field is set to WW (TBD by IANA) for IPv4 and ZZ (TBD by
IANA) for IPv6.</t>
<t hangText="Length: ">
The length field is set to 0 for IPv4 and 1 for IPv6.</t>
<t hangText="Padding: ">
The six extra bytes of padding are only present in IPv6 and are
required to bring the size of the option up to the eight octet
boundary. The value of the padding bytes must be set to zero on
transmission and ignored on receipt.</t>
</list>
</t>
<t>A multicast router uses received Multicast Router Advertisement and
Neighbor Discovery / ICMPv6 messages to determine if all live neighbor
multicast routers on each interface are participating in MSNIP. When a
router advertisement message not containing an MSNIP option is received
by a router participating in MSNIP, the mis-configuration SHOULD be
logged to the operator in a rate-limited manner.</t>
<t>If even one multicast router on a link does not have MSNIP
capability then ALL routers on that link MUST be configured to not
provide MSNIP services and to not advertise the MSNIP Operation option.
</t>
</section>
<section title="SSM Range Option" anchor="ssmro">
<t>The SSM Range Multicast Router Discovery option advertises the IPv4
SSM Range with which the router is configured. The option is defined in
<xref target="I-D.ietf-magma-mrdssm"/>. This option is only valid in
IPv4. The SSM range for IPv6 is well defined for all valid scopes
<xref target="RFC3306"/> and a mechanism to allow additional ranges to
operate in SSM mode on a per-link bases is not required.</t>
</section>
</section>
<section title="Managed Range Discovery by Source Systems" anchor="manrg">
<t>When an application in an IP system uses the MSNIP service
interface 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 (and is being
managed by MSNIP). 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. In addition, an MSNIP-capable IP system
must be able to detect if there are multicast routers on its connected
links and if they support MSNIP operation. If no multicast routers are
present or if the multicast routers are not MSNIP-capable then the IP
system MUST default to flooding and immediately instruct applications to
transmit.</t>
<t>An IP system controls transmission behavior under the different
possible conditions by adapting its definition of the MSNIP-managed
multicast destination address range:
<list style="symbols">
<t>On a link with multicast routers operating the MSNIP protocol the
IP system MUST use the SSM multicast destination address range as
the MSNIP-managed range. IPv4 systems MUST use the contents of
the SSM Range option in received Multicast Router Advertisement
messages <xref target="I-D.ietf-magma-mrdssm"/> to discover the
configured SSM range. SSM range discovery is not needed in IPv6
where the SSM destination address range is fixed.</t>
<t>On a link not connected to a multicast routed infrastructure or
on a link with multicast routers that do not support MSNIP
operation, the IP system MUST use an empty range as its
MSNIP-managed range. This forces applications transmitting to any
multicast destination address to default to flooding thus
providing backward compatibility.</t>
</list>
</t>
<t>As described in <xref target="msnipoo"/>, an IP system can determine
the status of a link and distinguish between the above two cases through
the reception of IPv4 Multicast Router Advertisement and Neighbor
Discovery / ICMPv6 messages.</t>
</section>
</section>
<section title="Requesting and Receiving Notifications">
<t>Like IGMP, MSNIP is an asymmetric protocol specifying different
behavior 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 systems to notify them
of the arrival of the first or departure of the last receiver 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.</t>
<section title="Host Interest Solicitation">
<t>Source systems that wish to be managed by MSNIP periodically
transmit a Host Interest Solicitation message. This message is multicast
with a multicast destination address of ALL_IGMPv3_ROUTERS (224.0.0.22)
or ALL_MLDv2_ROUTERS (FF02::16) and is transmitted every [Interest
Solicitation Interval] seconds. The Host 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. Systems with multiple
interfaces or multiple IP addresses per interface must originate
separate Host Interest Solicitation messages from each of their IP
addresses that they wish to have managed by MSNIP. In practice a system
with more than one IP address is treated by MSNIP as multiple IP
systems.</t>
<t>When an IP system first comes up it transmits [Robustness Variable]
Host Interest Solicitation messages spaced by [Initial Interest
Solicitation Interval] seconds.</t>
<t>All MSNIP capable routers that receive a Host Interest Solicitation
message from an IP system, maintain a system interest record of the form:
<list style="empty">
<t>(IP system address, holdtime timer)</t>
</list>
</t>
<t>Each time a Host 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 may respond to the solicitation message
with a Receiver Membership Report message described in
<xref target="rrmr"/>. 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.</t>
<t>The holdtime timer of a record counts down to zero. When the
holdtime timer of a specific system interest record expires, the record
is deleted.</t>
</section>
<section title="Router Receiver Membership Reports" anchor="rrmr">
<t>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.</t>
<t>In addition to reports sent in response to Host Interest
Solicitation messages, 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 multicast
destination address is managed by MSNIP and the router has a system
interest record created by a previously received Host Interest
Solicitation message with an 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 spaced by
[Unsolicited Membership Report Interval] seconds. If the membership
status changes again for the same destination address and source system
while transmission of Receiver Membership Reports is still pending then
the pending report messages are canceled and a new set of [Robustness
Variable] messages indicating the new state are scheduled.</t>
<t>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:
<list style="empty">
<t>(router address, source address, multicast address, holdtime timer)
</t>
</list>
The router address is obtained from the source address of the IP header
of the received message. The source address is obtained from the
destination address of the IP header of the received message. The
multicast address is obtained from the information in the TRANSMIT
record. The holdtime timer is set to the value of the holdtime field in
the received Receiver Membership Report message.</t>
<t>For each HOLD record present in the message, the system deletes the
matching previously created transmission record from its state.</t>
<t>The holdtime timer of a record counts down to zero. When the
holdtime timer of a specific transmission record expires, the record is
deleted.</t>
<t>Note that creation and deletion of transmission records in an IP
system's state may cause local applications to be notified to start and
stop transmitting data (see <xref target="appnot"/>).</t>
</section>
</section>
<section title="Application Notification" anchor="appnot">
<t>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.</t>
<t>In tabular form, the state-machine is:
<figure>
<artwork><![CDATA[
+------------------+---------------------------------------------+
| | Previous State |
| Event +--------------+---------------+--------------+
| | No Info | Hold | Transmit |
+------------------+--------------+---------------+--------------+
| New Register | - | - | - |
| | Start new | | Start new |
+------------------+--------------+---------------+--------------+
| | -> Hold | - | - |
| Start Manage | Stop ALL | | |
| | registered | | |
+------------------+--------------+---------------+--------------+
| | - | -> No Info | -> No Info |
| Stop Manage | | Stop ALL | |
| | | registered | |
+------------------+--------------+---------------+--------------+
| | - | -> Transmit | - |
| Recv TRANSMIT | | Start ALL | |
| | | registered | |
+------------------+--------------+---------------+--------------+
| Recv last HOLD | - | - | -> Hold |
| or timeout | | | Stop ALL |
| | | | registered |
+------------------+--------------+---------------+--------------+
]]></artwork>
</figure>
</t>
<t>The events in the state machine above have the following meaning:
<list style="hanging">
<t hangText="New register: ">
A new application has registered through a call to
IPMulticastSourceRegister for this S and G.</t>
<t hangText="Start manage: ">
We received an SSM Range option in an MRD packet on the interface
that S belongs to that changed the status of G from a non-managed
to a MSNIP-managed destination address. The SSM Range option is
only valid in IPv4.</t>
<t hangText="Stop manage: ">
We received an SSM Range option in an MRD 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. The SSM
Range option is only valid in IPv4.</t>
<t hangText="Receive TRANSMIT: ">
We received a Receiver Membership Report with S as the IP
destination address that contains a TRANSMIT record for G.</t>
<t hangText="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 the
holdtime timer in a transmission record for S and G expired and
there are no other transmission 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.</t>
</list></t>
<t>The state machine actions have the following meaning:
<list style="hanging">
<t hangText="Start new: ">
Send an IPMulticastSourceStart notification to the application that
just registered for this S and G.</t>
<t hangText="Start ALL registered: ">
Send an IPMulticastSourceStart notification to all applications
that are registered for this S and G.</t>
<t hangText="Stop ALL registered: ">
Send an IPMulticastSourceStop notification to all applications that
are registered for this S and G.</t>
</list></t>
</section>
<section title="Router Processing">
<t>This section describes the per-source system tracking state machine
operated by each first-hop router. The initial state is No Info.</t>
<t>In tabular form, the state-machine is:
<figure>
<artwork><![CDATA[
+---------------------+----------------------------------------------+
| | Previous State |
| Event +----------------------+-----------------------+
| | Not tracking | Tracking |
+---------------------+----------------------+-----------------------+
| | -> Tracking | - |
| Receive HIS | Set HT to message | Set HT to message |
| | holdtime; Send ALL | holdtime; Send ALL |
| | existing TRANSMITs | existing TRANSMITs |
+---------------------+----------------------+-----------------------+
| HIS timeout | - | -> Not tracking |
| | | |
+---------------------+----------------------+-----------------------+
| Receivers for new | - | - |
| destination G | | Send TRANSMIT for G |
+---------------------+----------------------+-----------------------+
| Receivers of G | - | - |
| leave | | Send HOLD for G |
+---------------------+----------------------+-----------------------+
]]></artwork>
</figure>
</t>
<t>The events in the state machine above have the following meaning:
<list style="hanging">
<t hangText="Receive HIS: ">
The router has received a Host Interest Solicitation from S.</t>
<t hangText="HIS timeout: ">
The holdtime timer (HT) in the host interest record associated with
S has expired.</t>
<t hangText="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.</t>
<t hangText="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.</t>
</list></t>
<t>The state machine actions have the following meaning:
<list style="hanging">
<t hangText="Set HT to message holdtime: ">
The holdtime timer in the host interest record associated with S is
restarted to the value of the holdtime field in the received Host
Interest Solicitation message.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
</list></t>
</section>
<section title="Message Formats" anchor="formats">
<t>The following packet formats are valid for both IPv4 and IPv6. IP
version-specific values will be explicitly defined.</t>
<t>There are two message types of concern to the MSNIP protocol
described in this document:
<figure>
<artwork><![CDATA[
+---------------------+------------------------------+
| Type Number (hex) | Message Name |
+---------------------+------------------------------+
| 0xXX | Host Interest Solicitation |
+---------------------+------------------------------+
| 0xYY | Receiver Membership Report |
+---------------------+------------------------------+
]]></artwork>
</figure>
</t>
<t>Both the Host Interest Solicitation message and the Receiver
Membership Report message MUST not be forwarded by routers (see
<xref target="seccons"/>). The Router Alert option <xref target="RFC2113"/>
<xref target="RFC2711"/> MUST be included in the packet by
the router or host IP system transmitting the message. Routers receiving
Host Interest Solicitation messages and IP systems receiving Receiver
Membership Reports MUST not process a received MSNIP message if the
Router Alert option is not present.
</t>
<section title="Host Interest Solicitation Message" anchor="hism">
<t>A Host Interest Solicitation message is periodically multicast by
MSNIP capable systems to declare interest in Receiver Membership
Reports from multicast routers on the link. The Host Interest
Solicitation message is multicast with a destination address of
ALL_IGMPv3_ROUTERS (224.0.0.22) or ALL_MLDv2_ROUTERS (FF02::16).
<figure>
<artwork><![CDATA[
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 | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<list style="hanging">
<t hangText="Type: ">
The type field is set to XX (to be assigned by IANA as an IGMP type
for IPv4 and an ICMPv6 type for IPv6).</t>
<t hangText="Reserved: ">
Transmitted as zero. Ignored upon receipt.</t>
<t hangText="Checksum: ">
In IPv4, the Checksum is the 16-bit one's complement of the one's
complement sum of the whole IGMP message (the entire IP payload).
In IPv6, the Checksum is the standard ICMPv6 checksum, covering the
entire MLDv2 message plus a "pseudo-header" of IPv6 header fields
<xref target="RFC4443"/>. For computing the checksum, the Checksum
field is set to zero. When receiving packets, the checksum MUST be
verified before processing a packet.</t>
<t hangText="Holdtime: ">
The amount of time a receiving router must keep the system interest
state alive, in seconds. The default value for this field is
[Interest Solicitation Holdtime].</t>
</list>
</t>
</section>
<section title="Receiver Membership Report Message">
<t>A Receiver Membership Report message 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.
<figure>
<artwork><![CDATA[
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 | Dest Count | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Holdtime | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record-Type-1 | Record-Reserved-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination-Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<list style="hanging">
<t hangText="Type: ">
The type field is set to YY (to be assigned by IANA as an IGMP type
for IPv4 and an ICMPv6 type for IPv6).</t>
<t hangText="Dest Count: ">
The number of multicast destination address records present in this
message.</t>
<t hangText="Checksum: ">
In IPv4, the Checksum is the 16-bit one's complement of the one's
complement sum of the whole IGMP message (the entire IP payload).
In IPv6, the Checksum is the standard ICMPv6 checksum, covering the
entire MLDv2 message plus a "pseudo-header" of IPv6 header fields
<xref target="RFC4443"/>. For computing the checksum, the Checksum
field is set to zero. When receiving packets, the checksum MUST be
verified before processing a packet.</t>
<t hangText="Holdtime: ">
The amount of time in seconds that the target host must keep alive
the transmission record state created or updated by the TRANSMIT
records in this report. The router originating the Receiver
Membership Report sets this field to the current value of the
holdtime timer in the system interest record corresponding to the
target host. As a result Receiver Membership Reports sent in
response to the reception of a Host Interest Solicitation message
have their holdtime set to the value of the holdtime field in the
received HIS message.</t>
<t hangText="Reserved: ">
Transmitted as zero. Ignored upon receipt.</t>
<t hangText="Record-Type-1: ">
The type of the first transmission control record in this message.
Valid values are:
<figure>
<artwork><![CDATA[
+-------------+----------------------------------------------+-------+
| Record Type | Description | Value |
+-------------+----------------------------------------------+-------+
| TRANSMIT | Request to start transmitting to destination | 1 |
+-------------+----------------------------------------------+-------+
| HOLD | Request to stop transmitting to destination | 2 |
+-------------+----------------------------------------------+-------+
]]></artwork>
</figure></t>
<t hangText="Record-Reserved-1: ">
Transmitted as zero. Ignored upon receipt.</t>
<t hangText="Destination-Address-1: ">
The multicast destination address of the first record in the message.
</t>
</list>
</t>
</section>
<section title="IPv4 Header Fields">
<t>Like all IGMP messages, MSNIP messages are encapsulated in IPv4
datagrams, with an IP protocol number of 2. MSNIP messages can be
identified from other IGMP messages by the message types listed in
<xref target="formats"/>. Every MSNIP message described in this
document is sent with an IP Time-to-Live of 1, and carries an IP
Router Alert option <xref target="RFC2113"/> in its IP header.</t>
</section>
<section title="IPv6 Header Fields">
<t>MLD messages are a sub-protocol of the Internet Control Message
Protocol (ICMPv6 <xref target="RFC4443"/>). MSNIP messages are
identified in IPv6 packets by the combination of a preceding Next
Header value of 58 and by the MLD message types listed in
<xref target="formats"/>. All MSNIP messages described in this
document are sent with a link-local IPv6 Source Address (or the
unspecified address, if a valid link-local address is not available), an
IPv6 Hop Limit of 1, and an IPv6 Router Alert option
<xref target="RFC2711"/> in a Hop-by-hop Options header.</t>
</section>
</section>
<section title="Constants Timers and Default Values">
<t>
<list style="hanging">
<t hangText="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</t>
<t hangText="Interest Solicitation Interval: ">
The interval used by MSNIP capable systems between transmissions of
Host Interest Solicitation messages. Default: 60 secs</t>
<t hangText="Interest Solicitation Holdtime: ">
The interval inserted in Host 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)).</t>
<t hangText="Initial Interest Solicitation Interval: ">
The interval used by systems to send out the initial Host Interest
Solicitation messages when they first come up. Default: 1 second.</t>
<t hangText="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.</t>
</list>
</t>
</section>
<section title="Possible Optimisations">
<section title="Suppressing HIS Messages" anchor="suppresshis">
<t>A possible optimisation for MSNIP is to suppress the transmission
of Host Interest Solicitation messages from the source address of an IP
system for which no local application has registered interest. In
addition to conserving bandwidth, not transmitting HIS messages prevents
remote receivers for groups with no matching source application from
creating transmission record state in the host system.</t>
</section>
<section title="Host Stack Filtering">
<t>Legacy applications that have not been coded with MSNIP support can
still be prevented from wasting first-hop link bandwidth by filtering
transmitted packets at the operating system level. Even though such
applications will not register for MSNIP notifications with the host
operating system, if the OS is MSNIP-capable and the application is
transmitting data to an MSNIP-managed group for which there are no
transmit records, the OS can safely filter the packets and not transmit
them on the wire.</t>
<t>A problem with the filtering approach is that it cannot be combined
with the HIS message suppression optimisation (see
<xref target="suppresshis"/>). If there are no registered applications
in the system and HIS messages are
being suppressed then the first-hop routers will not send any Receiver
Membership Reports to the system. As a result, knowledge of receiver
membership from the presence of transmit records for groups operated by
legacy applications will not exist. It therefore becomes unsafe to
filter packets from legacy applications.</t>
</section>
<section title="Responding to Unexpected IGMP Queries">
<t>Under steady state the router side of the IGMP protocol elects a
single router on each link that is responsible for issuing IGMP Queries.
Routers other than the acting IGMP querier will send an IGMP Query only
if they restart and have no IGMP querier election state or if the active
Querier crashes and a new election takes place.</t>
<t>MSNIP can take advantage of this mechanism to quickly populate the
host interest records of a new router starting up. When the router comes
up it will issue an IGMP Query in an attempt to be elected as a Querier.
MSNIP-capable hosts will notice that the sender of the Query is not the
acting Querier. They can use this trigger to respond with Host Interest
Solicitation Messages (with transmission randomised over a small
interval) to quickly bring the new router up-to-date.</t>
</section>
<section title="Host and Router Startup">
<t>When a host operating system is restarted there may be applications
that are started as part of the initialisation process and want to
source IPv4 multicast traffic. It is possible for the applications to
register through MSNIP with the IP subsystem and to start transmitting
multicast data before the host receives the MSNIP-managed range
definition through the SSM Range option of the Multicast Router
Discovery protocol.</t>
<t>This temporary flooding can be avoided if the host OS holds off
notifying MSNIP-capable applications that they can transmit until it
receives an MRD advertisement and learns the SSM configuration for the
network. This behaviour has the drawback that it is not compatible with
legacy networks with no MRD deployment. In such a network the host OS
has to be able to determine after a configurable period that MRD is not
enabled and hence all multicast applications wishing to source traffic
should be notified to transmit. A good default value for this period is
the MAX_RESPONSE_DELAY of the Multicast Router Discovery protocol
<xref target="RFC4286"/>.</t>
<t>Late router startup is harder to deal with. Hosts that start up
before the multicast router may time out waiting for an MRD
advertisement and instruct all MSNIP-capable multicast source
applications to transmit data. One way to work around this problem is to
configure the host OS to wait forever for an MRD advertisement before
instructing MSNIP applications to transmit.</t>
</section>
</section>
<section title="Inter-operation with IGMP / MLD Proxying">
<t>MSNIP is intended for use on networks with multicast servers
offering a large number of potential sessions. Although unlikely, it is
possible to deploy such a server behind an IGMP / MLD Proxy
<xref target="RFC4605"/>. If the proxy is not MSNIP-aware and does not
implement the extensions described below then sources behind the proxy
will default to flooding.</t>
<t>If a device performing IGMP / MLD Proxying wishes to proxy MSNIP,
it MUST forward MSNIP Host Interest Solicitation messages that are
received on downstream interfaces to its upstream interface. No special
treatment is required for MSNIP Receiver Membership Reports as they are
unicast to the target host.</t>
<t>In addition to the forwarding of MSNIP messages, an IGMP proxy MUST
operate the Multicast Router Discovery protocol <xref target="RFC4286"/>
on all its downstream interfaces and advertise the MSNIP capability option
(<xref target="msnipoo"/>) and SSM address range option
(<xref target="ssmro"/>). The MSNIP capability option should be advertised
on downstream interfaces only if it is included in MRD messages received
on the upstream interface. The address range to be included in the SSM
Range option MUST be determined by MRD and IGMP messages received on the
upstream interface of the proxy according to the rules in
<xref target="manrg"/>.</t>
<t>In addition to the forwarding of MSNIP messages, an MLD proxy MUST
operate the IPv6 Neighbour Discovery protocol. The MSNIP capability
option should be advertised on downstream interfaces when it is included
in IPv6 Neighbour Discovery messages received on the upstream interface.
</t>
</section>
<section title="Security Considerations" anchor="seccons">
<t>We consider the ramifications of a forged message of each type. As
described in <xref target="RFC3376"/> and <xref target="RFC3810"/>,
IPSEC AH can be used to authenticate IGMP and MLD messages if desired.</t>
<section title="Receiver Membership Report Attacks">
<t>A DoS attack on a host could be staged through forged Receiver
Membership Report messages. The attacker can send a large number of
reports, each with a large number of TRANSMIT records and a holdtime
field set to a large value. The host will have to store and maintain the
transmission records specified in all of those reports for the duration
of the holdtime. This would consume both memory and CPU cycles in the
host.</t>
<t>Forged Receiver Membership Report messages from the local network
can be easily traced. There are three measures necessary to defend
against externally forged reports:
<list style="symbols">
<t>Routers SHOULD NOT forward Receiver Membership Reports. This is
easier for a router to accomplish if the report carries the
Router-Alert option.</t>
<t>Hosts SHOULD ignore Receiver Membership Reports without the
Router-Alert option.</t>
</list></t>
<t>Note that a remote attack through the multicast routing protocol is
possible. A remote site can originate join state for a large number of
groups that will propagate through MSNIP to the target source host.
Such attacks are considered a more significant problem for the routers
involved and are left up to the routing protocol security.</t>
<t>HOLD records in forged Receiver Membership Report messages are not
a significant threat as hosts track the individual interests of each
first-hop router separately. Only by forging the source address of the
report message so that is appears to have originated from a real
first-hop router can the attacker cause the source to stop transmitting
to a group that has valid receivers. Such forged messages can be
detected by the router itself.</t>
</section>
<section title="Host Interest Solicitation Attacks">
<t>Forged Host Interest Solicitation messages can have two effects:
<list style="symbols">
<t>When non-existent source addresses are used the solicitation
messages can create unwanted host record state on attached
routers for the duration of the holdtime specified in the
message.</t>
<t>When a source address corresponding to an existing host is used
in the forged HIS message, receipt of the message by attached
routers will cause them to transmit Receiver Membership Reports
messages for all MSNIP-managed multicast destination addresses
with receivers for the target host. Although no additional state
will be created in routers or hosts from this attack, bandwidth
and CPU is wasted in both the first-hop routers and the target
host.</t>
</list></t>
<t>Just like for the Receiver Membership Report message, attacks using
the Host Interest Solicitation message can be reduced by requiring the
use of the Router-Alert option on the message.</t>
</section>
<section title="MSNIP Managed Range Discovery">
<t>As discussed in <xref target="I-D.ietf-magma-mrdssm"/> it is possible
for directly connected systems to send forged Multicast Router
Advertisement messages containing the SSM Range Discovery option. As the
SSM Range Discovery option determines the MSNIP-managed range under
IPv4, such forged messages can temporarily replace the managed range
map with incorrect information in receiving hosts. An incorrect mapping
can have two effects:
<list style="symbols">
<t>Applications using a multicast destination address within the
real SSM range that have no valid receivers can be tricked into
thinking that their chosen destination address is no longer an
SSM address and will therefore start transmitting data.</t>
<t>Applications using group addresses outside the valid SSM range
can be tricked into thinking that they are using an SSM
destination address and therefore prevented from transmitting
data.</t>
</list></t>
<t>The Multicast Router Discovery SSM Range Option specification
suggests that a router receiving a Multicast Router Advertisement with
an inconsistent SSM Range Option log the event to the operator. Such
logging will enable tracking of this type of attack.</t>
</section>
</section>
<section title="IANA Considerations">
<t>This document introduces the following new types and options that
require allocation by IANA:
<list style="symbols">
<t>Two new IGMP messages for Host Interest Solicitation and Receiver
Membership Report. Each of these messages requires a new IGMP
type value to be assigned by IANA <xref target="IGMPREG"/>.</t>
<t>The new MSNIP Operation option for the Multicast Router Discovery
protocol. This option requires a new MRD type value to be
assigned by IANA.</t>
<t>The new MSNIP Operation option for the Neighbour Discovery /
ICMPv6 protocol. This option requires a new NDP / ICMPv6 type
value to be assigned by IANA.</t>
</list></t>
</section>
<section title="Acknowledgements">
<t>The authors would like to thank Dave Thaler, Jon Crowcroft, Toerless
Eckert, Haixiang He, Pekka Savola and Karen Kimball for their
contribution to this specification.</t>
</section>
</middle>
<back>
<references title='Normative References'>
<?rfc include='reference.RFC.2113' ?>
<?rfc include='reference.RFC.2711' ?>
<?rfc include='reference.RFC.3376' ?>
<?rfc include='reference.RFC.3810' ?>
<?rfc include='reference.RFC.4286' ?>
<?rfc include='reference.RFC.4443' ?>
<?rfc include='reference.RFC.4861' ?>
<?rfc include='reference.I-D.ietf-magma-mrdssm' ?>
</references>
<references title='Informative References'>
<?rfc include='reference.RFC.3306' ?>
<?rfc include='reference.RFC.4601' ?>
<?rfc include='reference.RFC.4605' ?>
<?rfc include='reference.RFC.5771' ?>
<reference anchor="IGMPREG">
<front>
<title>IGMP Type Numbers</title>
<author surname="IANA">
<organization />
</author>
<date month="June" year="2005" />
</front>
<seriesInfo name="IGMP TYPE NUMBERS - per RFC3228, BCP57"
value="http://www.iana.org/assignments/igmp-type-numbers" />
</reference>
</references>
<section title="Extending MSNIP to Any-Source Multicast" anchor="asm">
<t>This document defines MSNIP only for use with SSM. As noted in
<xref target="routingsupport"/> 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. We will specify in
<xref target="asmpimsm"/> how MSNIP can be extended to work for
ASM when PIM-SM <xref target="RFC4601"/>) is used.</t>
<t>Whether MSNIP can be used for ASM depends on the multicast
routing protocols used. There may be different protocols used for
different group addresses. Rather than requiring a host to know for
which ASM groups MSNIP can be used, we suggest that the host can
use it for all ASM groups. If the first-hop router is unable to
determine whether there are receivers or not, it can tell the source
that there are receivers present anyway. The host will then start sending
and the behavior will be as if MSNIP is not used. If MSNIP is extended
to ASM, one should consider adding a flag to the MSNIP Operation
Option <xref target="msnipoo"/>, or creating a new option for use
with IPv4 in the Multicast Router Discovery protocol
<xref target="RFC4286"/> and Neighbor Discovery / ICMPv6 protocol
<xref target="RFC4861"/>, in order to announced the router capability
to the hosts.</t>
<section title="Extending MSNIP to ASM with PIM-SM" anchor="asmpimsm">
<t>When PIM-SM <xref target="RFC4601"/> is used to provide ASM
service, a first-hop router will generally not know if there are
receivers for a group until it starts receiving data from an active
source. Until the source becomes active, receivers simply join the
shared tree for the group. This allows the Rendezvous-Point (RP) for the
group to learn that receivers are present. Next when a source becomes
active, a first-hop router (the Designated Router (DR)) will be
responsible for sending PIM register messages to the the RP. If there
are receivers present, the RP and/or last-hop routers will join the
Shortest Path Tree (SPT) towards the source. This will result in at
least one first-hop router learning that a source exists. The last
part is similar to when using PIM-SM for SSM. With SSM a last-hop
router immediately joins the Shortest Path Tree (SPT).</t>
<t>MSNIP can be extended to ASM with PIM-SM as follows:
<list style="symbols">
<t>Host Interest Solicitation Message (<xref target="hism"/>) need to
be extended to include a list of groups that the host is interested
in receiving membership reports for.</t>
<t>When a Designated Router (DR) receives a Host Interest
Solicitiation Message with source address S containing a group G, it
will periodically send PIM Null-Register messages to the RP for (S,G).
This is done instead of the data PIM Register messages the DR would
use if the source did not use MSNIP. Per the DR register state
machine in section 4.4.1 of <xref target="RFC4601"/>, one can
immediately send a Null-Register and then move to Prune state as if
a Register-Stop was received. When the Register-Stop timer expires,
send a Null-Register as usual. But then, rather than setting the
Register-Stop timer to Register_Probe_Time, transition directly to
Prune state as if a Register-Stop was received again. By periodically
receiving the (S,G) registers, the RP will know that a source exists,
and will join the SPT towards the source if it has receivers. Just
like SSM, a first-hop routers will then receive an SPT join for (S,G)
and learn that there are receivers. It can then inform the source.
If the first-hop router has (*,G)-state, e.g., local interest or it
is part of the shared tree, but has not yet got an (S,G) olist, it
must immediately inform the source.</t>
</list></t>
<t>
One benefit with this approach, is that PIM data registers can be
avoided.
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 22:25:05 |