Internet Engineering Task Force                                W. Fenner
INTERNET-DRAFT                                         February 26, 1999
draft-fenner-igmp-proxy-00.txt                       Expires August 1999

          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 August 1999                  [Page 1]


Internet Draft       draft-fenner-igmp-proxy-00.txt    February 26, 1999


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.

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.

2.2.  Downstream Interface

     Each of a router's interfaces that is not in the direction of the
     root of the tree.

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 membership on an interface.

3.  Abstract protocol definition

Each router performing IGMP-based forwarding has a single upstream
interface and one or more downstream interfaces.  It performs the router
side of the IGMP[Fenner97] protocol on its downstream interfaces, and
the host side of IGMP on its upstream interface.  The router MUST NOT
perform the router side of IGMP on its upstream interface.

The router maintains a database consisting of the merger of all member-
ships on any downstream interface.  When using IGMPv2, this is a simple
union of all group memberships received.  When using IGMPv3, the member-
ships are merged using the rules given in the IGMPv3 specification for
merging multiple memberships heard on a single interface.




Fenner                     Expires August 1999                  [Page 2]


Internet Draft       draft-fenner-igmp-proxy-00.txt    February 26, 1999


The router sends IGMP membership reports when queried, and sends unso-
licited 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.  It
removes the interface on which this packet arrived from the list and
forwards the packet to the remaining interfaces.  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.

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 side of the IGMP protocol on each down-
stream interface.  The output of this protocol is a set of multicast
group memberships; this set is maintained seperately on each downstream
interface.  In addition, the memberships on each downstream interface
are merged into 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 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 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 subscrip-
tions.  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' subscrip-
tions.  (Note: the assumption is that the root of the spanning tree is
connected to a wider multicast infrastructure, and that all multicast
must be delivered to the root in order to connect to the wider infras-
tructure.)






Fenner                     Expires August 1999                  [Page 3]


Internet Draft       draft-fenner-igmp-proxy-00.txt    February 26, 1999


5.  Security Considerations

     Must be filled in.

6.  References

Bradner97      Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", RFC 2119/BCP 14, Harvard University,
               March 1997.

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'', RFC2236, Xerox PARC, November 1997.

7.  Author's Address


   William C. Fenner
   Xerox PARC
   3333 Coyote Hill Road
   Palo Alto, CA 94304
   Phone: +1 650 812 4816
   Email: fenner@parc.xerox.com


























Fenner                     Expires August 1999                  [Page 4]