Internet Engineering Task Force                                W. Fenner
INTERNET-DRAFT                                             July 11, 2000
draft-fenner-igmp-proxy-03.txt                     Expires December 2000

          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 docu-
ments of the Internet Engineering Task Force (IETF), its Areas, and its
Working Groups.  Note that other groups may also distribute working doc-
uments 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 docu-
ments at any time.  It is not appropriate to use Internet Drafts as ref-
erence 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 rout-
     ing protocol.  It is sufficient to learn group membership informa-
     tion and simply forward based upon that information.  This draft
     describes a mechanism for forwarding based solely upon IGMP member-
     ship information.

This document is a product of an individual.  Comments are solicited and
should be addressed to the author.









Fenner                    Expires December 2000                 [Page 1]


Internet Draft       draft-fenner-igmp-proxy-03.txt        July 11, 2000


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 topol-
ogy.  The root of the tree is assumed to be connected to a wider multi-
cast 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 inter-
face 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] pro-
tocol 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 December 2000                 [Page 2]


Internet Draft       draft-fenner-igmp-proxy-03.txt        July 11, 2000


The router maintains a database consisting of the merger of all sub-
scriptions 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 specifica-
tion[CDT00] for merging multiple memberships heard on a single inter-
face.

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 algo-
rithm 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 subscrip-
tions; this set is maintained separately on each downstream interface.
In addition, the subscriptions on each downstream interface are merged



Fenner                    Expires December 2000                 [Page 3]


Internet Draft       draft-fenner-igmp-proxy-03.txt        July 11, 2000


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 down-
stream 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 per-
forming IGMPv2 on its upstream interface, the router sends [Robustness
Interval] 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.

CDT00          Cain, B., S. Deering and A. Thyagarajan, "Internet Group
               Management Protocol, Version 3".  Work in progress.





Fenner                    Expires December 2000                 [Page 4]


Internet Draft       draft-fenner-igmp-proxy-03.txt        July 11, 2000


Deering91      Deering, S., "Multicast Routing in a Datagram Internet-
               work", 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 December 2000                 [Page 5]