Internet DRAFT - draft-he-mixed-igmp-proxy
draft-he-mixed-igmp-proxy
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]
