Internet Engineering Task Force                              Haixiang He
INTERNET-DRAFT                                            Brian Haberman
Expire August, 2001                                          Hal Sandick
                                                         Nortel Networks
                                                          February, 2001


                      IGMP Mixed Version Proxying
                   <draft-he-mixed-igmp-proxy-00.txt>


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]