Internet Engineering Task Force Haixiang He INTERNET-DRAFT Brian Haberman Expire August, 2001 Hal Sandick Nortel Networks February, 2001 IGMP Mixed Version Proxying Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. Abstract IGMP proxying can be used to forward multicast data traffic in certain network topologies. The current specification only address IGMP proxying within the scope of the same IGMP version proxying. This document describes some mechanisms to address IGMP proxying within the scope of mixed IGMP version proxying. 1. Introduction IGMP proxying[1] can be used by IPv4 system to forward multicast traffic in certain network topologies. A device(Proxy) performing IGMP proxying has a single upstream interface and one or more He, Haberman, Sandick [Page 1] Internet Draft IGMP Mixed Version Proxying August, 2001 downstream interfaces. It performs IGMP host portion on its upstream interface and IGMP router portion on its downstream interfaces. The current specification [1] only describes the Proxy behavior in the scope of same version IGMP proxying. Same version IGMP proxying means the router portion and host portion that a Proxy performs are of the same version of IGMP. In more detail, the specification describes the Proxy behavior when the Proxy performs IGMPv2 [2] host portion on its upstream interface and IGMPv2 router portion on its downstream interfaces, and the Proxy behavior when the Proxy performs IGMPv3 [3] host part on its upstream interface and IGMPv3 router portion on its downstream interfaces. There are some scenarios that a Proxy's upstream link and downstream links are performing different version of IGMP. In these scenarios, the Proxy MAY perform IGMP mixed version proxying. This document specifies mechanisms to handle IGMP proxying in the scope of mixed version IGMP proxying. We follow the definitions specified in [1] and please refer [1] for IGMP proxying protocol definition. 1.1. Conventions 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 [4]. 2. IGMP Mixed Version Proxying and Proxy Behavior There are 4 scenarios that the a device MAY perform IGMP mixed version proxying. This section describes the Proxy behavior in each scenario of the IGMP mixed version proxying. 2.1. IGMPv3 to IGMPv2 Proxying In this scenario, the upstream link performs IGMPv2 and all the downstream links perform IGMPv3. The Proxy MAY perform IGMPv2 host portion on its upstream interface and IGMPv3 router portion on its downstream interfaces. In this scenario, the Proxy maintains an IGMPv3 based membership database. It performs IGMPv3 router portion on each downstream interface. The output of this protocol is a set of IGMPv3 He, Haberman, Sandick [Page 2] Internet Draft IGMP Mixed Version Proxying August, 2001 subscriptions; this set is maintained separately for each downstream interface. In addition, the subscriptions for each downstream interface are merged into the IGMPv3 based membership database using the IGMPv3 merging rules. An entry in the membership database is created or deleted following the rules specified in [3].If a change in the IGMPv2 state is required, the change is reported on the upstream interface using IGMPv2 join or leave message respectively. The IGMPv3 subscriptions are converted to IGMPv2 subscriptions by removing the source filter information. All other changes are ignored. The Proxy MAY use an IGMPv2 subscription cache for its upstream interface in order to efficiently report subscription activities. This cache MAY be first constructed by converting the whole IGMPv3 based membership database but MUST be updated accordingly to the rules described above. The change of the cache is reported using IGMPv2. The packets forwarding rule is similar to the rules described in [1]. In this scenario, the IGMPv3 subscriptions are used. The Proxy MAY receive more traffic from upstream interface than its downstream interfaces subscribe. But each downstream interface does not receive extra traffic. 2.2. IGMPv2 to IGMPv3 Proxying In this scenario, the upstream link performs IGMPv3 and all the downstream links perform IGMPv2. The Proxy MAY perform IGMPv3 host portion on its upstream interface and IGMPv2 router portion on its downstream interfaces. In this scenario, the Proxy maintains an IGMPv2 based membership database. It performs IGMPv2 router portion on each downstream interface. The output of this protocol is a set of IGMPv2 subscriptions; this set is maintained separately for each downstream interface. In addition, the subscriptions for each downstream interface are merged into the IGMPv2 based membership database using the IGMPv2 merging rules. When the membership database changes, the change is reported on the upstream interface using IGMPv3. In more detail, the IGMPv2 subscriptions are converted to IGMPv3 subscriptions as described in [3]. Then the converted IGMPv3 subscriptions are reported using IGMPv3 on the upstream interface. The packets forwarding rule is similar to the rules described in [1]. He, Haberman, Sandick [Page 3] Internet Draft IGMP Mixed Version Proxying August, 2001 In this scenario, the IGMPv2 subscriptions are used. 2.3. Mixed IGMP to IGMPv2 Proxying In this scenario, the upstream link performs IGMPv2 and some of the downstream links perform IGMPv2 while other downstream links perform IGMPv3. The Proxy MAY perform IGMPv2 host portion on its upstream interface, IGMPv2 router portion on downstream interfaces where the links they connect perform IGMPv2, and IGMPv3 router portion on other downstream interfaces. In this scenario, the Proxy follows the behavior as described in section 2.1 except that if a change in the IGMPv2 state is required due to downstream IGMPv2 subscriptions, the change is reported on the upstream interface. The packets forwarding rule is similar to the rules described in [1]. In this scenario, both the IGMPv2 subscriptions and IGMPv3 subscriptions are used. 2.4. Mixed IGMP to IGMPv3 Proxying In this scenario, the upstream link performs IGMPv3 and some of the downstream links perform IGMPv2 while other downstream links perform IGMPv3. The Proxy MAY perform IGMPv3 host portion on its upstream interface, IGMPv2 router portion on downstream interfaces where the links they connect perform IGMPv2, and IGMPv3 router portion on other downstream interfaces. In this scenario, the Proxy follows the behavior as described in section 2.2 except that if a change in the IGMPv3 state is required due to downstream IGMPv3 subscriptions, the change is reported on the upstream interface. The packets forwarding rule is the same as described in above scenario. 3. IGMPv2 Proxying Fall Back In any of the 4 scenarios, a device MAY fall back to use IGMPv2 proxying. In the case, the Proxy follows the behavior as described in [1]. A Proxy MAY have a configuration to indicate which mechanism to use. There are two disadvantages. First, the Proxy MAY receive extra He, Haberman, Sandick [Page 4] Internet Draft IGMP Mixed Version Proxying August, 2001 traffic. Second, it MAY force some links to perform IGMPv2 from IGMPv3. And because of this, it MAY cause more traffic on those links. 4. SSM Considerations This section describes the Proxy behavior for addresses in the source-specific range. The IGMPv3 behaviors described in [5] apply here. In scenario IGMPv3 to IGMPv2 proxying, the Proxy MAY have a configuration option to send source-specific subscription on upstream interface for addresses in the source-specific range as described in [5]. The source-specific subscriptions MAY be processed by an IGMPv3 querier on upstream link that losses the querier election to an IGMPv1 or IGMPv2 querier. In scenario IGMPv2 to IGMPv3 proxying, the Proxy SHOULD drop the IGMPv2 subscriptions for addresses in the source-specific range. However,a box MAY be configured to allow IGMPv2 reports to be turned into IGMPv3 reports. On a per interface basis, one or more group addresses in the SSM range can be configured such conversion. Each configured group address must be paired with a source address. In scenario Mixed IGMP to IGMPv2 proxying, the IGMPv2 subscriptions for addresses in the source-specific range MUST be ignored to construct the IGMPv3 membership database. The Proxy MAY also have the option as in scenario IGMPv3 to IGMPv2 proxying. The packets with source-specific addresses SHOULD not be forwarded to interfaces with IGMPv2 subscriptions for these addresses. In scenario Mixed IGMP to IGMPv3 proxying, the IGMPv2 SSM subscriptions MUST also be ignored. And the packets SHOULD also not be forwarded to interfaces with IGMPv2 SSM subscriptions. 5. Security Considerations This document does not cause extra security problems. The security considerations specified in [1], [3] apply here. 6. Acknowledgements Portions of the text of this document were copied from [1]. He, Haberman, Sandick [Page 5] Internet Draft IGMP Mixed Version Proxying August, 2001 References [1] Fenner, W., "IGMP-based Multicast Forwarding ("IGMP Proxying")", Internet-Draft, July, 2000. [2] Fenner, W., "Internet Group Management Protocol, Version2", RFC 2236, November 1997. [3] Cain, B., Deering, S., Fenner, W., Kouvelas, I., Thyagarajan, A., "Internet Group Management Protocol, Version 3", Internet-Draft, January 2001. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119/BCP 14, March 1997. [5] Holbrook, H., and Cain, B., "Using IGMPv3 For Source-Specific Multicast", Internet-Draft, July 2000. Author's Address: Haixiang He Nortel Networks 600 Technology Park Drive Billerica, MA 01821 Phone: 978-288-7482 Email: haixiang@nortelnetworks.com Brian Haberman Nortel Networks 4309 Emperor Blvd Suite 200 Durham, NC 27703 Email: haberman@nortelnetworks.com Hal Sandick Nortel Networks 4309 Emperor Blvd Suite 200 Durham, NC 27703 Email: hsandick@nortelnetworks.com He, Haberman, Sandick [Page 6]