Internet Engineering Task Force W. Fenner INTERNET-DRAFT April 3, 2001 draft-ietf-idmr-igmp-proxy-00.txt Expires October 2001 IGMP-based Multicast Forwarding (``IGMP Proxying'') 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "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. Distribution of this document is unlimited. Abstract In certain topologies, it is not necessary to run a multicast routing protocol. It is sufficient to learn group membership information and simply forward based upon that information. This draft describes a mechanism for forwarding based solely upon IGMP membership information. This document is a product of the IDMR working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at idmr@cs.ucl.ac.uk and/or the author. Fenner Expires October 2001 [Page 1]
Internet Draft draft-ietf-idmr-igmp-proxy-00.txt April 3, 2001 1. Introduction This document applies spanning tree multicast routing[Deering91] to an IGMP-only environment. The topology is limited to a tree, since we specify no protocol to build a spanning tree over a more complex topology. The root of the tree is assumed to be connected to a wider multicast infrastructure. 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 [Bradner97]. 2. Definitions 2.1. Upstream Interface A router's interface in the direction of the root of the tree. Also called the "Host interface". 2.2. Downstream Interface Each of a router's interfaces that is not in the direction of the root of the tree. Also called the "Router interfaces". 2.3. Membership Database The database maintained at each router into which the membership information of each of its downstream interfaces is merged. 2.4. Subscription When using IGMPv2, a group membership on an interface. When using IGMPv3, an IGMPv3 state entry (i.e. a (multicast address, group timer, filter-mode, source-element list) tuple) on an interface. 3. Abstract protocol definition A router performing IGMP-based forwarding has a single upstream interface and one or more downstream interfaces. These designations are explicitly configured; there is no protocol to determine what type each interface is. It performs the router portion of the IGMP[Fenner97] protocol on its downstream interfaces, and the host portion of IGMP on its upstream interface. The router MUST NOT perform the router portion of IGMP on its upstream interface. Fenner Expires October 2001 [Page 2]
Internet Draft draft-ietf-idmr-igmp-proxy-00.txt April 3, 2001 The router maintains a database consisting of the merger of all subscriptions on any downstream interface. When using IGMPv2, this is a simple union of all group memberships received. When using IGMPv3, the subscriptions are merged using the rules given in the IGMPv3 specification[CDFKT01] for merging multiple memberships heard on a single interface. The router sends IGMP membership reports on the upstream interface when queried, and sends unsolicited reports or leaves when the database changes. When the router receives a packet destined for a multicast group, it builds a list consisting of the upstream interface and any downstream interface which has a subscription pertaining to this packet and on which it is the IGMP Querier. It removes the interface on which this packet arrived from the list and forwards the packet to the remaining interfaces. Note that the rule that a router must be the querier in order to forward packets restricts the IP addressing scheme used; in particular, the IGMP-based forwarding routers must be given the lowest IP addresses of any potential IGMP Queriers on the link, in order to win the IGMP Querier election. If another device wins the IGMP Querier election, no packets will flow. This rule "piggy-backs" forwarder election on IGMP Querier election; it is necessary for links which multiple IGMP-based forwarders consider to be downstream. On a link with only one IGMP-based forwarding router, this rule MAY be disabled (i.e. the router MAY be configured to forward packets to an interface on which it is not the querier). However, the default configuration MUST include the querier rule. Note that this does not protect against an "upstream loop," where one router's upstream interface is considered to be another's downstream interface and vice versa. A spanning-tree or other tree building algorithm is required to resolve loops like this. 4. Router Behavior This section describes an IGMP-based multicast forwarding router's actions in more detail. 4.1. Membership Database maintenance The router performs the router portion of the IGMP protocol on each downstream interface. The output of this protocol is a set of subscriptions; this set is maintained separately on each downstream interface. In addition, the subscriptions on each downstream interface Fenner Expires October 2001 [Page 3]
Internet Draft draft-ietf-idmr-igmp-proxy-00.txt April 3, 2001 are merged into the membership database. When using IGMPv2, the membership database simply contains the union of all subscriptions on downstream interfaces. When using IGMPv3, the merging rules for multiple memberships on a single interface specified in the IGMPv3 specification[CDT99] are used to merge all subscriptions on downstream interfaces to create the membership database. When the composition of the membership database changes (e.g. the first downstream member joins or the last downstream member leaves, or a downstream member changes its IGMPv3 source subscriptions), the change in the database is reported on the upstream interface as though this router were a host performing the action. For example, when an IGMPv2 group member first appears on a downstream interface and the router is performing IGMPv2 on its upstream interface, the router sends [Robustness Variable] IGMPv2 reports on the upstream interface. 4.2. Forwarding Packets A router forwards packets received on its upstream interface to each downstream interface based upon the downstream interface's subscriptions and whether or not this router is the IGMP Querier on each interface. A router forwards packets received on any downstream interface to the upstream interface, and to each downstream interface other than the incoming interface based upon the downstream interfaces' subscriptions and whether or not this router is the IGMP Querier on each interface. A router MAY use a forwarding cache in order not to make this decision for each packet, but MUST update the cache using these rules any time any of the information used to build it changes. 5. Security Considerations - Since only the Querier forwards packets, the IGMP Querier election process may lead to black holes if a non-forwarder is elected Querier. An attacker on a downstream LAN can cause itself to get elected Querier resulting in no packets being forwarded. 6. References Bradner97 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119/BCP 14, Harvard University, March 1997. CDFKT01 Cain, B., S. Deering, B. Fenner, I. Kouvelas and A. Thyagarajan, "Internet Group Management Protocol, Version 3". Work in progress. (draft-ietf-idmr-igmp-v3-07.txt) Fenner Expires October 2001 [Page 4]
Internet Draft draft-ietf-idmr-igmp-proxy-00.txt April 3, 2001 Deering91 Deering, S., "Multicast Routing in a Datagram Internetwork", Ph.D. Thesis, Stanford University, December 1991. Fenner97 Fenner, W. ``Internet Group Management Protocol, Version 2'', RFC 2236, Xerox PARC, November 1997. 7. Author's Address William C. Fenner AT&T Labs - Research 75 Willow Rd Menlo Park, CA 94025 Phone: +1 650 330 7893 Email: fenner@research.att.com Fenner Expires October 2001 [Page 5]