Internet DRAFT - draft-girish-raj-proxy-reporting-impl
draft-girish-raj-proxy-reporting-impl
INTERNET-DRAFT Girish Kumar Gupta
Category: Informational Future Software
Expires: January 2005 Rajesh Babu Nataraja
RiverStone Networks
July 2004
Implementation of IGMP and MLD Proxy-Reporting Switches
<draft-girish-raj-proxy-reporting-impl-00.txt>
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be discarded, any of which I become aware will be
disclosed, in accordance with RFC 3668.
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
This document suggests a way for implementing a IGMP/MLD proxy-
reporting switch in which reports received from downstream hosts
and queries received from upstream routers are used to build the
Subscription Aggregation table. Subscription Aggregation table can
be used for forwarding multicast data traffic, sending state change
and current state reports to upstream router ports.
1. Introduction
This memo assumes familiarity with the IGMP/MLD proxy and snooping
switches. A IGMP/MLD proxy-reporting switch acts as a querier for
the downstream hosts and acts as a host for the upstream routers. A
procedure for building the membership record by merging the
downstream subscriptions is described in section 4.1 of current
specification [PROXY]. Each time the subscription changes on any
downstream port, the merging rules are to be applied on every
downstream subscription for that multicast address to build the
membership record. This method involves a significant overhead. In
Gupta & Nataraja Expires - January 2005 [Page 1]
INTERNET-DRAFT proxy-reporting-implementation July 2004
addition, the specification [PROXY] does not describe a method for
building the multicast forwarding table.
This document introduces a new table called the Subscription
Aggregation Table which can be used as the multicast forwarding
table for forwarding MDPs (Multicast Data Packets). The table can
also be used for sending state change and current state records to
upstream router ports. The mechanism described here will reduce the
overhead involved in forwarding MDPs and building the upstream state
change records whenever there is a change in subscription on any
downstream port. Deployment scenarios for proxy-reporting switch are
the same as mentioned in [PROXY].
MLD mixed version proxying as specified in [MIXED-PROXYING] can be
achieved using proxy-reporting switches. Another advantage of proxy-
reporting switches over snooping switches which do not implement
proxy-reporting function is that the reports will not be forwarded
on upstream router ports if the forwarding state of the switch for a
particular (S,G)/(*,G) is not changing. This will significantly
reduce the number of reports sent upstream.
2. Terminology
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].
2.1 Pseudocode Notation
We use set notation at several places in this specification.
"A+B" is the union of sets A and B
"A*B" is the intersection of sets A and B
"A-B" is the removal of all elements of set B from set A
NULL is empty set or list
C like syntax:
= Denotes assignment of a variable.
== denotes a comparison for equality
!= denotes comparison for inequality
&& denotes logical AND operation
3. Proxy-reporting switch considerations
The proxy-reporting switch SHOULD follow the recommendations listed
in section 2 of [SNOOPING]. To achieve the proxy-reporting
functionality, the following changes MUST be made in the IGMP
Forwarding rules described in section 2.1.1 of [SNOOPING]-
Gupta, Nataraja Expires - January 2005 [Page 2]
INTERNET-DRAFT proxy-reporting-implementation July 2004
1) A Proxy-reporting switch MUST not forward IGMP Membership Reports
on any ports. If IGMPv1/v2 membership reports are forwarded on the
ports on which routers are attached, as referred in section 2.1.1
of [SNOOPING], the router will go to lower version compatibility
mode for the multicast address for which report has been
forwarded.
2) Queries from ports on which routers are attached MUST not be
forwarded on ports on which hosts are attached.
3) The Proxy-reporting switch should perform the router portion of
IGMP/MLD on each of its downstream host port independently, and a
single host portion of IGMP/MLD on all of its upstream router
ports. The administrative control SHOULD be provided for
configuring the IGMP/MLD version of a port.
4. Subscription Aggregation Table (SAT)
The Subscription Aggregation Table consists of group record entries.
Associated with each group record (G), is a forwarding group port
list and a set of source records. Each source record has a
forwarding source port list. The group port list is used for
forwarding MDPs when the source is not found in the set of source
records present for that group. When the source is present, then the
source port list of that source record is used for forwarding. As
mentioned in [PROXY], if the proxy-reporting switch is a non-querier
on a downstream port connected to Multi-access LAN, MDPs must not be
forwarded even if the port is present in the forwarding GPL/SPL. In
addition, the MDPs MUST be forwarded on all router ports too as
specified in [SNOOPING].
The format of the group and source records is shown below:
Group Record (G):
o Group address (G)
o Group port list (GPL)
o Source record set
Source Record (S):
o Source Address (S)
o Source port list (SPL)
4.1 Handling reports from Hosts connected on downstream ports
Whenever a report is received from a host, it is processed as
described in section 6.4 of [RFC 3376] for IGMP and section 7.4 of
[MLDv2] for MLD. Table 1 summarizes the changes in the multicast
Gupta, Nataraja Expires - January 2005 [Page 3]
INTERNET-DRAFT proxy-reporting-implementation July 2004
address state and the actions taken upon receipt of state change and
current state records. For building the Subscription Aggregation
table, appropriate actions are taken depending upon the type of
report received for a particular group on a particular port. Please
refer to [RFC 3376] for notations and definitions used in Table 1.
+-----------+--------------------------------------------------+
| Report | PORT GROUP RECORD STATE |
| Received +-------------------------+------------------------+
| | INCLUDE(A) | EXCLUDE(X, Y) |
+-----------+-------------------------+------------------------+
| | | |
| ALLOW(B) | INCLUDE(A+B) | EXCLUDE(X+B, Y-B) |
| | (B) = MALI | (B) = MALI |
| | IncludeAdd(B) | ExcludeAdd (Y*B) |
+-----------+-------------------------+------------------------+
| | INCLUDE (A) | EXCLUDE(X + (B-Y), Y) |
| BLOCK(B) | SEND Q(MA, A*B) | (B-X-Y) = Filter Timer |
| | | Send Q (MA, B-Y) |
+-----------+-------------------------+------------------------+
| | EXCLUDE(A*B, B-A) | EXCLUDE (B-Y, Y*B) |
| | (B-A) = 0 | (B-X-Y) = Filter Timer |
| TO_EX(B) | Delete(A-B) | Delete(X-B) |
| | Send Q (MA, A*B) | Delete(Y-B) |
| | Filter Timer = MALI | Send Q(MA, B-Y) |
| | IncludeToExclude (A, B) | Filter Timer=MALI |
| | | ExcludeAdd(Y-B) |
+-----------+-------------------------+------------------------+
| | | |
| | EXCLUDE(A*B, B-A) | EXCLUDE (B-Y, Y*B) |
| IS_EX(B) | (B-A) = 0 | (B-X-Y) = MALI |
| | Delete(A-B) | Delete(X-B) |
| | Filter Timer = MALI | Delete(Y-B) |
| | IncludeToExclude (A, B) | Filter Timer=MALI |
| | | ExcludeAdd(Y-B) |
+-----------+-------------------------+------------------------+
| | | |
| | INCLUDE(A+B) | EXCLUDE(X+B, Y-B) |
| TO_IN(B) | (B) = MALI | (B) = MALI |
| | Send Q (MA, A-B) | Send Q (MA, X-B) |
| | IncludeAdd(B) | Send Q (MA) |
| | | ExcludeAdd (B) |
+-----------+-------------------------+------------------------+
| | | |
| | INCLUDE(A+B) | EXCLUDE(X+B, Y-B) |
| IS_IN(B) | (B) = MALI | (B) = MALI |
| | IncludeAdd(B) | ExcludeAdd (B) |
+-----------+-------------------------+------------------------+
Gupta, Nataraja Expires - January 2005 [Page 4]
INTERNET-DRAFT proxy-reporting-implementation July 2004
+-----------+-------------------------+------------------------+
| | | |
| SOURCE(S) | INCLUDE (A-S) | EXCLUDE(X-S, Y+S) |
| TIMER | IncludeDelete (S) | ExcludeDelete(S) |
| EXPIRY | | |
+-----------+-------------------------+------------------------+
| Filter | | |
| Timer | Not Valid | INCLUDE(X) |
| Expiry(G) | | IncludeAdd(X) |
| | | |
+-----------+-------------------------+------------------------+
| GROUP | INCLUDE(NULL) | INCLUDE(NULL) |
| RECORD(G) | | |
| DELETED | DeleteGroupRecord() | DeleteGroupRecord() |
| | | |
+-----------+-------------------------+------------------------+
Table 1. Handling Reports and updating Subscription Aggregation
table.
Note that for reasons of compactness the first two parameters
PortNo (P) and GroupAddress (G) passed to APIs are not shown
in Table 1. The variable MALI stands for Multicast Address Listener
Interval, this is similar to GMI (Group Membership Interval) used in
RFC 3376.
The APIs referred in the Table 1 are defined below -
1. IncludeAdd (PortNo(P), GroupAddress(G), SourceList(SL))
a. If (SL != NULL),
i. Create the group record (G) if it is not present.
ii. For all the sources present in SL, create the source
records if not present and copy GPL to SPL.
iii. Add P to the SPL of all source records in SL.
b. If P is found in GPL,
i. Delete P from GPL.
ii. Delete P from the SPL of all the source records except
the sources present in SL.
c. If (GPL == NULL), delete all the source records with NULL
SPL.
d. If (GPL != NULL), delete all the source records with (SPL
== GPL).
e. If((GPL == NULL) && (source record set == NULL), delete
the group record (G).
2. IncludeDelete (PortNo(P), GroupAddress(G), SourceList(SL))
If group record is present,
i. If (SL != NULL), for all the sources present in SL,
1. Delete P from the SPL of source record if it is
present.
2. Do not create the source record if it is not
present.
ii. If (SL == NULL), delete P from SPL of all the source
records present for group record (G).
Gupta, Nataraja Expires - January 2005 [Page 5]
INTERNET-DRAFT proxy-reporting-implementation July 2004
iii. If (GPL == NULL), delete all the source records with
NULL SPL.
iv. If (GPL != NULL), delete all the source records for
which (SPL == GPL).
v. If((GPL == NULL) && (source record set == NULL),
delete the group record (G).
3. ExcludeAdd (PortNo(P), GroupAddress(G), SourceList(SL))
a. Create Group record (G) if not present.
b. Add P to GPL of group record G.
c. For all the sources present in SL,
i. If the source record is present, add the port P to the
SPL.
ii. Delete all the source records with (SPL == GPL).
4. ExcludeDelete (PortNo(P), GroupAddress(G), SourceList(SL))
a. Create Group record (G) if not present.
b. If(SL != NULL), for all the sources present in SL,
i. If the source record is present, delete P from SPL.
ii. If the source record is not present, create the source
record and copy all ports of GPL to SPL except port P.
c. If (P is not present in GPL), add P to the SPL of all the
source records present except the source records present
for the sources in SL.
d. Add P to GPL of group record G.
e. Delete all source records with (SPL == GPL).
f. If((GPL == NULL) && (source record set == NULL), delete
the group record (G).
5. IncludeToExclude (PortNo(P), GroupAddress(G), SourceList1(SL1),
SourceList2(SL2))
a. If ((group record (G) exists) && (SL1 != NULL)), then for
all the sources present in SL1,
If ((count(SPL) == 1)&&(port == P)&&(GPL ==
NULL)),delete P from SPL of source record and
delete the source record
b. Call the API - ExcludeDelete (P, G, (SL2-SL1))
6. DeleteGroupRecord (PortNo(P), GroupAddress(G))
If group record G is present, then
i. Delete P from the SPL of all the source records
present in the group record.
ii. Delete P from GPL.
iii. If((GPL == NULL) && (source record set == NULL),
delete the group record (G).
4.2 Sending triggered state change reports to upstream router ports
Subscription Aggregation Table gets changed as a result of executing
Gupta, Nataraja Expires - January 2005 [Page 6]
INTERNET-DRAFT proxy-reporting-implementation July 2004
the action routines. Switch Group Filter mode is determined by GPL.
When GPL changes from NULL to NON-NULL, Switch Group Filter mode
changes from INCLUDE to EXCLUDE. When GPL changes from NON-NULL to
NULL, the Switch Group Filter mode changes from EXCLUDE to INCLUDE.
Table 2 summarizes the state change reports that MUST be triggered
based on the changes in the SAT. The appropriate reports SHOULD be
triggered only after performing the actions described in Table 1 and
should also follow the rules described in section 5.1 of [RFC 3376]
for IGMP and section 6.1 of [MLDv2] for MLD.
+-----------------------------+-------------------------------------+
| |Switch Group Filter mode |
| +-------------------+--- -----------+
| Events | EXCLUDE MODE | INCLUDE MODE |
| | (GPL != NULL) | (GPL == NULL) |
| | | |
+-----------------------------+-------------------+-----------------+
| SPL Change (Source S) | | |
| (NULL --> NON-NULL) | ALLOW(S) | ALLOW(S) |
| | | |
| | | |
+-----------------------------+-------------------+-----------------+
| | | |
| SPL Change (Source S) | BLOCK(S) | BLOCK(S) |
| (NON-NULL --> NULL) | | |
| | | |
+-----------------------------+-------------------+-----------------+
| | | |
| | INCLUDE MODE | |
| | TO_IN(A) | |
| Switch Group Filter mode | A = Set of all | NOT VALID |
| change | Sources with | |
| EXCLUDE --> INCLUDE | (SPL != NULL) | |
| | | |
+-----------------------------+-------------------+-----------------+
| | | |
| | | EXCLUDE MODE |
| Switch Group Filter mode | Not Valid | TO_EX(A) |
| change | | |
| INCLUDE --> EXCLUDE | | A = Set of all |
| | | Sources with |
| | | (SPL == NULL) |
| | | |
+-----------------------------+-------------------+-----------------+
Table 2. Sending state change reports to Upstream Router ports.
4.3 Sending reports in response to queries from Upstream Router ports
Proxy-reporting switch performs the host portion of IGMP on router
Gupta, Nataraja Expires - January 2005 [Page 7]
INTERNET-DRAFT proxy-reporting-implementation July 2004
ports. It reports its own state in response to the General query,
Multicast address specific query and Multicast Address and Source
specific query. The rules for constructing the report message are
specified below -
1 If (GPL == NULL), the filter mode of group record G is INCLUDE.
2 If (GPL != NULL), the filter mode of group record is EXCLUDE.
3 If the filter mode of group record G is INCLUDE,
a. IS_IN (X) report is send in response to a Group Specific
query where X denotes all the sources present in the source
record set of group record G.
b. In response to a Multicast address and Source Specific query,
when the filter mode is INCLUDE, IS_IN (S) is send only when
source S is present in the source record set of group record
G.
4 If the filter mode of group record G is EXCLUDE,
a. IS_EX (X) report is send in response to a group specific
query where X denotes all the sources present with NULL SPL
in the source record set of group record G.
b. In response to a Multicast address and Source Specific query,
IS_EX (S) is send only when source S is present with NULL SPL
in the source record set of group record G.
5 An Implementation MAY reduce the state in the upstream routers by
not providing the source specific information in the report
messages.
5. IPv6 Considerations
In the case of IPv6, there are few exceptions which are covered in
section 3 of [SNOOPING].
6. References
6.1 Normative References
[SNOOPING] M.Christensen, K.Kimball, F.Solensky,
"considerations for IGMP and MLD Snooping
switches", draft-ieft-magma-snoop-11.txt, May
2004.
[PROXY] Fenner, B. et al, "IGMP/MLD-based Multicast
Forwarding (IGMP/MLD Proxying)", draft-ietf-
magma-igmp-proxy-06.txt, April 2004.
[MIXED-PROXYING] Haixiang, Brain, Hal, "IGMP Mixed Version
Proxying", draft-he-mixed-igmp-proxy-
00.txt, February 2001.
[RFC 3376] Cain, B., S. Deering, B. Fenner, I. Kouvelas
and A. Thyagarajan, "Internet Group Management
Protocol, Version 3", RFC 3376, October 2002.
Gupta, Nataraja Expires - January 2005 [Page 8]
INTERNET-DRAFT proxy-reporting-implementation July 2004
[RFC 2236] Fenner, W., "Internet Group Management
Protocol, Version 2", RFC 2236, Xerox PARC,
November 1997.
[MLDv2] Vida, R., Costa and L., Fdida, "Multicast
Listener Discovery Version 2 (MLDv2) for IPv6",
RFC 3810, June 2004.
[RFC 2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", RFC 2119/BCP 14,
Harvard University, March 1997.
7. Security Considerations
This document does not cause extra security problems. The security
considerations specified in [SNOOPING], [PROXY] and [MIXED-PROXYING]
apply here.
8. Acknowledgements
The current specifications [PROXY], [SNOOPING] and [RFC 3376]
provided the basis for the implementation described in this document.
We would like to thank Sivakumar A and Raja K for comments and
suggestions on this document.
Authors Addresses
Girish Kumar Gupta
Future Software
480-481 Anna Salai
Nandanam, Chennai-600 035
India.
Email: girishkg@future.futsoft.com
Rajesh Babu Nataraja
Email: rnataraja@riverstonenet.com
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is
subject to the rights, licenses and restrictions contained in
BCP 78, and except as set forth therein, the authors retain all
their rights."
Gupta, Nataraja Expires - January 2005 [Page 9]
INTERNET-DRAFT proxy-reporting-implementation July 2004
"This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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."
Gupta, Nataraja Expires - January 2005 [Page 10]
