Internet Draft Internet Engineering Task Force Yunzhou Li INTERNET-DRAFT Billy Ng Nortel Networks 23 June 1999 PIM Neighbor Hello GenID Option <draft-ietf-pim-hello-genid-01.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 memo addresses an issue with the current PIM in Sparse Mode. In the case of router reboot, PIM networks have to converge slowly and suffer long outage of traffic flows. This memo proposes a Generation Identifier (GenID) Option in PIM Hello messages. It enables neighbors to quickly detect router reboot and thus to synchronize RP-Set information and forwarding states by triggering Bootstrap and Join/Prune messages to the rebooted router. The rebooted router then is able to quickly recover from the reboot. PIM-DM also benefits by using this GenID to reduce join latency. Refer to section 6 of PIM-DM specification ([PIM-DM]). Li, Ng Expires 22 December 1999 [Page i] Internet Draft PIM Neighbor Hello GenID Option 23 June 1999 1. Introduction The current default PIM Hello interval is 30 seconds and its holdtime is 105 seconds. If a neighbor is rebooted within this holdtime, all other neighbors on the LAN will not be able to detect this transition. Thus, in the case of PIM Sparse Mode, the rebooted neighbor will take longer to learn its RP-Set information causing longer outage of traffic flows through this neighbor. In the worst case, the rebooted neighbor was the elected BSR or a Candidate BSR in which case the BSR election process will take place unnecessarily even if its configuration stay the same. In particular, if the DR for a source network is rebooted, other routers on the same network will not transit to be a new DR. The DR will not forward any data packets until it learns RP-Set information 60 seconds later (in the worst case). In the case of an upstream router reboot where there is no alternative path towards the RP, in the worst case, the rebooted router has to take 60 seconds to learn RP-Set information, and then to take 60 seconds to receive Join/Prune from downstream neighbors. As a result, downstream members will suffer 120 second outage of traffic flows. We propose a GenID option in the PIM Hello message. A GenID is randomly selected when the router boots and remains the same as long as the router is up. By including this GenID as an option in the Hello packet, a neighbor reboot can easily be detected if its GenID is different from before. When such an event happens, the DR on the LAN unicasts its most recent RP-Set information to the rebooted neighbor. If the rebooted neighbor was the DR, the next highest ip address (or the next highest DR priority if this option is enabled) neighbor will unicast the information. 2. Generation Identifier Option The GenID is a 32-bit unsigned number. This number is randomly assigned when the router boots up and remains the same for the router's up time. This is usually taken from the milli-second portion of the router's wall clock. A router may intentionally regenerate a new GenID in order to synchronize its RP-set information and forwarding states with its neighboring routers. If no GenID option is specified in a Hello message, the Hello sender is deemed not capable of handling the GenID option. When such a hello message is received, the receiver will just treat it as zero. This way new systems can interoperate with older systems in the old way. Li, Ng Expires 22 December 1999 [Page 1] Internet Draft PIM Neighbor Hello GenID Option 23 June 1999 The GenID received in a Hello is kept until the next Hello from the the same system arrives. The newly received GenID replaces the cached GenID for the same neighbor if its GenID has changed. An implementation capable of doing this option should always include it in the Hellos even if no GenID option is explicitly configured. The following is the format of this option. OptionType: 20 OptionLength: 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionType = 20 | OptionLength = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ | GenID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GenID: 32-bit GenID value 3. Triggering Hello Message In order to minimize delay, a Hello message should immediately be sent upon boot up. After learning a new GenID from a neighbor, a router should unicast a Hello message to the neighbor after a random delay. This is to trigger the neighbor to establish neighborship with all routers as soon as possible. 4. Triggering Behaviours in PIM-SM After learning a new GenID from a neighbor, if it determines itself is the DR (or the next available DR if the neighbor was the DR), the router should unicast a Bootstrap message to the neighbor after sending the above Hello message. Aside, for each forwarding state with the neighbor as the upstream, the router should subsequently send Join/Prune messages to this neighbor. 5. Triggering Behaviors in PIM-DM See section 6 of PIM-DM specification ([PIM-DM]). 6. Security Considerations Security issues are discussed in detail in ``Authenticating PIM Version 2 Messages'' ([PIMAU]). 7. Acknowledgments Many thanks to Brad Cain, Hal Sandick and Liming Wei for their valuable comments. Li, Ng Expires 22 December 1999 [Page 2] Internet Draft PIM Neighbor Hello GenID Option 23 June 1999 6. References [PIM-SM] D. Estrin et al, Protocol Independent Multicast Sparse-Mode (PIM-SM): Protocol Specification. RFC 2362, June 1998. [PIM-DM] S. Deering et al, Protocol Independent Multicast Version 2 Dense Mode Specification. Internet Draft, work in progress, May 1999. [PIMAU] L. Wei, Authenticating PIM Version 2 Messages. Internet Draft, work in progress, November 1998. Authors' Addresses Yunzhou Li Nortel Networks BL60-304 600 Technology Park Drive Billerica, MA 01821 Phone: 1-978-916-1130 Fax: 1-978-670-8760 E-mail: yunli@NortelNetworks.COM Billy Ng Nortel Networks BL60-304 600 Technology Park Drive Billerica, MA 01821 Phone: 1-978-916-8412 Fax: 1-978-670-8760 E-mail: bng@NortelNetworks.COM Li, Ng Expires 22 December 1999 [Page 3]