Network Working Group T. Morin Internet-Draft France Telecom - Orange Labs Intended status: Standards Track November 3, 2008 Expires: May 7, 2009 Fast Hello exchange procedures for Protocol Independent Multicast draft-morin-pim-fast-hello-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 May 7, 2009. Abstract This document is proposed as an update of RFC4601 and describes procedures allowing exchanges of PIM Hellos to complete earlier when a new link comes up, to mitigate the multicast traffic blackholing issues that result from inconsistencies between links advertised by unicast routing and the links on which PIM adjacencies are fully set up. Requirements Language 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]. Morin Expires May 7, 2009 [Page 1] Internet-Draft PIM Fast Hello exchange November 2008 1. Introduction PIM-SM specifications [RFC4601] section 4.3.1 implies that : o when a link comes up, a Hello message is sent by a router after a random delay in the [0,Triggered_Hello_Delay] range (Triggered_Hello_Delay being 5s by default), or at once if there are Join messages that need to be send on this link ; o and that on reception of a Hello from a new neighbor a router will send a Hello after a random delay in the same range. With these procedures, there is a risk of having a link be considered up by unicast routing before PIM Join/Prune messages can be exchanged on this link. In this case, the nodes that are downstream to such a link may update their RPF and send Join messages in the direction of the new link, before the node adjacent to the new link is ready to send the Join on that link. The result is a temporary blackholing of multicast traffic which can persist for at least up to Triggered_Hello_Delay. The procedures and timers defined in [RFC4601] are conservative and meant to avoid storms of Hello messages on multiaccess links. This document propose more aggressive timers for point-to-point links, new procedures for fast hello exchanges on multiaccess links, and propose corresponding adjustments related to when Join messages are sent after a link comes up. 2. Hello exchange on a point-to-point link If a link is known to be a point-to-point link (e.g. based on the underlying link layer in use, or based on local configuration), then a router SHOULD set the Triggered_hello_delay to zero on this link. The result is that, on a point-to-point link: o on reception of a Hello from a new neighbor, a router will send a Hello at once o even in the absence of any Join/Prune/Assert message that would need to be sent, a router will send a Hello at once 3. Hello exchange on a multiaccess link The goal is to allow a faster exchange of Hello messages, while preserving the behavior of REF in that the risk of overloading the Morin Expires May 7, 2009 [Page 2] Internet-Draft PIM Fast Hello exchange November 2008 router control plane with processing of a large amount of Hello message in a short period. Without introducing random delays before Hello are sent, when a multiaccess link comes up there would be a possibility to have all routers send a Hello at the same time, then resulting all routers replying at the same time (2*n messages in a very short time). The proposed modifications to RFC4601 are that: o implementations SHOULD provide a tuning knob to change the value of Triggered_Hello_Delay on an interface -- this allows the operator to choose a timer value lower than the current default, when the number of routers on the link is such that the effects of a surge of PIM Hello messages are considered reasonable o implementations SHOULD implement the following "unicast Hello" procedures: * when a Join/Prune/Assert message needs to be sent to a router that is not already a PIM neighbor, the router MAY send a Hello message at once, using unicast toward the neighbor ; the timer for sending a normal PIM Hello based on RFC164601 procedures is preserved * when a unicast Hello is received from a router that is not already a PIM neighbor , the router MUST send at once a Hello, using unicast to the sender of the Hello ; the timer for sending a normal PIM Hello based on RFC164601 procedures is preserved 4. Sending Joins Current PIM specifications [RFC4601] indicate that a router that need to send a Join, Prune or Assert message to a neighbor will send a Hello message at once, but it is not indicated if it should wait for reception of a Hello from that router before sending the said Join messages. It is also indicated that Join messages should not be sent to a router from which no PIM Hello has been received yet, so implicitly the interpretation is that the router should wait. Current PIM specifications [RFC4601] also indicate that "[a router] will not accept Join/Prune or Assert messages from a router unless they have first heard a Hello message from that router". However, widespread implementations do not enforce these verifications and allow sending Join/Prune/Assert to (and process Join/Prune/Assert to) router from which no Hello has been received Morin Expires May 7, 2009 [Page 3] Internet-Draft PIM Fast Hello exchange November 2008 yet, providing as a result a form of mitigation of blackholing issues. The following rules are proposed to make explicit the rules on how messages are sent right after a link comes up. When Prune/Join/Assert messages need to be sent on a point-to-point link to a router from which a Hello message has not been sent yet (call it router A): o a Hello message is sent at once, and a timer T is set to a low value (e.g. 100ms, the same value as the Prune override delay can be used) o the messages are queued, and sent on the link when the first of these two events occur: * a Hello is received from A * T expires o if messages were sent because T expired, the timers associated to the states corresponding to the messages should be set so that these messages will be repeated at once when, eventually, a Hello message is received from A 5. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 6. Security Considerations 7. Acknowledgements Acknowledgments goes to Bill Fenner, Mark Handley and Dino Farinacci, with whom these proposals were extensively discussed and who suggested some key ideas. 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Morin Expires May 7, 2009 [Page 4] Internet-Draft PIM Fast Hello exchange November 2008 Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. Author's Address Thomas Morin France Telecom - Orange Labs 2, avenue Pierre Marzin Lannion 22307 France Email: thomas.morin@orange-ftgroup.com Morin Expires May 7, 2009 [Page 5] Internet-Draft PIM Fast Hello exchange November 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. Morin Expires May 7, 2009 [Page 6]