< draft-holbrook-idmr-igmpv3-ssm-00.txt   draft-holbrook-idmr-igmpv3-ssm-01.txt >
INTERNET-DRAFT IGMPv3 for SSM H. Holbrook INTERNET-DRAFT IGMPv3 for SSM H. Holbrook
Expires January 14, 2001 Cisco Systems Expires September 2, 2001 Cisco Systems
B. Cain B. Cain
Mirror Image Internet Cereva Networks
14 July 2000 2 March 2000
Using IGMPv3 For Source-Specific Multicast Using IGMPv3 For Source-Specific Multicast
<draft-holbrook-idmr-igmpv3-ssm-00.txt> <draft-holbrook-idmr-igmpv3-ssm-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 25 skipping to change at page 2, line 25
membership requests from a host to its locally attached routers. IGMP membership requests from a host to its locally attached routers. IGMP
version 3 (IGMPv3) [IGMPv3] provides the ability for a host to version 3 (IGMPv3) [IGMPv3] provides the ability for a host to
selectively request or filter traffic from individual sources within a selectively request or filter traffic from individual sources within a
multicast group. The IGMPv3 algorithms and message processing rules multicast group. The IGMPv3 algorithms and message processing rules
require small changes to support the source-specific multicast model. require small changes to support the source-specific multicast model.
This document defines the modifications required to the host and router This document defines the modifications required to the host and router
portions of IGMPv3 to support source-specific multicast. portions of IGMPv3 to support source-specific multicast.
2. IGMP Host Requirements for Source-Specific Multicast 2. IGMP Host Requirements for Source-Specific Multicast
This document does not require that the IP layer or the IGMP module of This document does not strictly require the IP layer or IGMP module of
an IGMPv3-enabled host treat SSM destination addresses specially. This an IGMPv3-enabled host to treat SSM destination addresses specially.
document does require host applications to: For correct operation of SSM, however, a host applications must
- know the range of destination addresses that have SSM semantics - know the range of destination addresses that have SSM semantics
- use ONLY the source-specific APIs to request delivery of packets - use ONLY the source-specific APIs to request delivery of packets
sent to SSM destination addresses sent to SSM destination addresses
The 232/8 address range is currently allocated for SSM, however routers The 232/8 address range is currently allocated for SSM by IANA [IANA-
may be configured to force SSM semantics for other addresses, also. The ALLOCATION], however hosts and routers may be configured to force SSM
mechanism for discovering which addresses have SSM semantics is not semantics for other addresses as well. A IGMP module on a host or
defined in this document. router SHOULD have a configuration mechanism to set the SSM address
range(s). If this configuration option exists, it MUST default to the
IANA-allocated SSM range. The mechanism for setting this configuration
option MUST at least allow for manual configuration. Protocol
mechanisms to set this option may be defined in subsequent documents.
If a host that does not have this option, applications on that host may
be denied SSM service by other non-compliant applications on the same
host or by other non-compliant hosts on the same network, as described
below.
Given that the host IP module is not required to know which addresses It is strongly recommened that the multicast source filtering (MSF) APIs
are SSM and which addresses are not, the ISM APIs generally will not of [MSFAPI] be used to implement SSM. If the host IP module receives a
return an error when applied to SSM destination addresses. However, non source-specific request for an SSM destination address, it SHOULD
hosts that mistakenly use the ISM (e.g., "join(G)") or the full IGMPv3 return an error to the application. If the host IP module is not
APIs (e.g., "IPMulticastListen(G,EXCLUDE(S1))") to request delivery of configured with the SSM address range, the non-source-specific (RFC
packets sent to an SSM address will not receive the requested service, 1112) APIs will not return an error when passed an SSM destination
as routers will refuse to process any such request, as per section 10.2. addresses. On these hosts, applicaitons that mistakenly use the wrong
APIs (e.g., "join(G)", or "IPMulticastListen(G,EXCLUDE(S1))" for IGMPv3)
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 This section documents the behavior of hosts with respect to sending and
receiving the following IGMP message types: receiving the following IGMP message types:
- IGMPv1/v2 Reports - IGMPv1/v2 Reports
- IGMPv3 Reports - IGMPv3 Reports
- IGMPv1/v2 Queries - IGMPv1/v2 Queries
- IGMPv2 Leave - IGMPv2 Leave
- IGMPv2 Group Specific Query - IGMPv2 Group Specific Query
- IGMPv3 Group Specific Query - IGMPv3 Group Specific Query
- IGMPv3 Group-and-Source Specific Query - IGMPv3 Group-and-Source Specific Query
2.1. IGMPv1/v2 Reports 2.1. IGMPv1/v2 Reports
IGMPv1 or IGMPv2 host report are not processed for SSM addresses. They A compliant host SHOULD NOT send IGMPv1 or IGMPv2 host reports for SSM
will not ever be seen, if other hosts on the LAN agree about which addresses. If an SSM-unaware IGMPv3-enabled host receives an IGMPv1 or
addresses have SSM semantics. As long as hosts use the SSM APIs for SSM IGMPv2 host report for SSM destination address G, its IGMP module will
addresses. IGMPv1 and IGMPv2 host reports will not be sent for SSM revert to IGMPv1/v2 compatibility mode for address G. This will prevent
addresses. the host from sending source-specific joins, and consequently the SSM
service model will not be provided for destination address G.
Therefore, it is important that the SSM address range be used only in
conjunction with the SSM APIs.
2.2. IGMPv3 Reports 2.2. IGMPv3 Reports
Source-specific multicast destination-and-source pairs (channels) are Source-specific multicast destination-and-source pairs (channels) are
reported using IGMPv3 with the IGMPv3 INCLUDE report. A host reported using IGMPv3 with the IGMPv3 INCLUDE report. A host
implementation MAY report either one or multiple channels in a single implementation MAY report either one or multiple channels in a single
IGMPv3 report. IGMPv3 report.
When source-specific channels are reported in an IGMPv3 Report, the When source-specific channels are reported in an IGMPv3 Report, the
report may contain one or more group records of the following types: report may contain one or more group records of the following types:
- MODE_IS_INCLUDE as part of a Current-State Record - MODE_IS_INCLUDE as part of a Current-State Record
- ALLOW_NEW_SOURCES as part of a State-Change Record - ALLOW_NEW_SOURCES as part of a State-Change Record
- BLOCK_OLD_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 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 more than one. If a host implementation so chooses, it may report both
SSM destination addresses and ISM destination addresses in the same SSM destination addresses and RFC 1112 multicast (henceforth termed Any-
Source Multicast or ASM as in [SSM]) destination addresses in the same
message. message.
If all applications use the SSM APIs for SSM addresses, then a host If all applications on a host use the SSM APIs for SSM addresses, then a
would not normally send any of the following group record types for host would not normally send any of the following group record types for
addresses in the source-specific range: addresses in the source-specific range:
- MODE_IS_EXCLUDE as part of a Current-State Record - MODE_IS_EXCLUDE as part of a Current-State Record
- CHANGE_TO_INCLUDE_MODE as part of a Filter-Mode-Change 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 - 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 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 for a SSM address should never change to or from EXCLUDE mode under
correct application behavior. [Note: please see Section 4, Outstanding correct application behavior. [Note: please see Section 4, Outstanding
Issues.] Issues.] A host that is configured with the SSM address range MUST NOT
send any of the above record types for an SSM address.
2.3. IGMPv1/IGMPv2 Queries 2.3. IGMPv1/IGMPv2 Queries
If an IGMPv1 or IGMPv2 query is received, the IGMPv3 protocol If an IGMPv1 or IGMPv2 query is received, the IGMPv3 protocol
specification requires the host to revert to the older (IGMPv1 or specification requires the host to revert to the older (IGMPv1 or
IGMPv2) mode of operation for that destination address. If this occurs, IGMPv2) mode of operation for that destination address. If this occurs,
the host will stop reporting source-specific subscriptions for that the host will stop reporting source-specific subscriptions for that
destination address and start using either IGMPv1 or IGMPv2 to report destination address and start using either IGMPv1 or IGMPv2 to report
interest in the SSM destination address, unqualified by a source interest in the SSM destination address, unqualified by a source
address. If this occurs, SSM semantics will no longer be applied for G. address. If this occurs, SSM semantics will no longer be applied for G.
However, a router compliant with this document would never generate an A router compliant with this document would never generate an IGMPv1 or
IGMPv1 or IGMPv2 query for an address in the SSM range, so this IGMPv2 query for an address in the SSM range, so this situation would
situation would only occur if some router is not compliant with this only occur if some router is not compliant with this document for an
document for an address that the host believes to have SSM semantics. address that the host believes to have SSM semantics.
If a host does revert to an older version of operation for some When a host reverts to an older version of operation for some
destination address, it will no longer be able to send source-specific 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 IGMPv3 messages and applications on that host will not be able to
using that destination address. A host MAY have a configuration option subscribe to SSM channels using that destination address. A host that
that allows it continue to send source-specific reception requests and is configured with the SSM address range MAY have a configuration option
to refuse to revert to the older (IGMPv1 or IGMPv2) mode of operation to allow it continue to to refuse to revert to the older (IGMPv1 or
for addresses in the source-specific range, even if an IGMPv1 or IGMPv2 IGMPv2) mode of operation for addresses in the source-specific range,
query is heard. even if an IGMPv1 or IGMPv2 query is heard.
These problems only arise on a shared-medium link that has both SSM- These problems only arise on a shared-medium link that has both SSM-
aware and non-SSM-aware routers present. Therefore, it SHOULD be aware and non-SSM-aware routers present. Therefore, it SHOULD be
administratively assured that all routers on a given shared-medium administratively assured that all routers on a given shared-medium
network are compliant with this document. network are compliant with this document.
2.4. IGMPv2 Leave 2.4. IGMPv2 Leave
IGMP Leave messages are not processed by hosts. IGMPv2 Leave messages IGMP Leave messages are not processed by hosts. IGMPv2 Leave messages
are not sent for SSM addresses. are not sent for SSM addresses.
2.5. IGMPv2 Group Specific Query 2.5. IGMPv2 Group Specific Query
If a host receives an IGMPv2 Group Specific Query for an address in the If a host receives an IGMPv2 Group Specific Query for an address in its
source-specific range, it MUST silently discard the query, even if the configured source-specific range, it MUST silently discard the query,
group listed matches the source-specific destination address of some even if the group listed matches the source-specific destination address
locally subscribed source-specific group. The transmission of such a of some locally subscribed source-specific group. The transmission of
query indicates that the sender is not compliant with this document. such a query indicates that the sender is not compliant with this
document.
2.6. IGMPv3 Group Specific Query 2.6. IGMPv3 Group Specific Query
If a host receives an IGMPv3 Group-Specific Query in the source-specific If a host receives an IGMPv3 Group-Specific Query in its configured
range, it MUST respond with a report if the group matches the source- source-specific range, it MUST respond with a report if the group
specific destination address of any of its subscribed source-specific matches the source-specific destination address of any of its subscribed
groups. source-specific groups.
Although in the current IGMPv3 protocol specification, routers would Although in the current IGMPv3 protocol specification, routers would
have no reason to send one, the semantics of such a query are well- 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 defined in this range and future implementations may have reason to send
such a query. Be liberal in what you accept. such a query. Be liberal in what you accept.
2.7. IGMPv3 Group-and-Source Specific Query 2.7. IGMPv3 Group-and-Source Specific Query
An IGMPv3 router will query a source-specific channel that a host has 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- 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 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 specific query for which the group and source in the query match match
any channel for which the host has a subscription. any channel for which the host has a subscription.
Hosts MUST be able to process a query with multiple sources listed per Hosts MUST be able to process a query with multiple sources listed per
group. group.
3. IGMP Router Requirements for Support Source-Specific Multicast 3. IGMP Router Requirements for Support Source-Specific Multicast
Routers must be aware of the SSM address range. The 232/8 address range
is currently allocated for SSM by IANA [IANA-ALLOCATION]. However, an
SSM router may be configured to force SSM semantics for other addresses
as well. If this configuration option exists, it MUST default to the
IANA-allocated range.
This section documents the behavior of routers with respect to the This section documents the behavior of routers with respect to the
following types of IGMP messages for source-specific destination following types of IGMP messages for source-specific destination
addresses: addresses:
- IGMPv3 Reports - IGMPv3 Reports
- IGMPv3 General Query - IGMPv3 General Query
- IGMPv3 Group-Specific Query - IGMPv3 Group-Specific Query
- IGMPv3 Group-and-Source Specific Query - IGMPv3 Group-and-Source Specific Query
- IGMPv1/v2 Reports - IGMPv1/v2 Reports
- IGMPv1/v2 Queries - IGMPv1/v2 Queries
- IGMPv2 Leave - IGMPv2 Leave
3.1. IGMPv3 Reports 3.1. IGMPv3 Reports
IGMPv3 Reports are used to report source-specific subscriptions in the IGMPv3 Reports are used to report source-specific subscriptions in the
SSM address range. If a router receives an IGMPv3 report that contains SSM address range. If a router receives an IGMPv3 report that contains
a group record for a destination address in the source-specific range a group record for a destination address in source-specific range that
that matches one of the types listed below, then it MUST ignore that matches one of the types listed below, then it MUST ignore that group
group record, however, it MUST process other group records within that record, however, it MUST process other group records within that same
same report. report.
- Any Current-State Record with MODE_IS_EXCLUDE - Any Current-State Record with MODE_IS_EXCLUDE
- A CHANGE_TO_INCLUDE_MODE Filter-Mode-Change Record - A CHANGE_TO_INCLUDE_MODE Filter-Mode-Change Record
- A CHANGE_TO_EXCLUDE_MODE Filter-Mode-Change Record - A CHANGE_TO_EXCLUDE_MODE Filter-Mode-Change Record
3.2. IGMPv3 General Queries 3.2. IGMPv3 General Queries
IGMPv3 General Queries are used to periodically build the total desired IGMPv3 General Queries are used to periodically build the total desired
membership state on a subnet. These queries are used for the same membership state on a subnet. These queries are used for the same
purpose in the source-specific address range -- no change in behavior is purpose in the source-specific address range -- no change in behavior is
required. A router that supports the source-specific multicast address required. An SSM router sends periodic IGMPv3 General Queries as per
range sends periodic IGMPv3 General Queries as per the IGMPv3 the IGMPv3 specification.
specification.
3.3. IGMPv3 Group Specific Queries 3.3. IGMPv3 Group Specific Queries
IGMPv3 routers that support source-specific multicast MAY send group- IGMPv3 routers that support source-specific multicast MAY send group-
specific queries for addresses in the source-specific range, although, specific queries for addresses in the source-specific range, although,
in the current IGMPv3 protocol spec, there is no scenario under which in the current IGMPv3 protocol spec, there is no scenario under which
this would occur. this would occur.
3.4. IGMPv3 Group-and-Source Specific Queries 3.4. IGMPv3 Group-and-Source Specific Queries
skipping to change at page 7, line 26 skipping to change at page 8, line 5
address range. An IGMPv3 router that loses the querier election to an address range. An IGMPv3 router that loses the querier election to an
IGMPv1 or v2 querier SHOULD continue to process source-specific reports IGMPv1 or v2 querier SHOULD continue to process source-specific reports
in the source-specific address range. in the source-specific address range.
3.7. IGMPv2 Leave 3.7. IGMPv2 Leave
An IGMPv2 Leave may be received for a source-specific address from a 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 host that does not support the source-specific model. A router MUST
ignore all IGMPv2 leaves in the source-specific address range. ignore all IGMPv2 leaves in the source-specific address range.
4. Outstanding Issues 4. A Note on EXCLUDE Mode
EXCLUDE mode does not apply to SSM addresses, and the filter mode used [To be removed before going to the IESG.]
for a SSM address should never change to or from EXCLUDE mode under
correct application behavior. The IGMPv3 specification indicates that a
host should convert to EXCLUDE mode operation when it no longer has
enough memory to record INCLUDE mode requests. For SSM, it would be
preferable to return an error indication.
However, as specified in this document, a host does not have any The IGMPv3 specification formerly indicated that a host should convert
knowledge about the range of addresses that have SSM semantics -- only a to EXCLUDE mode operation when it no longer has enough memory to record
router has this information. One possible solution is to allow the INCLUDE mode requests. This would cause SSM working applications to
application layer to provide this information. In this solution, the suddenly break when the router runs out of memory for subsequent joins.
IGMPv3 IPMulticastListen API is extended to allow a host to request an The IGMPv3 protocol specification was subsequently changed to say that a
INCLUDE-mode subscription that must not be converted to an EXCLUDE mode host MUST NOT transition to EXCLUDE mode as a result of running out of
subscription if the router runs out of memory. resources.
5. Acknowledgments 5. Acknowledgments
The authors would like to thank Vince Laviano, Nidhi Bhaskar, and Steve The authors would like to thank Vince Laviano, Nidhi Bhaskar, and Steve
Deering and for their input and careful review. Deering and for their input and careful review.
6. References 6. References
[IGMPv3] Cain, B., Deering, S., and A. Thyagarajan, "Internet Group [IGMPv3] Cain, B., Deering, S., and A. Thyagarajan, "Internet Group
Management Protocol, Version 3," Work in Progress. Management Protocol, Version 3," Work in Progress.
[RFC1112] Deering, S., "Host Extensions for IP Multicasting," RFC 1112, [RFC1112] Deering, S., "Host Extensions for IP Multicasting," RFC 1112,
August 1989. August 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119, March 1997. Requirement Levels," RFC 2119, March 1997.
[IANA-ALLOCATION] Internet Assigned Numbers Authority,
http://www.isi.edu/in-notes/iana/assignments/multicast-addresses.
[IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2," [IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2,"
RFC 2236, November 1997. RFC 2236, November 1997.
[MSFAPI] Thaler, D., Fenner, B., and Quinn, B. "Socket Interface
Extensions for Multicast Source Filters." Work in Progress.
[SSM] Holbrook, H., and Cain, B., "Source-Specific Multicast for IP", [SSM] Holbrook, H., and Cain, B., "Source-Specific Multicast for IP",
Work in Progress. Work in Progress.
7. Author's Address 7. Author's Address
Hugh Holbrook Hugh Holbrook
Cisco Systems Cisco Systems
170 W. Tasman Drive.
San Jose, CA 95134
holbrook@cisco.com holbrook@cisco.com
Brad Cain Brad Cain
Nortel Networks Cereva Networks
bcain@nortelnetworks.com 3 Network Drive
Marlborough, MA 01752
bcain@cereva.com
This document expires January 14, 2001. This document expires September 2, 2001.
 End of changes. 28 change blocks. 
73 lines changed or deleted 101 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/