[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 RFC 4605

MAGMA Working Group                           Bill Fenner, AT&T Research
INTERNET-DRAFT                              Haixiang He, Nortel Networks
draft-ietf-magma-igmp-proxy-02.txt      Brian Haberman, Caspian Networks
                                      Hal Sandick, Sheperd Middle School
Expire: September, 2003                                      March, 2002



       IGMP/MLD-based Multicast Forwarding ("IGMP/MLD 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

   In certain topologies, it is not necessary to run a multicast routing
   protocol.  It is sufficient to learn and proxy group membership
   information and simply forward based upon that information.  This
   draft describes a mechanism for forwarding based solely upon Internet
   Group Management Protocol (IGMP) or Multicast Listener Discovery
   (MLD) membership information.



1. Introduction

   This document applies spanning tree multicast routing [Deering91] to
   an Internet Group Management Protocol (IGMP) or Multicast Listener



Fenner, He, Haberman, Sandick                                   [Page 1]

Internet Draft     draft-ietf-magma-igmp-proxy-02.txt    September, 2003


   Discovery (MLD) 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.

   This document is a product of the Multicast & Anycast Group
   Membership (MAGMA) working group within the Internet Engineering Task
   Force.  Comments are solicited and should be addressed to the working
   group's mailing list at magma@ietf.org and/or the authors.


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 proxy device's interface in the direction of the root of the tree.
   Also called the "Host interface".


2.2. Downstream Interface

   Each of a proxy device's interfaces that is not in the direction of
   the root of the tree.  Also called the "Router interfaces".


2.3. Group Mode

   In IPv4 environment, for each multicast group, a group is in IGMP
   version 1 (IGMPv1) [Deering89] mode if an IGMPv1 report is heard. A
   group is in IGMP version 2 (IGMPv2) [Fenner97] mode if an IGMPv2
   report is heard but no IGMPv1 report is heard. A group is in IGMP
   version 3 (IGMPv3) [CDFKT02] mode if an IGMPv3 report is heard but no
   IGMPv1 or IGMPv2 report is heard.

   In IPv6 environment, for each multicast group, a group is in MLD
   version 1 (MLDv1) [DFH99] mode if a MLDv1 report is heard. MLDv1 is
   equivalent to IGMPv2.  A group is in MLD version 2 (MLDv2)
   [VCFDFKH02] mode if an MLDv2 report is heard but no MLDv1 report is
   heard. MLDv2 is equivalent to IGMPv3.





Fenner, He, Haberman, Sandick                                   [Page 2]

Internet Draft     draft-ietf-magma-igmp-proxy-02.txt    September, 2003


2.4.  Subscription

   When a group is in IGMPv1 or IGMPv2/MLDv1 mode, the subscription is a
   group membership on an interface.  When a group is in IGMPv3/MLDv2
   mode, the subscription is a an IGMPv3/MLDv2 state entry (i.e. a
   (multicast address, group timer, filter-mode, source-element list)
   tuple) on an interface.




2.5.  Membership Database

   The database maintained at each proxy device into which the
   membership information of each of its downstream interfaces is
   merged.


3.  Abstract protocol definition

   A proxy device performing IGMP/MLD-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 [Deering89, Fenner97, CDFKT02] or MLD [DFH99,
   VCFDFKH02] protocol on its downstream interfaces, and the host
   portion of IGMP/MLD on its upstream interface.  The proxy device MUST
   NOT perform the router portion of IGMP/MLD on its upstream interface.

   The proxy device maintains a database consisting of the merger of all
   subscriptions on any downstream interface. Refer to section 4 for the
   details about the construction and maintenance of the membership
   database.

   The proxy device sends IGMP/MLD membership reports on the upstream
   interface when queried, and sends unsolicited reports or leaves when
   the database changes.

   When the proxy device receives a packet destined for a multicast
   group (channel in Source-Specific Multicast (SSM)), it uses 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/MLD Querier.  This list may be built dynamically or cached.
   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 proxy device must be the querier in order
   to forward packets restricts the IP addressing scheme used; in
   particular, the IGMP/MLD-based forwarding devices must be given the



Fenner, He, Haberman, Sandick                                   [Page 3]

Internet Draft     draft-ietf-magma-igmp-proxy-02.txt    September, 2003


   lowest IP addresses of any potential IGMP/MLD Querier on the link, in
   order to win the IGMP/MLD Querier election.  If another device wins
   the IGMP/MLD Querier election, no packets will flow.

   The election of a single forwarding proxy is necessary to avoid local
   loops and redundant traffic for links which are considered to be
   downstream links by multiple IGMP/MLD-based forwarders. This rule
   "piggy-backs" forwarder election on IGMP/MLD Querier election. The
   use of the IGMP/MLD Querier election process to choose the forwarding
   proxy delivers similar functionality on the local link as the
   Protocol Independent Multicast (PIM) Assert mechanism.  On a link
   with only one IGMP/MLD-based forwarding device, this rule MAY be
   disabled (i.e. the device 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.

   For example, for redundancy purpose, as shown in the figure below:

           LAN 1  --------------------------------------
                  Upstream |              | Upstream
                           A              B
                Downstream |              | Downstream
           LAN 2  --------------------------------------

   LAN 2 can have two proxy devices A and B. In such configuration, one
   proxy device must be elected to forward the packets. This document
   requires that the forwarder must be the IGMP/MLD querier. So proxy
   device A will forward packets to LAN 2 only if A is the querier. In
   the above figure, if A is the only proxy device, A can be configured
   to forward packets even though B is the querier.


   Note that this does not protect against an "upstream loop". For
   example, as shown in the figure below:


           LAN 1  --------------------------------------
                  Upstream |              | Downstream
                           A              B
                Downstream |              | Upstream
           LAN 2  --------------------------------------


   B will unconditionally forward packets from LAN 1 to LAN 2, and A
   will unconditionally forward packets from LAN 2 to LAN 1.  This will
   cause an upstream loop. A multicast routing protocol which employs a
   tree building algorithm is required to resolve loops like this.





Fenner, He, Haberman, Sandick                                   [Page 4]

Internet Draft     draft-ietf-magma-igmp-proxy-02.txt    September, 2003


3.1. Topology Restrictions

   This specification describes a protocol that works only in a simple
   tree topology.  The tree must be manually configured by designating
   upstream and downstream interfaces on each proxy device, and the root
   of the tree is expected to be connected to a wider multicast
   infrastructure.


3.2. Supporting Senders

   In order for senders to send from inside the proxy tree, all traffic
   is forwarded towards the root.  The multicast router(s) connected to
   the wider multicast infrastructure should be configured to treat all
   systems inside the proxy tree as though they were directly connected
   -- e.g., for Protocol Independent Multicast - Sparse Mode (PIM-SM)
   [FHHK02], these routers should Register-encapsulate traffic from new
   sources within the proxy tree just as they would directly-connected
   sources.

   This information is likely to be manually configured; IGMP/MLD-based
   multicast forwarding provides no way for the routers upstream of the
   proxy tree to know what networks are connected to the proxy tree. If
   the proxy topology is congruent with some routing topology, this
   information MAY be learned from the routing protocol running on the
   topology; e.g. a router may be configured to treat multicast packets
   from all prefixes learned from routing protocol X via interface Y as
   though they were from a directly connected system.


4.  Proxy Device Behavior

   This section describes an IGMP/MLD-based multicast forwarding
   device's actions in more detail.


4.1.  Membership Database

   The proxy device performs the router portion of the IGMP/MLD protocol
   on each downstream interface.  For each interface, the version of
   IGMP/MLD used is explicitly configured and defaults to the highest
   version supported by the system.

   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 are merged into the
   membership database.

   The membership database is a set of membership records of the form:



Fenner, He, Haberman, Sandick                                   [Page 5]

Internet Draft     draft-ietf-magma-igmp-proxy-02.txt    September, 2003


           (multicast-address, filter-mode, source-list)

   Each record is the result of the merge of all subscriptions for that
   record's multicast-address on downstream interfaces. If some
   subscriptions are IGMPv1 or IGMPv2/MLDv1 subscriptions, these
   subscriptions are converted to IGMPv3/MLDv2 subscriptions. The
   IGMPv3/MLDv2 and the converted subscriptions are first preprocessed
   to remove the timers in the subscriptions, and if the filter mode is
   EXCLUDE, to remove every source whose source timer > 0. Then the
   preprocessed subscriptions are merged using the merging rules for
   multiple memberships on a single interface specified in the
   IGMPv3/MLDv2 specification[CDFKT02,VCFDFKH02] to create the
   membership record. For example, there are two downstream interfaces
   I1 and I2 that have subscriptions for multicast address G. I1 has an
   IGMPv2/MLDv1 subscription that is (G). I2 has an IGMPv3/MLDv2
   subscription that has membership information (G, INCLUDE, (S1, S2)).
   The I1's subscription is converted to an IGMPv3/MLDv2 subscription
   that has membership information (G, EXCLUDE, NULL). Then the
   subscriptions are preprocessed and merged and final membership record
   is (G, EXCLUDE, NULL).

   The proxy device performs the host portion of the IGMP/MLD protocol
   on upstream interface. If there is an IGMPv1 or IGMPv2/MLDv1 querier
   on upstream network, then the proxy device will perform IGMPv1 or
   IGMPv2/MLDv1 on upstream interface accordingly. Otherwise, it will
   perform IGMPv3/MLDv2.

   If the proxy device performs IGMPv3/MLDv2 on upstream interface, then
   when the composition of the membership database changes, the change
   in the database is reported on the upstream interface as though this
   proxy device were a host performing the action. If the proxy device
   performs IGMPv1 or IGMPv2/MLDv1 on upstream interface, then when the
   membership records are created or deleted, the changes are reported
   on the upstream interface.  All other changes are ignored. When the
   proxy device reports using IGMPv1 or IGMPv2/MLDv1, only the multicast
   address field in the membership record is used.


4.2.  Forwarding Packets

   A proxy device forwards packets received on its upstream interface to
   each downstream interface based upon the downstream interface's
   subscriptions and whether or not this proxy device is the IGMP/MLD
   Querier on each interface. A proxy device 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 proxy
   device is the IGMP/MLD Querier on each interface. A proxy device MAY
   use a forwarding cache in order not to make this decision for each



Fenner, He, Haberman, Sandick                                   [Page 6]

Internet Draft     draft-ietf-magma-igmp-proxy-02.txt    September, 2003


   packet, but MUST update the cache using these rules any time any of
   the information used to build it changes.


4.3. SSM Considerations

   To support Source-Specific Multicast (SSM), the proxy device should
   be compliant with the specification about using IGMPv3 for SSM
   [HC01].  Note that the proxy device should be compliant with both the
   IGMP Host Requirement and the IGMP Router Requirement for SSM since
   it performs IGMP Host Portion on upstream interface and IGMP Router
   Portion on each downstream interface.

   An interface can be configured to perform IGMPv1 or IGMPv2. In this
   scenario, the SSM semantic will not be maintained for that interface.
   However, a proxy device that supports this document should ignore
   those IGMPv1 or IGMPv2 subscriptions sent to SSM addresses. And more
   importantly, the packets with source-specific addresses SHOULD not be
   forwarded to interfaces with IGMPv2 or IGMPv1 subscriptions for these
   addresses.


5. Security Considerations

   Since only the Querier forwards packets, the IGMP/MLD 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
   be elected Querier resulting in no packets being forwarded.

   IGMP/MLD-based forwarding does not provide "upstream loop" detection
   mechanism as described in section 3. Hence to avoid the problems
   caused by "upstream loop", it MUST be administratively assured that
   such loops don't exist when deploying IGMP/MLD Proxying.

   The IGMP/MLD information presented by the proxy to its upstream
   routers is the aggregation of all its downstream group membership
   information.  Any access control applied on the group membership
   protocol at the upstream router can not be performed on a single
   subscriber. That is, the access control will apply equally to all the
   interested hosts reachable via the proxy device.



Normative References

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




Fenner, He, Haberman, Sandick                                   [Page 7]

Internet Draft     draft-ietf-magma-igmp-proxy-02.txt    September, 2003


   CDFKT02     Cain, B., S. Deering, B. Fenner, I. Kouvelas and A.
               Thyagarajan, "Internet Group Management Protocol,
               Version 3", RFC 3376, October 2002.

   Fenner97    Fenner, W., "Internet Group Management Protocol,
               Version 2", RFC 2236, Xerox PARC, November 1997.

   Deering89   Deering, S., "Host Extensions for IP Multicasting",
               RFC 1112, August 1989.

   DFH99       Deering, S., Fenner, W., and Haberman, B., "Multicast
               Listener Discovery (MLD) for IPv6", RFC 2710,
               October 1999.

   VCFDFKH02   Vida, R., Costa, L., Fdida, S., Deering, S., Fenner, B.,
               Kouvelas, I., and Haberman, B., "Multicast Listener
               Discovery Version 2 (MLDv2) for IPv6", Work in Progress.



Informative References

   Deering91   Deering, S., "Multicast Routing in a Datagram
               Internetwork", Ph.D. Thesis, Stanford University,
               December 1991.

   FHHK02      Fenner, W., Handley, M., Holbrook, H., and Kouvelas, I.,
               "Protocol Independent Multicast - Sparse Mode (PIM-SM):
               Protocol Specification (Revised)", Work in Progress.

   HC01        Holbrook, H., and Cain, B., "Using IGMPv3 for Source-
               Specific Multicast", Work in Progress.


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

     Haixiang He
     Nortel Networks
     600 Technology Park Drive
     Billerica, MA 01821
     Phone: +1 978 288 7482
     Email: haixiang@nortelnetworks.com



Fenner, He, Haberman, Sandick                                   [Page 8]

Internet Draft     draft-ietf-magma-igmp-proxy-02.txt    September, 2003


     Brian Haberman
     Caspian Networks
     One Park Drive, Suite 400
     Research Triangle Park, NC  27709
     Phone: +1 919 949 4828
     Email: bkhabs@nc.rr.com

     Hal Sandick
     Sheperd Middle School
     2401 Dakota St.
     Durham, NC 27707
     Email: sandick@nc.rr.com


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgement:

   Funding for the RFC Editor function is currently provided by the
   Internet Society.





Fenner, He, Haberman, Sandick                                   [Page 9]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/