[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 01

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]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/