INTERNET-DRAFT Source-Specific Multicast H. Holbrook
Expires September 9, 2000 Cisco Systems
B. Cain
Nortel Networks
9 March 2000
Source-Specific Multicast for IP
<draft-holbrook-ssm-00.txt>
Status of this Memo
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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC 2119].
Holbrook/Cain [Page 1]
INTERNET-DRAFT Source-Specific Multicast 9 March 2000
Abstract
IP addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are
designated as source-specific multicast (SSM) destination addresses and
are reserved for use by source-specific applications and protocols
[IANA-ALLOCATION]. This document defines the semantics of source-
specific multicast addresses and specifies the policies governing their
use. It defines an extension to the Internet network service that
applies to datagrams sent to SSM addresses and defines the host
extensions to support this service.
Appendix I of this document describes changes to the Internet Group
Management Protocol Version 3 (IGMPv3) [IGMPv3] to support source-
specific multicast.
1. Overview and Rationale
The Internet Protocol (IP) multicast service model is defined in RFC
1112 [RFC1112]; that document specifies that a datagram sent to an IP
class D address (224.0.0.0 through 239.255.255.255) G is delivered to
each "upper-layer protocol module" that has requested reception of
datagrams sent to address G. The network service identified by a
multicast destination address G is referred to as a "host group" (as per
RFC 1112). This model supports both one-to-many and many-to-many group
communication. This document uses the term "Internet Standard
Multicast" (ISM) to refer to the RFC 1112 multicast model.
IP addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are
designated as source-specific multicast (SSM) destination addresses and
are reserved for use by source-specific applications and protocols.
Source-Specific Multicast delivery semantics are provided for a datagram
sent to an SSM address. That is, a datagram with source IP address S
and SSM destination address G is delivered (only) to each upper-layer
"socket" that has specifically requested the reception of datagrams sent
to address G by source S. The network service identified by (S,G), for
SSM address G and source host address S, is referred to as a "channel."
In contrast to the ISM model of RFC 1112, SSM provides network-layer
support for one-to-many delivery only.
The benefits of source-specific multicast include:
Elimination of cross-delivery of traffic when two sources
simultaneously use the same source-specific destination address.
The simultaneous use of an SSM destination address by multiple
sources is explicitly supported.
Avoidance of the need for inter-host coordination when choosing
Holbrook/Cain [Page 2]
INTERNET-DRAFT Source-Specific Multicast 9 March 2000
source-specific addresses, as a consequence of the above.
Avoidance of many of the router protocols and algorithms that are
needed to deliver ISM multicast datagrams from potentially any host
to all hosts that have requested delivery of that address. For
instance, the "shared trees" and Rendezvous Points of the PIM-SM
protocol are not necessary to support the source-specific address
range. The router mechanisms required to support SSM are not new,
and are in fact largely a subset of those required to support ISM.
For example, a network that uses the PIM-SM protocol can readily
provide for source-specific multicast by using PIM's shortest-path
trees.
Like ISM, SSM is receiver-driven, and the receivers are unknown to the
sender. An SSM source is provided with neither the identity of receivers
nor their number.
This document defines the semantics of source-specific multicast
addresses and specifies the policies governing their use. In
particular, it defines an extension to the Internet network service that
applies to datagrams sent to SSM addresses and defines host extensions
to support the network service. Hosts, routers, applications, and
protocols that use these addresses MUST comply with the policies
outlined in this document. Failure of hosts to comply may prevent a
host from receiving traffic sent to an SSM channel, and failure of a
router to comply may result in SSM traffic being delivered to parts of
the network where it is unwanted, placing an undue burden on the network
infrastructure.
Appendix I of this document describes changes to the Internet Group
Management Protocol Version 3 (IGMPv3) [IGMPv3] to support source-
specific multicast.
2. Semantics of Source-Specific Multicast Addresses
The source-specific multicast service is defined as follows:
A datagram sent with source IP address S and destination IP address
G in the SSM range is delivered to each host socket that has
specifically requested delivery of datagrams sent by S to G, and
only to those sockets.
Where, borrowing text from [IGMPv3]:
"socket" is an implementation-specific parameter used to distinguish
among different requesting entities (e.g., programs or processes or
communication end-points within a program or process) within the
requesting host; the socket parameter of BSD Unix system calls is a
Holbrook/Cain [Page 3]
INTERNET-DRAFT Source-Specific Multicast 9 March 2000
specific example.
The IP module interface to upper-layer protocols is extended to allow a
socket to "Subscribe" to or "Unsubscribe" from a particular channel
identified by an SSM destination address and a source IP address. The
extended interface is defined in section 4.1.
Any host may send a datagram to any SSM address, and delivery is
provided according to the above semantics. It is meaningless for an
application or host to request reception of datagrams sent to an SSM
destination address G, as is supported in Internet Standard Multicast,
without also specifying a corresponding source address, and routers MUST
ignore any such request from a host, pursuant to Appendix I.
Multiple source applications on different hosts Si can use the same SSM
destination address G without conflict because datagrams sent by each
source host Si are delivered only to those sockets that requested
delivery of datagrams sent to G specifically by Si.
The key point is that, in effect, a channel is identified (addressed) by
the combination of a (unicast) source address and a multicast
destination address in the SSM range. So, for example the channel
S,G = (36.18.0.1, 232.7.8.9)
differs from
S,G = (36.18.0.2, 232.7.8.9).
3. Terminology
To avoid confusion between Internet Standard Multicast and Source-
Specific Multicast, we use different terminology when discussing the two
service models that are provided to applications.
We use the term "channel" to refer to the service associated with an SSM
address. A channel is identified by the combination of an SSM
destination address and a specific source, e.g., an (S,G) pair.
We use the term "host group" (used in RFC 1112) to refer to the service
associated with "regular" class D addresses (excluding those in the SSM
range). A host group is identified by a single class D address.
Any host can send to a host group, and similarly, any host can send to
an SSM destination address. A packet sent by a host S to an ISM
destination address G is delivered to the host group identified by G. A
Holbrook/Cain [Page 4]
INTERNET-DRAFT Source-Specific Multicast 9 March 2000
packet sent by host S to an SSM destination address G is delivered to
the channel identified by (S,G). The receiver operations allowed on a
host group are "join(G)" and "leave(G)" (as per RFC 1112); similarly,
the receiver operations supported on a channel are "subscribe(S,G)" and
"unsubscribe(S,G)."
The following table summarizes the terminology:
Service Model: Internet Standard Source-Specific
Network Abstraction: group channel
Identifier: G S,G
Receiver Operations: join, leave subscribe, unsubscribe
We note that, although this document specifies a new service model
available to applications, the protocols and techniques necessary to
support the service model are largely a subset of those used to support
ISM. Appendix I describes how the IGMPv3 protocol can be used to
implement the host-to-router subscription for SSM; companion documents
will describe the router protocol modifications to support SSM.
4. Host Requirements
This section describes the requirements on hosts that support Source-
Specific Multicast, including:
- Extensions to the IP Module Interface
- Extensions to the IP Module
- Allocation of SSM Addresses
4.1. Extensions to the IP Module Interface
The IP module interface to upper-layer protocols is extended to allow
protocols to request reception of all datagrams sent to a particular
channel.
Subscribe ( socket, source-address, group-address, interface )
Unsubscribe ( socket, source-address, group-address, interface )
where
"socket" is as previously defined,
Holbrook/Cain [Page 5]
INTERNET-DRAFT Source-Specific Multicast 9 March 2000
and, paraphrasing [IGMPv3],
"interface" is a local identifier of the network interface on which
reception of the channel identified by the (source-address,group-
address) pair is to be enabled or disabled. A special value may be
used to indicate a "default" interface, as per [IGMPv3]. If
reception of the same channel is desired on multiple interfaces,
Subscribe is invoked once for each.
The above are abstract functional APIs -- the functionality may be
provided in an implementation-specific way. On a host that supports a
full IGMPv3 API, the Subscribe and Unsubscribe MAY be provided via those
APIs.
Widespread implementations of the IP packet reception interface (e.g.,
the recvfrom() system call in BSD unix) do not allow a receiver to
determine the destination address to which a datagram was sent. On a
host with such an IP implemntation the destination address of a datagram
cannot be inferred, if the socket on which the datagram is received is
also Subscribed to multiple channels. Host operating systems SHOULD
provide a way for a host to determine both the source and the
destination address to which a datagram was sent. (As one example, the
Linux version 2.2 operating system provides the ability to determine the
destination of a packet with the recvmsg() system call.) Until this
capability is present, applications are forced to use higher-layer
mechanisms to identify the channel to which a datagram was sent.
4.2. Requirements on the Host IP Module
An incoming datagram destined to an SSM address MUST be delivered by the
IP module to all sockets that have indicated (via Subscribe) a desire to
receive data that matches the datagram's source address, destination
address, and arriving interface. It MUST NOT be delivered to other
sockets.
When the first socket on host H subscribes to a channel (S,G) on
interface I, the host IP module on H sends a request on interface I to
indicate to neighboring routers that the host wishes to receive traffic
sent by source S to source-specific destination G. Similarly, when the
last socket on a host unsubscribes from a channel on interface I, the
host IP module sends an unsubscription request for that channel out
interface I. These requests will typically be IGMPv3 messages, as
specified in Appendix I.
The exact rules for sending source-specific subscription and
unsubscription requests and the algorithms used to maintain
subscriptions are defined in Appendix I of this document.
Holbrook/Cain [Page 6]
INTERNET-DRAFT Source-Specific Multicast 9 March 2000
4.3. Allocation of Source-Specific Multicast Addresses
The SSM destination address 232.0.0.0 is reserved, and hosts MUST NOT
send datagrams with destination address of 232.0.0.0. The address range
232.0.0.1-232.0.0.255 is reserved for allocation by IANA.
The policy for allocating the rest of the SSM addresses to sending
applications is strictly locally determined at the sender's host.
When allocating addresses from the locally allocated range (232.0.1.0 -
232.255.255.255), a host or host operating system MUST NOT start at the
first allowed address, 232.0.1.0, and allocate addresses sequentially.
As described in Section 6, the mapping of an IP packet with SSM
destination address onto a link-layer multicast address does not take
into account the datagram's source IP address (on commonly-used link
layers like Ethernet). If all hosts started at 232.0.1.0, then with
high probability, many source-specific channels on shared-medium local
area networks would collide on the same link-layer multicast address.
As a result, traffic destined for one channel member would burden
another as the link-layer (unaware of the IP Source Address) accepts the
multicast datagram, passes it to the IP layer, which then simply rejects
it.
A RECOMMENDED allocation policy is for a host to allocate SSM addresses
to applications randomly, while ensuring that allocated addresses are
not given simultaneously to multiple applications and while avoiding the
reserved space.
A host operating system SHOULD provide an interface to allow an
application to request a unique allocation of a channel destination
address in advance of a session's commencement, and this allocation
database SHOULD persist across host reboots. By providing persistent
allocations, a host application can advertise the session in advance of
its start time on a web page or in another directory. (We note that
this issue is not specific to SSM applications -- the same problem
arises when ISM is used.)
This document neither defines the interfaces for requesting or returning
addresses nor specifies the host algorithms for storing those
allocations. One plausible abstract API is defined in RFC 2771
[RFC2771], although the interface of RFC 2771 would allow an application
to request an address from a specific sub-range of the SSM allocation,
which is NOT RECOMMENDED for SSM, unless the start address of the
allowed range is selected at random. Randomization is important to
minimize link-layer collisions.
No globally agreed-upon administratively-scoped address range [ADMIN-
SCOPE] is needed for the source-specific multicast range because there
Holbrook/Cain [Page 7]
INTERNET-DRAFT Source-Specific Multicast 9 March 2000
is no possibility of address conflict between hosts in different
administrative domains (or between two hosts of any kind).
Administrative scoping of SSM addresses MAY be implemented within an
administrative domain by filtering at domain boundary routers.
5. Router Requirements
5.1. Packet Forwarding
A router that receives an IP datagram with a source-specific destination
address MUST silently drop it unless a neighboring host or router has
communicated a desire to receive packets sent to the source and
destination address of the received packet.
5.2. Protocols
Certain IP multicast routing protocols already have the ability to
communicate source-specific joins to neighboring routers (in particular,
PIM-SM), and these protocols can, with slight modifications, be used to
provide source-specific semantics. Companion documents will specify the
required modifications to those protocols to support the source-
specific address range. Any protocols that use SSM addresses MUST also
comply with the requirements in this section.
A network can concurrently support SSM semantics in the SSM address
range and ISM in the rest of the class D address space, and it is
expected that this will be commonplace. In such a network, a router may
receive a non-source-specific, or "(*,G)" in conventional terminology,
request for delivery of traffic in the SSM range from a neighbor that
does not implement source-specific multicast in a manner compliant with
this document. A router that receives such a non-source-specific
request for data in the SSM range MUST NOT use the request to establish
forwarding state and MUST NOT propagate the request to other neighboring
routers. This applies both to any request received from a host, e.g.,
an IGMPv1 or IGMPv2 host report, and to any request received from a
routing protocol, e.g., a PIM-SM (*,G) join [PIM-SM]. The inter-router
case is further discussed in section 8, Transition Considerations.
To comply with this specification, a router MUST treat ALL addresses in
the 232/8 range with source-specific semantics. It is essential that
all routers in the network give source-specific semantics to the same
range of addresses in order to achieve the full benefit of SSM.
Holbrook/Cain [Page 8]
INTERNET-DRAFT Source-Specific Multicast 9 March 2000
6. Link-Layer Transmission of Datagrams
Source-specific multicast packets are transmitted on link-layer networks
as specified in RFC 1112. On many shared-medium link-layer networks
(e.g., Ethernet), the IP source address is not used in the mapping.
Consequently, on such a network, all packets sent to destination address
G will be delivered to any host that has subscribed to any channel
(S,G), regardless of S. And therefore, the IP module MUST filter
packets it receives from the link layer before delivering them to the
socket layer. A socket on which an (S,G) subscription has been
requested MUST receive packets whose source and destination address
match the requested subscription(s) for that socket.
7. Security Considerations
7.1. Denial-of-Service
A subscription request creates (S,G) state in a router to record the
subscription and invokes processing on that router and possibly causes
processing at neighboring routers. A host can mount a denial of service
attack by requesting a large number of subscriptions. A denial of
service can result if:
- a large amount of traffic arrives when it was otherwise undesired,
consuming network resources to deliver it and host resources to drop
it
- a large amount of (invalid) source-specific multicast state is
created in network routers, using router memory and CPU resources to
store and process the state
- a large amount of control traffic is generated to manage the
source-specific state, using router CPU and network bandwidth
To reduce the potential for damage from such an attack, a router MAY
have a configuration option to limit the following items:
- The total rate at which all hosts on any one interface are allowed
to initiate subscriptions (to limit the damage caused by forged
source-address attacks)
- The total number of subscriptions that can be initated from any
single interface.
A decision to use small limits should be taken carefully, as future
applications may be developed that can use large numbers of channels,
Holbrook/Cain [Page 9]
INTERNET-DRAFT Source-Specific Multicast 9 March 2000
and placing tight limits on the rate or number of channel subscriptions
may inhibit the development and deployment of such applications.
A router SHOULD verify that the source of a subscription request is a
valid address for the interface on which it was received. Failure to do
so would exacerbate a spoofed-source address attack.
We note that such an attack is not unique to SSM -- it is also present
for ISM.
7.2. Spoofed Source Addresses
By forging the source address in a datagram, an attacker can potentially
transmit datagrams on a channel that belongs to another host.
Applications that require strong authentication can not assume that all
packets that arrive on a source-specific destination address were sent
by the requested source, and higher-layer authentication should be used
to validate the source in such an application.
We note that some protection against spoofed source addresses is fairly
widespread for multicast today, because commonly deployed IP multicast
routing protocols [PIM-DM, PIM-SM, DVMRP] incorporate a reverse-path
forwarding check that validates that a multicast packet arrived on the
expected interface for its source address. It is anticipated that SSM
protocols will also incorporate such a check.
8. Transition Considerations
A host that uses the SSM address range in a fashion compliant with this
document will send ONLY source-specific host reports for addresses in
the SSM range. However, during a transition period, non-compliant hosts
might continue to send non-source-specific (IGMPv1 or IGMPv2) host
reports for source-specific destination addresses, and routers MUST
ignore these reports (as stated in Appendix I).
During a transition period, it may be possible to deliver SSM datagrams
through domains that are not SSM compliant by simply forwarding any
packet destined to G to all hosts that have requested subscription of
(S,G) for any S, even for an SSM destination address G. However, this
implementation risks placing an undue burden on the network
infrastructure to deliver (S,G) datagrams to hosts that did not request
them. Such an implementation for addresses in the SSM range is
specifically not compliant with Section 5.2 of this document.
Holbrook/Cain [Page 10]
INTERNET-DRAFT Source-Specific Multicast 9 March 2000
9. IANA Considerations
IANA has characterized the 232/8 address range as source-specific
multicast addresses, from its prior designation [IANA-ALLOCATION]. No
address transition plan is required by IANA.
Following the policies outlined in [IANA-CONSIDERATIONS], addresses in
the range 232.0.0.1 through 232.0.0.255 are reserved for allocation to
well-known and widely-applicable source-specific multicast applications
and services, under a policy of IETF Expert Review with Specification
Required.
The addresses in this range are reserved for services with wide
applicability that either require or would strongly benefit if all hosts
used a well-known SSM destination address for the application. When
considering an allocation in the 232.0.0.1-232.0.0.255 range, it should
be considered that, on an Ethernet network, any datagram sent to a well-
known SSM destination address will be transmitted to the same link-layer
destination address, regardless of its IP source address. Therefore,
the link-layer impact of allocating a well-known SSM address should be
considered carefully. Furthermore, the fact that channels with
destinations in 232.0.0/24 use the same link-layer addresses as the
reserved IP multicast group range 224.0.0/24 must also be taken under
consideration.
Except for the aforementioned addresses, IANA SHALL NOT allocate
destination addresses in this range to particular entities or for use by
particular applications. To do so would compromise one of the important
benefits of the source-specific model: the ability for a host to
autonomously allocate source-specific addresses without consulting a
remote authority.
10. Appendix I: IGMP Modifications For Source-Specific Multicast
The Internet Group Management Protocol (IGMP) [RFC1112,IGMPv2,IGMPv3],
is the standard mechanism for communicating IP multicast group
membership requests from a host to its locally attached routers. IGMP
version 3 (IGMPv3) [IGMPv3] adds the ability to selectively request or
filter traffic from individual sources within a multicast group. The
IGMPv3 algorithms and message processing rules require small changes to
support the source-specific multicast model. This Appendix defines the
modifications required to the host and router portions of IGMPv3 to
support source-specific multicast. A host or router that implements
IGMPv3 MUST implement the modifications defined in this Appendix to be
compliant with this document.
Holbrook/Cain [Page 11]
INTERNET-DRAFT Source-Specific Multicast 9 March 2000
10.1. IGMP Host Requirements for Source-Specific Multicast
This document does not require that the IP layer or the IGMP module of
an IGMPv3-enabled host treat SSM destination addresses specially. This
document does require host applications to:
- know the range of destination addresses that have SSM semantics
- use ONLY the source-specific APIs to request delivery of packets
sent to SSM destination addresses
The 232/8 address range is currently allocated for SSM, however routers
may be configured to force SSM semantics for other addresses, also. The
mechanism for discovering which addresses have SSM semantics is not
defined in this document.
Given that the host IP module is not required to know which addresses
are SSM and which addresses are not, the ISM APIs generally will not
return an error when applied to SSM destination addresses. However,
hosts that mistakenly use the ISM (e.g., "join(G)") or the full IGMPv3
APIs (e.g., "IPMulticastListen(G,EXCLUDE(S1))") to request delivery of
packets sent to an SSM address will not receive the requested service,
as routers will refuse to process any such request, as per section 10.2.
This section documents the behavior of hosts with respect to sending and
receiving the following IGMP message types:
- IGMPv1/v2 Reports
- IGMPv3 Reports
- IGMPv1/v2 Queries
- IGMPv2 Leave
- IGMPv2 Group Specific Query
- IGMPv3 Group Specific Query
- IGMPv3 Group-and-Source Specific Query
10.1.1. IGMPv1/v2 Reports
IGMPv1 or IGMPv2 host report are not processed for SSM addresses. They
will not ever be seen, if other hosts on the LAN agree about which
addresses have SSM semantics. As long as hosts use the SSM APIs for SSM
addresses. IGMPv1 and IGMPv2 host reports will not be sent for SSM
addresses.
Holbrook/Cain [Page 12]
INTERNET-DRAFT Source-Specific Multicast 9 March 2000
10.1.2. IGMPv3 Reports
Source-specific multicast destination-and-source pairs (channels) are
reported using IGMPv3 with the IGMPv3 INCLUDE report. A host
implementation MAY report either one or multiple channels in a single
IGMPv3 report.
When source-specific channels are reported in an IGMPv3 Report, the
report may contain one or more group records of the following types:
- MODE_IS_INCLUDE as part of a Current-State Record
- ALLOW_NEW_SOURCES as part of a State-Change Record
- BLOCK_OLD_SOURCES as part of a State-Change Record
The source list for any individual Group Record MAY be of length one or
more than one. If a host implementation so chooses, it MAY report both
SSM destination addresses and ISM destination addresses in the same
message.
If all applications use the SSM APIs for SSM addresses, then a host
would not normally send any of the following group record types for
addresses in the source-specific range:
- MODE_IS_EXCLUDE as part of a Current-State Record
- CHANGE_TO_INCLUDE_MODE as part of a Filter-Mode-Change Record
- CHANGE_TO_EXCLUDE_MODE as part of a Filter-Mode-Change Record
EXCLUDE mode does not apply to SSM addresses, and the filter mode used
for a SSM address should never change to or from EXCLUDE mode under
correct application behavior.
10.1.3. IGMPv1/IGMPv2 Queries
If an IGMPv1 or IGMPv2 query is received, the IGMPv3 protocol
specification requires the host to revert to the older (IGMPv1 or
IGMPv2) mode of operation for that destination address. If this occurs,
the host will stop reporting source-specific subscriptions for that
destination address and start using either IGMPv1 or IGMPv2 to report
interest in the SSM destination address, unqualified by a source
address. If this occurs, SSM semantics will no longer be applied for G.
Holbrook/Cain [Page 13]
INTERNET-DRAFT Source-Specific Multicast 9 March 2000
However, a router compliant with this document would never generate an
IGMPv1 or IGMPv2 query for an address in the SSM range, so this
situation would only occur if some router is not compliant with this
document for an address that the host believes to have SSM semantics.
If a host does revert to an older version of operation for some
destination address, it will no longer be able to send source-specific
IGMPv3 messages and it will not be able to subscribe to SSM channels
using that destination address. A host MAY have a configuration option
that allows it continue to send source-specific reception requests and
to refuse to revert to the older (IGMPv1 or IGMPv2) mode of operation
for addresses in the source-specific range, even if an IGMPv1 or IGMPv2
query is heard.
These problems only arise on a shared-medium link that has both SSM-
aware and non-SSM-aware routers present. Therefore, it SHOULD be
administratively assured that all routers on a given shared-medium
network are compliant with this document.
10.1.4. IGMPv2 Leave
IGMP Leave messages are not processed by hosts. IGMPv2 Leave messages
are not sent for SSM addresses.
10.1.5. IGMPv2 Group Specific Query
If a host receives an IGMPv2 Group Specific Query for an address in the
source-specific range, it MUST silently discard the query, even if the
group listed matches the source-specific destination address of some
locally subscribed source-specific group. The transmission of such a
query indicates that the sender is not compliant with this document.
10.1.6. IGMPv3 Group Specific Query
If a host receives an IGMPv3 Group-Specific Query in the source-specific
range, it MUST respond with a report if the group matches the source-
specific destination address of any of its subscribed source-specific
groups.
Although in the current IGMPv3 protocol specification, routers would
have no reason to send one, the semantics of such a query are well-
defined in this range and future implementations may have reason to send
such a query. Be liberal in what you accept.
Holbrook/Cain [Page 14]
INTERNET-DRAFT Source-Specific Multicast 9 March 2000
10.1.7. IGMPv3 Group-and-Source Specific Query
An IGMPv3 router will query a source-specific channel that a host has
requested to leave (via a BLOCK_OLD_SOURCES record) with a group-and-
source specific query. A host MUST respond to a group-and-source
specific query for which the group and source in the query match match
any channel for which the host has a subscription.
Hosts MUST be able to process a query with multiple sources listed per
group.
10.2. IGMP Router Requirements for Support Source-Specific Multicast
This section documents the behavior of routers with respect to the
following types of IGMP messages for source-specific destination
addresses:
- IGMPv3 Reports
- IGMPv3 General Query
- IGMPv3 Group-Specific Query
- IGMPv3 Group-and-Source Specific Query
- IGMPv1/v2 Reports
- IGMPv1/v2 Queries
- IGMPv2 Leave
10.2.1. IGMPv3 Reports
IGMPv3 Reports are used to report source-specific subscriptions in the
SSM address range. If a router receives an IGMPv3 report that contains
a group record for a destination address in the source-specific range
that matches one of the types listed below, then it MUST ignore that
group record, however, it MUST process other group records within that
same report.
- Any Current-State Record with MODE_IS_EXCLUDE
- A CHANGE_TO_INCLUDE_MODE Filter-Mode-Change Record
- A CHANGE_TO_EXCLUDE_MODE Filter-Mode-Change Record
10.2.2. IGMPv3 General Queries
IGMPv3 General Queries are used to periodically build the total desired
membership state on a subnet. These queries are used for the same
Holbrook/Cain [Page 15]
INTERNET-DRAFT Source-Specific Multicast 9 March 2000
purpose in the source-specific address range -- no change in behavior is
required. A router that supports the source-specific multicast address
range sends periodic IGMPv3 General Queries as per the IGMPv3
specification.
10.2.3. IGMPv3 Group Specific Queries
IGMPv3 routers that support source-specific multicast MAY send group-
specific queries for addresses in the source-specific range, although,
in the current IGMPv3 protocol spec, there is no scenario under which
this would occur.
10.2.4. IGMPv3 Group-and-Source Specific Queries
IGMPv3 Group-and-Source Specific Queries are used to verify that there
are no locally attached listeners when a receiver has indicated that it
is no longer interested in receiving traffic from a particular (S,G)
pair. Group-and-Source Specific Queries are used within the source-
specific address range when a router receives a BLOCK_OLD_SOURCES Record
for one or more source-specific groups.
10.2.5. IGMPv1/v2 Reports
An IGMPv1/v2 report for an address in the source-specific range could be
sent by a host that does not support the source-specific model. A
router MUST ignore all IGMPv1 and IGMPv2 reports in the source-specific
address range and specifically MUST NOT use them to establish IP
forwarding state.
10.2.6. IGMPv1/v2 Queries
The IGMP querier on a shared-medium network is elected to be the one
with lowest source IP address. Therefore, an IGMPv3 router will yield
to an IGMPv1 or v2 querier with a lower IP address. IGMPv3 routers that
lose the querier election to a lower version router MUST log an error,
as per the IGMPv3 specification. However, IGMPv3 routers MUST NOT
revert into previous version compatibility mode for the source-specific
address range. An IGMPv3 router that loses the querier election to an
IGMPv1 or v2 querier SHOULD continue to process source-specific reports
in the source-specific address range.
Holbrook/Cain [Page 16]
INTERNET-DRAFT Source-Specific Multicast 9 March 2000
10.2.7. IGMPv2 Leave
An IGMPv2 Leave may be received for a source-specific address from a
host that does not support the source-specific model. A router MUST
ignore all IGMPv2 leaves in the source-specific address range.
11. References
[IANA-ALLOCATION] Internet Assigned Numbers Authority,
http://www.isi.edu/in-notes/iana/assignments/multicast-addresses.
[IGMPv3] Cain, B., Deering, S., and A. Thyagarajan, "Internet Group
Management Protocol, Version 3," Work in Progress.
[RFC1112] Deering, S., "Host Extensions for IP Multicasting," RFC 1112,
August 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119, March 1997.
[RFC2771] Finlayson, R., "An Abstract API for Multicast Address
Allocation," RFC 2771, February 2000.
[IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2,"
RFC 2236, November 1997.
[IANA-CONSIDERATIONS] Narten, T., and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs," RFC 2434, October 1998.
[PIM-DM] Deering, S., Estrin, D., Farinacci, D., Jacobson, V., Helmy,
A., Meyer, D., and L. Wei, "Protocol Independent Multicast Version 2
Dense Mode Specification," Work in Progress.
[PIM-SM] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S.,
Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei, "Protocol
Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification," RFC
2362, June 1998.
[DVMRP] Waitzman, D., Partridge, C., and S. Deering., "Distance Vector
Multicast Routing Protocol," RFC 1075, Nov 1988.
[ADMIN-SCOPE] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
RFC 2365, July, 1998.
Holbrook/Cain [Page 17]
INTERNET-DRAFT Source-Specific Multicast 9 March 2000
12. Author's Address
Hugh Holbrook
Cisco Systems
holbrook@cisco.com
Brad Cain
Nortel Networks
bcain@nortelnetworks.com
This document expires September 9, 2000.
Holbrook/Cain [Page 18]