INTERNET-DRAFT IGMPv3 for SSM H. Holbrook Expires January 14, 2001 Cisco Systems B. Cain Mirror Image Internet 14 July 2000 Using IGMPv3 For Source-Specific Multicast 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 IGMPv3 for SSM 14 July 2000 Abstract This document describes changes to the Internet Group Management Protocol Version 3 (IGMPv3) [IGMPv3] to support source-specific multicast (SSM) [SSM]. 1. Overview and Rationale 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] provides the ability for a host 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 document defines the modifications required to the host and router portions of IGMPv3 to support 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 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: Holbrook/Cain [Page 2] INTERNET-DRAFT IGMPv3 for SSM 14 July 2000 - IGMPv1/v2 Reports - IGMPv3 Reports - IGMPv1/v2 Queries - IGMPv2 Leave - IGMPv2 Group Specific Query - IGMPv3 Group Specific Query - IGMPv3 Group-and-Source Specific Query 2.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. 2.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 Holbrook/Cain [Page 3] INTERNET-DRAFT IGMPv3 for SSM 14 July 2000 - 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. [Note: please see Section 4, Outstanding Issues.] 2.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. 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. 2.4. IGMPv2 Leave IGMP Leave messages are not processed by hosts. IGMPv2 Leave messages are not sent for SSM addresses. 2.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 Holbrook/Cain [Page 4] INTERNET-DRAFT IGMPv3 for SSM 14 July 2000 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. 2.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. 2.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. 3. 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 Holbrook/Cain [Page 5] INTERNET-DRAFT IGMPv3 for SSM 14 July 2000 3.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 3.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 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. 3.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. 3.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. 3.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 Holbrook/Cain [Page 6] INTERNET-DRAFT IGMPv3 for SSM 14 July 2000 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. 3.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. 3.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. 4. Outstanding Issues 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. 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 knowledge about the range of addresses that have SSM semantics -- only a router has this information. One possible solution is to allow the application layer to provide this information. In this solution, the IGMPv3 IPMulticastListen API is extended to allow a host to request an INCLUDE-mode subscription that must not be converted to an EXCLUDE mode subscription if the router runs out of memory. 5. Acknowledgments The authors would like to thank Vince Laviano, Nidhi Bhaskar, and Steve Deering and for their input and careful review. Holbrook/Cain [Page 7] INTERNET-DRAFT IGMPv3 for SSM 14 July 2000 6. References [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. [IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2," RFC 2236, November 1997. [SSM] Holbrook, H., and Cain, B., "Source-Specific Multicast for IP", Work in Progress. 7. Author's Address Hugh Holbrook Cisco Systems holbrook@cisco.com Brad Cain Nortel Networks bcain@nortelnetworks.com This document expires January 14, 2001. Holbrook/Cain [Page 8]