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 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]