MBONED Working Group J. Vijayananda Internet-Draft P. Jhingran Intended status: Standards Track Huawei Technologies Expires: December 27, 2007 J. Chennamangalam Raman Research Institute K. Agarwal Infinera June 25, 2007 Internet Group Management Protocol (IGMP)/ Multicast Listener Discovery (MLD) Proxy Upstream Interface Learning draft-vijay-mboned-igmpproxy-upstream-learning-00 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 December 27, 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 December 27, 2007 [Page 1] Internet-Draft IGMP/MLD Proxy Upstream Learning June 2007 achieved by listening for IGMP/MLD General Query messages on the interfaces of the proxy device. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Conventions Used in This Document . . . . . . . . . . . . . . 3 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Handling a General Query Message . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . 11 6. Alarm Handling . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Consequences for Data Forwarding . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 12.1. Normative References . . . . . . . . . . . . . . . . . . . 13 12.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Vijayananda, et al. Expires December 27, 2007 [Page 2] Internet-Draft IGMP/MLD Proxy Upstream Learning June 2007 1. Introduction IGMP/MLD proxying [RFC4605] 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 new interface as the upstream. This usually happens when IGMP/MLD proxying is implemented in a 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. Definitions The terms "upstream interface", "downstream interface" and "membership database" are defined in [RFC4605]. The terms "General Query", "Robustness Variable", and "Query Response Interval" are defined in [RFC3376] and [RFC3810]. The term "Membership Report" is defined in [RFC3376] and "Multicast Listener Done" is defined in [RFC3810]. 3. 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 [RFC2119]. 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. Vijayananda, et al. Expires December 27, 2007 [Page 3] Internet-Draft IGMP/MLD Proxy Upstream Learning June 2007 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 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, may 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, a "multiple- querier" alarm SHOULD be raised, which would notify the network administrator about the abnormality. If, in the converged state, the upstream querier becomes silent, the single interface in the list of upstream interfaces will be aged out when the corresponding monitoring timer expires. This situation, in which there is no active upstream querier and hence no interface in the list of upstream interfaces, is an error condition, and a "no- querier" alarm SHOULD be raised to alert the network administrator of its occurrence. The behaviour of the proxy device does not involve forwarding Query messages received on one upstream interface to other upstream interfaces. This negates the occurrence of Querier Election. Multicast Router Discovery [RFC4286] is usually used when Query Vijayananda, et al. Expires December 27, 2007 [Page 4] Internet-Draft IGMP/MLD Proxy Upstream Learning June 2007 suppression due to Querier Election causes non-detection of IGMP/MLD routers. In the case of IGMP/MLD Proxy Upstream Interface Learning, Multicast Router Advertisement messages MAY be processed in addition to Query messages, and if the processing is done, it SHOULD be similar to Query processing as described in this section. 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. 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. Figure 1 describes this algorithm. Vijayananda, et al. Expires December 27, 2007 [Page 5] Internet-Draft IGMP/MLD Proxy Upstream Learning June 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 | +----------+ Figure 1 Vijayananda, et al. Expires December 27, 2007 [Page 6] Internet-Draft IGMP/MLD Proxy Upstream Learning June 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, stop sending General Query messages on the downstream interfaces, and raise the no- querier alarm. Go to Step 6. Step 4. If the list contains more than one interface, go to Step 6, else continue. Step 5. Stop the multiple-querier-detection timer, set the convergence flag, and start sending General Query messages on the downstream interfaces. Step 6. End of routine. Figure 2 describes this algorithm. Vijayananda, et al. Expires December 27, 2007 [Page 7] Internet-Draft IGMP/MLD Proxy Upstream Learning June 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 |raise no-querier| | +------------+ | | alarm | | | +----------------+ | Do nothing | +----------+-----------+ |Stop multiple-querier-| | detection timer | +----------+-----------+ | | +-------+-------+ |Set flag, start| |sending Queries| | on downstream | +---------------+ Figure 2 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 the multiple-querier alarm to notify the network administrator. Vijayananda, et al. Expires December 27, 2007 [Page 8] Internet-Draft IGMP/MLD Proxy Upstream Learning June 2007 Step 3. Restart the multiple-querier-detection timer. Step 4. End of routine. 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 [RFC3376] or [RFC3810], 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 [RFC3376] or [RFC3810], as applicable. Step 2. If no more hosts are interested in the relevant membership, send the Membership Report (IGMPv2 Leave [RFC2236] or Multicast Listener Done [RFC2710]) 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. Vijayananda, et al. Expires December 27, 2007 [Page 9] Internet-Draft IGMP/MLD Proxy Upstream Learning June 2007 Step 3. Flood the General Query message on all interfaces except the converged upstream interface. Step 4. End of routine. Figure 3 describes this algorithm. +------------+ _____|Has learning|_______ Y | | converged? | | N | +------------+ | | | +--------+--------+ +----------+----------+ | Flood Queries | | Flood Queries | |on all interfaces| | on all interfaces | |except converged | |except most-recently-| | upstream | | learnt upstream | +-----------------+ +---------------------+ Figure 3 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. Vijayananda, et al. Expires December 27, 2007 [Page 10] Internet-Draft IGMP/MLD Proxy Upstream Learning June 2007 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, the multiple- querier alarm is raised to notify the network administrator of multiple queriers in the network. 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, the multiple-querier 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. Vijayananda, et al. Expires December 27, 2007 [Page 11] Internet-Draft IGMP/MLD Proxy Upstream Learning June 2007 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 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 the multiple-querier 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 Dengbo, Janardhan D. Kulkarni, Muhammad Yaaseen, Sumit Kumar, Sanjeew Kumar, Aravind M. Kulkarni, and Geethmala S. for their valuable comments and suggestions on this document. Vijayananda, et al. Expires December 27, 2007 [Page 12] Internet-Draft IGMP/MLD Proxy Upstream Learning June 2007 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", RFC 4286, December 2005. 12.2. Informative References [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997. [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. Authors' Addresses Vijayananda J. Huawei Technologies Level 1, Anjaneya Techno Park 147, Airport Road Bangalore, Karnataka 560 008 IN Phone: +91 80 4111 7676 Email: vijayanandaj@huawei.com Vijayananda, et al. Expires December 27, 2007 [Page 13] Internet-Draft IGMP/MLD Proxy Upstream Learning June 2007 Prashant Jhingran Huawei Technologies Level 1, Anjaneya Techno Park 147, Airport Road Bangalore, Karnataka 560 008 IN Phone: +91 80 4111 7676 Email: prashantj@huawei.com Jayanth Chennamangalam Raman Research Institute C. V. Raman Avenue Sadashivanagar Bangalore, Karnataka 560 080 IN Phone: +91 80 2361 0122 Email: jayanth@rri.res.in URI: http://www.rri.res.in/~jayanth Krishna Agarwal Infinera Level 4, Prestige Solitaire 401, Brunton Road Bangalore, Karnataka 560 001 IN Phone: +91 80 2532 1402 Email: kagarwal@infinera.com Vijayananda, et al. Expires December 27, 2007 [Page 14] Internet-Draft IGMP/MLD Proxy Upstream Learning June 2007 Full 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. 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. Intellectual Property 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. Acknowledgments Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). This document was produced using xml2rfc v1.32 (of http://xml.resource.org/) from a source in RFC-2629 XML format. Vijayananda, et al. Expires December 27, 2007 [Page 15]