MAGMA Working Group J. Vijayananda INTERNET-DRAFT J. Chennamangalam Expires: September 2007 Huawei Technologies March 13, 2007 Internet Group Management Protocol (IGMP)/ Multicast Listener Discovery (MLD) Proxy Upstream Interface Learning draft-vijay-magma-igmpproxy-upstream-intf-learning-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 This Internet-Draft will expire on September 13, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document specifies a mechanism for the dynamic determination of the upstream interface of a device running IGMP/MLD Proxy, as opposed to manual configuration. The learning of the upstream interface is Vijayananda, et al Expires September 13, 2007 [Page 1] Internet-Draft IGMP/MLD Proxy Upstream Interface Learning March 2007 achieved by listening for IGMP/MLD General Query messages on the interfaces of the proxy device. Conventions Used in this Document 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 [KEYWORDS]. Table of Contents 1. Introduction...................................................2 2. Contributors...................................................3 3. Definitions....................................................3 4. Protocol Details...............................................3 4.1. Handling a General Query Message..........................4 4.2. Monitoring Timer Expiry Handling..........................7 4.3. Multiple-Querier-Detection Timer Expiry Handling..........8 4.4. Handling Multicast Group Subscription.....................9 4.5. Handling Multicast Group Unsubscription...................9 4.6. Sending General Query Messages on the Downstream..........9 5. Timers........................................................10 5.1. Monitoring Timer.........................................10 5.2. Multiple-Querier-Detection Timer.........................10 6. Alarm Handling................................................11 7. Consequences for Data Forwarding..............................11 8. Security Considerations.......................................12 9. IANA Considerations...........................................12 10. Conclusions..................................................12 11. Acknowledgments..............................................12 12. References...................................................12 12.1. Normative References....................................12 12.2. Informative References..................................13 Authors' Addresses...............................................14 Intellectual Property Statement..................................15 Disclaimer of Validity...........................................15 1. Introduction IGMP/MLD proxying [IGMPPROXY] is a method by which a device (the "proxy device") learns and proxies group membership information, and forwards multicast data based upon that information. IGMP/MLD proxying works only in a simple tree topology in which the upstream interface is determined by manual configuration. In the case of a topology change, if the upstream interface of the proxy device changes, the network administrator has to configure the Vijayananda, et al Expires September 13, 2007 [Page 2] Internet-Draft IGMP/MLD Proxy Upstream Interface Learning March 2007 new interface as the upstream. This usually happens when IGMP/MLD proxying is implemented on a Layer 3 switch. In this case, the tree topology is usually built by Spanning Tree Protocol. The upstream interface of the proxy device may change due to a link state change, when Spanning Tree Protocol recomputes the tree. Then the network administrator will have to reconfigure the upstream interface. This document describes a mechanism by which the upstream interface is determined dynamically, as opposed to being manually configured. 2. Contributors Krishna Agarwal (Infinera) and Prashant Jhingran (Huawei Technologies) contributed to the conceptualisation of IGMP/MLD Proxy Upstream Interface Learning. 3. Definitions The terms "upstream interface", "downstream interface" and "membership database" are defined in [IGMPPROXY]. The terms "General Query", "Robustness Variable", and "Query Response Interval" are defined in [IGMPV3] and [MLDV2]. The term "Membership Report" is defined in [IGMPV3] and "Multicast Listener Done" is defined in [MLDV2]. 4. Protocol Details The mechanism for learning the upstream interface of the proxy device is based on the device listening to IGMP/MLD General Query messages on its interfaces. The interface on which the proxy device receives a General Query message is considered to be the upstream interface. This implies that in a given instant, the proxy device may have more than one upstream interface. The proxy device runs a learning algorithm which ages out all interfaces except one, which is the actual upstream interface. The proxy device maintains a list of upstream interfaces. As and when an interface receives a General Query message, that interface is added to this list. For each interface in the upstream interfaces list, a "monitoring" timer is started. The period of the monitoring timer is given in Section 5.1. of this document. For an interface on which General Query messages are continuously being received, the monitoring timer would always be running. This means that each reception of a General Query message on a particular interface triggers the restarting of the timer. During the upstream interface transition, General Query messages will stop being received on the original upstream interface, so the monitoring timer for that Vijayananda, et al Expires September 13, 2007 [Page 3] Internet-Draft IGMP/MLD Proxy Upstream Interface Learning March 2007 interface will stop getting restarted. When the monitoring timer expires, the interface will be removed from the list of upstream interfaces. Since the new upstream interface keeps on receiving General Query messages, the corresponding monitoring timer never expires, and it remains in the list of upstream interfaces. The state when only one interface is present in the list of upstream interfaces is termed "convergence". The upstream interface learning is successful when convergence happens. The convergence status is marked by a "convergence flag", which is set when the system converges on to one interface, and reset otherwise. In some cases, due to erroneous connection or configuration, General Query messages may be continuously received on more than one interface. This situation, if persisting for long, would result in the malfunctioning of multicast data forwarding. The network administrator has to be alerted about such a situation. For this purpose, another timer, the "multiple-querier-detection" timer, is used. The multiple-querier- detection timer is started when the second interface is added to the list of upstream interfaces. The value of the multiple-querier- detection timer interval is given in Section 5.2. of this document. When the multiple-querier-detection timer expires, if there is more than one interface in the list of upstream interfaces, an alarm SHOULD be raised, which would notify the network administrator about the abnormality. The following sub-sections describe the behaviour of IGMP/MLD Proxy Upstream Interface Learning in more detail. 4.1. Handling a General Query Message This sub-section describes the algorithm to handle the reception of a General Query message. Step 1. Search the list of upstream interfaces for the interface on which the General Query was received. If the interface is not found (it is a new interface), continue, else go to Step 8. Step 2. Add the interface to the list of upstream interfaces. If the number of interfaces in this list has become 1, continue, else go to Step 4. Step 3. Set the convergence flag, respond to the General Query, and start sending General Query messages on the downstream interfaces. Go to Step 7. Vijayananda, et al Expires September 13, 2007 [Page 4] Internet-Draft IGMP/MLD Proxy Upstream Interface Learning March 2007 Step 4. If, with the newly-added interface, the number of interfaces in the list of upstream interfaces has become 2, continue, else go to Step 7. Step 5. Reset the convergence flag, and respond to the General Query on the interface on which it was received. Step 6. Start the multiple-querier-detection timer. Step 7. Start the monitoring timer. Go to Step 9. Step 8. Respond to the General Query message on the interface on which it was received, and restart the monitoring timer corresponding to that interface. Step 9. End of routine. The following diagram describes this algorithm. Vijayananda, et al Expires September 13, 2007 [Page 5] Internet-Draft IGMP/MLD Proxy Upstream Interface Learning March 2007 General Query received on an interface | | +-------+--------+ _______| Is interface |________ Y | |present in list?| | N | +----------------+ | | | +----+-----+ +------+-------+ |Respond to| |Add it to list| | Query | +------+-------+ +----+-----+ | | +-----+------+ +----+-----+ |Is number of| | Restart | +------+ interfaces +-------+ |monitoring| Y | |in list = 1?| | N | timer | | +------------+ | +----------+ | | +----------+-----------+ +-----+------+ | Set flag, respond to | |Is number of| |Query, send Queries on| +---+ interfaces +---+ | downstream | Y | |in list = 2?| | N +----------+-----------+ | +-----+------+ | | | | | +-------+--------+ | | | Reset flag, | | | |respond to Query| | | +-------+--------+ | | | | | +-----------+-----------+ | | |Start multiple-querier-| | | | detection timer | | | +-----------+-----------+ | | | | +-----------------+--------------------+ | +----+-----+ | Start | |monitoring| | timer | +----------+ Vijayananda, et al Expires September 13, 2007 [Page 6] Internet-Draft IGMP/MLD Proxy Upstream Interface Learning March 2007 4.2. Monitoring Timer Expiry Handling This sub-section describes the handling of the monitoring timer expiry. Step 1. Remove the interface corresponding to the expired timer from the list of upstream interfaces. Step 2. If the list is not empty, go to Step 4, else continue. Step 3. Reset the convergence flag, and stop sending General Query messages on the downstream interfaces. Go to Step 6. Step 4. If the list contains more than one interface, go to Step 6, else continue. Step 5. Set the convergence flag, and start sending General Query messages on the downstream interfaces. Step 6. End of routine. The following diagram describes this algorithm. Vijayananda, et al Expires September 13, 2007 [Page 7] Internet-Draft IGMP/MLD Proxy Upstream Interface Learning March 2007 Monitoring timer expired | | +-------+--------+ |Remove interface| | from list | +-------+--------+ | +------+-------+ +---+Is list empty?+---+ Y | +--------------+ | N | | +-------+--------+ +------+-----+ |Reset flag, stop| |Is number of| |sending Queries | +---+ interfaces +---+ | on downstream | Y | |in list = 1?| | N +----------------+ | +------------+ | | | +----------+-----------+ Do nothing |Stop multiple-querier-| | detection timer | +----------+-----------+ | | +-------+-------+ |Set flag, start| |sending Queries| | on downstream | +---------------+ 4.3. Multiple-Querier-Detection Timer Expiry Handling This sub-section describes the handling of the multiple-querier- detection timer expiry. Step 1. If the list of upstream interfaces contains more than one interface, continue, else go to Step 4. Step 2. Raise an alarm to notify the network administrator. Step 3. Restart the multiple-querier-detection timer. Step 4. End of routine. Vijayananda, et al Expires September 13, 2007 [Page 8] Internet-Draft IGMP/MLD Proxy Upstream Interface Learning March 2007 4.4. Handling Multicast Group Subscription This sub-section describes the handling of multicast group subscription on a downstream interface. Step 1. Add the membership information present in the IGMP/MLD Membership Report message to the membership database in accordance with [IGMPV3] or [MLDV2], as applicable. Step 2. Send the Membership Report message on all the interfaces present in the list of upstream interfaces. Step 3. End of routine. 4.5. Handling Multicast Group Unsubscription This sub-section describes the handling of multicast group unsubscription on a downstream interface. Step 1. Delete the membership information from the membership database in accordance with [IGMPV3] or [MLDV2], as applicable. Step 2. If no more hosts are interested in the relevant membership, send the Membership Report (IGMPv2 Leave [IGMPV2] or Multicast Listener Done [MLDV1]]) message on all the interfaces present in the list of upstream interfaces. Step 3. End of routine. 4.6. Sending General Query Messages on the Downstream This sub-section describes the sending of General Query messages on the downstream interfaces of the proxy device. Step 1. If the upstream interface learning has converged, go to Step 3, else continue. Step 2. Flood the General Query message on all interfaces except the most-recently-learnt upstream interface. Go to Step 4. Step 3. Flood the General Query message on all interfaces except the converged upstream interface. Step 4. End of routine. The following diagram describes this algorithm. Vijayananda, et al Expires September 13, 2007 [Page 9] Internet-Draft IGMP/MLD Proxy Upstream Interface Learning March 2007 +------------+ _____|Has learning|_______ Y | | converged? | | N | +------------+ | | | +--------+--------+ +----------+----------+ | Flood Queries | | Flood Queries | |on all interfaces| | on all interfaces | |except converged | |except most-recently-| | upstream | | learnt upstream | +-----------------+ +---------------------+ 5. Timers The timers used in IGMP/MLD Proxy Upstream Interface Learning are described in detail below. 5.1. Monitoring Timer The monitoring timer is started for each interface in the list of upstream interfaces. It monitors its corresponding interface for General Query messages. Each reception of a General Query message triggers the restarting of the timer. The value of the timer is tied to the values of Robustness Variable, Query Interval, and Query Response Interval. Monitoring timeout = (Robustness Variable * Query Interval) + (Query Response Interval / 2) Substituting the default values of the IGMP/MLD protocol timers and counters, the default value of the monitoring timer is 255 seconds. This value can be configured indirectly, by configuring the relevant IGMP/MLD protocol variables. 5.2. Multiple-Querier-Detection Timer The multiple-querier-detection timer is started when the second interface is added to the list of upstream interfaces. When this timer expires, the number of interfaces in the list of upstream interfaces is calculated, and if it is more than 1, an alarm is raised to notify the network administrator of multiple queriers in the network. Vijayananda, et al Expires September 13, 2007 [Page 10] Internet-Draft IGMP/MLD Proxy Upstream Interface Learning March 2007 Multiple-querier-detection timeout = (Robustness Variable * Query Interval) + (Query Response Interval) Substituting the default values of the IGMP/MLD protocol timers and counters, the default value of the multiple-querier-detection timer is 260 seconds. This value can be configured by configuring the relevant IGMP/MLD protocol variables. The value of the multiple-querier-detection timeout is defined to be more than that of the monitoring timeout. This is done to prevent the multiple-querier-detection timer and the monitoring timer for the second interface timing out simultaneously. Consider the case where there are only two interfaces in the list of upstream interfaces. When the second of the two interfaces was added to the list, in addition to its monitoring timer, the multiple-querier-detection timer is also started. When simultaneous timing out happens, if the latter timer's expiry is handled first, there would still be two interfaces in the list of upstream interfaces, and this would cause the alarm to be raised, when in fact, the second interface would be aged out right after the multiple-querier-detection timer's expiry. 6. Alarm Handling At the expiry of the multiple-querier-detection timer, if there is more than one interface in the list of upstream interfaces, an alarm SHOULD be raised to notify the network administrator of the abnormality. The nature of the alarm and the way it should be handled are outside the scope of this document. By way of a suggestion, it would be helpful if the alarm event/message contained the list of upstream interfaces, as this would allow the network administrator to locate the problem easily. The network administrator may physically change the topology, or reconfigure the interfaces, so that only one interface will receive the General Query messages from the upstream network. The administrator may also reset the IGMP/MLD proxy system, so that the list of upstream interfaces is flushed. After raising the alarm, the multiple-querier-detection timer SHOULD be restarted. It may cause multiple alarms to be raised in succession, but it ensures that the alarm event/message is not missed by the network administrator. 7. Consequences for Data Forwarding The consequences of considering multiple interfaces as upstream interfaces is dependent on the way the data forwarding is implemented, and is outside the scope of this document. In the ideal Vijayananda, et al Expires September 13, 2007 [Page 11] Internet-Draft IGMP/MLD Proxy Upstream Interface Learning March 2007 case, when the upstream switches from one interface to another, there will not be any significant disruption to data forwarding. 8. Security Considerations The IGMP/MLD Proxy Upstream Interface Learning provides limited protection against attacks. An attacker on a downstream interface can keep sending General Query messages, and get the membership information present in the proxy device, besides wasting the processing power of the proxy device. The multiple-querier-detection timer, on expiry, SHOULD raise an alarm which would notify the network administrator about the abnormality. 9. IANA Considerations This document has no actions for IANA. 10. Conclusions IGMP/MLD Proxy Upstream Interface Learning can prevent manual intervention in the determination of the upstream interface on a proxy device. In the case of a change in the upstream interface, the new interface can be detected automatically and data forwarding can be realised without manual configuration. 11. Acknowledgments The authors would like to thank Muhammad Yaaseen, Sumit Kumar, Sanjeew Kumar, and Aravind M. Kulkarni for their valuable comments and suggestions on this document. This document was prepared using 2-Word-v2.0.template.dot. 12. References 12.1. Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [IGMPPROXY] Fenner, B., He, H., Haberman, B., and Sandick, H., "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ('IGMP/MLD Proxying')", RFC 4605, August 2006. Vijayananda, et al Expires September 13, 2007 [Page 12] Internet-Draft IGMP/MLD Proxy Upstream Interface Learning March 2007 [IGMPV3] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and Thyagarajan, A., "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [MLDV2] Vida, R. and Costa, L. (Editors), "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 12.2. Informative References [IGMPV2] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997. [MLDV1] Deering, S., Fenner, W., and Haberman, B., "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. Vijayananda, et al Expires September 13, 2007 [Page 13] Internet-Draft IGMP/MLD Proxy Upstream Interface Learning March 2007 Authors' Addresses Vijayananda J. Huawei Technologies India Pvt. Ltd. Level 1, Anjaneya Techno Park 147, Airport Road Bangalore, Karnataka India 560008 Phone: +91 80 41117676 E-mail: vijayanandaj@huawei.com Jayanth Chennamangalam Huawei Technologies India Pvt. Ltd. Level 1, Anjaneya Techno Park 147, Airport Road Bangalore, Karnataka India 560008 Phone: +91 80 41117676 E-mail: jayanthc@gmail.com Krishna Agarwal Infinera India Pvt. Ltd. Level 4, Prestige Solitaire 401, Brunton Road Bangalore, Karnataka India 560001 Phone: +91 80 25321402 E-mail: kagarwal@infinera.com Prashant Jhingran Huawei Technologies India Pvt. Ltd. Level 1, Anjaneya Techno Park 147, Airport Road Bangalore, Karnataka India 560008 Phone: +91 80 41117676 E-mail: prashantj@huawei.com Vijayananda, et al Expires September 13, 2007 [Page 14] Internet-Draft IGMP/MLD Proxy Upstream Interface Learning March 2007 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity 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, THE IETF TRUST 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. Copyright Statement Copyright (C) The IETF Trust (2007). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Vijayananda, et al Expires September 13, 2007 [Page 15]