Network working group X. XU Internet Draft Huawei Category: Informational Expires: February 2010 August 14, 2009 PIM-SM DR Priority Auto-Adjustment draft-xu-pim-drpriority-auto-adjustment-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 Feburary 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Xu. Expires February 14, 2010 [Page 1] Internet-Draft PIM-SM DR Priority Auto-Adjustment August 2009 Abstract This document defines a mechanism for automatically adjusting the Protocol Independent Multicast (PIM) Designed Router (DR) priority according to the status of the tracked interface. This approach can be used to realize DR auto-switchover in case the current DR loses the routes to multicast senders or Rendezvous Points (RP). 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]. Table of Contents 1. Problem Statement..............................................3 2. DR Priority Auto-adjustment Mechanism..........................4 3. Security Considerations........................................5 4. IANA Considerations............................................5 5. Acknowledgments................................................5 6. References.....................................................5 6.1. Normative References......................................5 6.2. Informative References....................................5 Authors' Addresses................................................6 Xu. Expires February 14, 2010 [Page 2] Internet-Draft PIM-SM DR Priority Auto-Adjustment August 2009 1. Problem Statement In the Protocol Independent Multicast - Sparse Mode (PIM-SM) specification [RFC4601], a Designated Routers (DR) plays a very important role, e.g., the multicast receiver's DR sends PIM join/prune messages upon receiving Internet Group Management Protocol (IGMP) [RFC3376] membership report/leave messages from multicast receivers, or the multicast sender' DR sends PIM Register packets to a Rendezvous Point (RP) on behalf of the multicast senders. To achieve DR redundancy, multiple PIM routers are usually deployed in a shared-media LAN like Ethernet. As depicted in the following figure, two PIM routers R1, R2 are connected to the same LAN where a multicast receiver is located. Assume R1 is elected as the DR for that LAN. Now R1's upstream link to the outside network is down, as a result, R1 will lose the reachability to the multicast senders and RPs. If R1 doesn't quit the DR role, the multicast service for the receiver will be broken even though R2 is still available. | +-----+ +------------------+ +---+ R1 +----+ | | +-----+ | | +--------+ | | | +-------+ |Receiver+---+ | Outside Network +--+Sender | +--------+ | | (Run PIM-SM) | +-------+ | +-----+ | | +---+ R2 +----+ | | +-----+ +------------------+ In most cases, the recovery of the multicast forwarding tree can be fully dependent on the unicast route convergence. However, in the above scenario, there is usually no Interior Gateway Protocol (IGP) running between R1 and R2, and even IGP was ran, their interfaces are usually set to silent mode due to some issues, e.g., the possible route spoofing by malicious hosts, or the side-effect of route flooding on hosts. Somebody may argue that a failover static route can be configured on these two routers instead of running IGP. That's to say, each PIM router is configured with a default route with its next-hop pointed to the opposite side, and this default route will not take effect until the reachability to the outside network is lost. However, this approach has a few side-effects. Assume these two routers are connected to the same Internet Service Provider (ISP) network via different links, once the default route learnt from the ISP is withdrawn, the forwarding loop will occur between them when received Xu. Expires February 14, 2010 [Page 3] Internet-Draft PIM-SM DR Priority Auto-Adjustment August 2009 a packet whose best route is the configured default route. Another side-effect with this approach is: when the upstream link to the outside network recovers (from down to up), the RPF interface will change. As a result, the transient forwarding interruption due to SPT/RPT rebuilding will occur. Although this transient interruption issue due to unicast route change can be alleviated by using some make-before-break mechanism (e.g., by borrowing some ideas from RPT- >SPT switch mechanism, the old upstream link will not be pruned until the stream is received from the new upstream link.), the cost is relatively high for this scenario. 2. DR Priority Auto-adjustment Mechanism A PIM router could exactly cease the DR role by decreasing its DR priority once it loses routes to the RPs or multicast sources. Since the addresses of the RPs or the multicast sources may not be known to it, the PIM router could simply determine whether or not it has lost the route to the RPs or multicast sources just by tracking the status of its upstream link. This approach is much similar to interface tracking mechanism of the Virtual Router Redundancy Protocol (VRRP) [RFC2338]. Taken the above scenario as an example, R1 will track its upstream link to the outside network, once the upstream link is down, its PIM DR priority will be reduced automatically so as to cease the DR role. As a result, R2 will take over the DR role. To speed up the DR switchover further, as soon as the DR priority adjustment occurs, a new hello message containing the current DR priority will be triggered. In most cases, two last-hop routers each with an upstream link are enough for redundancy purpose. In case there are more than one upstream links on a PIM router, all of these interfaces should be tracked. As long as there is a route to the outside network, it is not necessary for the DR switchover to take place. Once the failed upstream link on R1 recovers (from down to up), its DR priority can be either recovered or not according to the pre- configured preemption policy. For example, if preemption is not allowed, its DR priority will remain unchanged so as to avoid DR switchover. As a result, the transient multicast forwarding interruption due to multicast forwarding tree rebuilding will not occur. Note that this approach is fully compatible with the current PIM specification. There is no need to change the PIM protocol on wire at all since it's just an internal implementation optimization. Although the PIM router could cease the DR role by declaring its death directly, e.g., sending a hello message with a zero holdtime, Xu. Expires February 14, 2010 [Page 4] Internet-Draft PIM-SM DR Priority Auto-Adjustment August 2009 or keeping silent till it times out, these approaches have a few limitations in some specific scenarios. Still taken the above scenario as an example, assume there is another multicast sender directly connected to R1 via another interface. Since the receiver and this sender are connected to the same PIM router, the receiver ought to be able to receive the multicast stream from this sender. However, in case there is another multicast source in the outside network using the same address (i.e., in anycast source scenario), a problem due to PIM assert failure will occur since join/prune or assert messages from a non-neighbor will be discarded silently according to the PIM specification. 3. Security Considerations The DR priority auto-adjustment mechanism described in this document does not introduce any new security risk. 4. IANA Considerations There is no IANA consideration for this document. 5. Acknowledgments The author would like to thank Liu Hui, Prashant Jhingran, Srimanikandan Ganesan and Rajiv Asati for their valuable comments. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.2. Informative References [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC2338] Knight, S., et. al., "Virtual Router Redundancy Protocol", RFC 2338, April 1998. Xu. Expires February 14, 2010 [Page 5] Internet-Draft PIM-SM DR Priority Auto-Adjustment August 2009 Authors' Addresses Xiaohu Xu Huawei Technologies, No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085, P.R. China Phone: +86 10 82836073 Email: xuxh@huawei.com Xu. Expires February 14, 2010 [Page 6]