Internet DRAFT - draft-ietf-idmr-pim-hello-genid
draft-ietf-idmr-pim-hello-genid
Internet Engineering Task Force Yunzhou Li
INTERNET-DRAFT Nortel Networks
Billy Ng
Nortel Networks
25 February 1999
PIM Neighbor Hello GenId Option
<draft-ietf-idmr-pim-hello-genid-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 except for the right to
produce derivative works.
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."
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the internet-drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), ftp.ietf.org (US East
Coast), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
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.
Li, Ng Expires 24 August 1999 [Page i]
Internet Draft PIM Neighbor Hello GenId Option 25 February 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, 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 router's wall clock
in seconds.
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 24 August 1999 [Page 1]
Internet Draft PIM Neighbor Hello GenId Option 25 February 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. Acknowledgments
Brad Cain and Hal Sandick commented on this draft.
Li, Ng Expires 24 August 1999 [Page 2]
Internet Draft PIM Neighbor Hello GenId Option 25 February 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, 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 24 August 1999 [Page 3]
