OSPF Working Group Zengjie Kou
Internet Draft Feng Yang
Expires: June 2006 Lu Feng
Huawei
Technologies,
December 2005
draft-kou-ospf-immediately-replying-hello-00.txt
Update to OSPF Hello procedure
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 June 26, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).All Rights Reserved.
Abstract
This memo documents an extension of the OSPF protocol to reach
¡°ExStart¡± state more quickly. Currently, the OSPF behavior requires
the Hello Packet to be sent between the neighbors every
HelloInterval. This document proposes to generalize the use of
Immediately Replying Hello which could reduce the time required to
reach the OSPF ¡°ExStart¡± state and expedite the routing table
convergence.
Kou , Yang & Feng [Page 1]
Internet Draft Update to OSPF Hello procedure December 2005
Table of Contents
1 Introduction...............................................2
2 Motivation.................................................2
3. Potential Solution.........................................3
4 Proposed Solution: Immediately Replying Hello..............3
5 Immediately Replying Hello.................................4
6 Description of the Revised protocol behavior...............4
6.1 Modifications to Sending Hello packets.....................4
6.1 Modifications to Sending Hello packets.....................4
6.1.1 Modification to section 9.5 of [OSPFV2]....................4
6.1.2 Modification to section 9.5.1 of [OSPFV2]..................5
6.2 Modifications to Electing the Designated Router............6
6.3 Modifications to The Neighbor State Machine................6
7 Benefit....................................................7
A. Immediately Replying Hello Experiment Report...............7
A.1 Broadcast networks.........................................8
A.1.1 No BDR on Broadcast........................................8
A.1.1.1 DUT is DR..................................................8
A.1.1.2 DUT is DROther.............................................9
A.1.2 Existing BDR on Broadcast..................................9
A.1.2.1 DUT is DR.................................................10
A.1.2.2 DUT is BDR................................................11
A.1.2.3 DUT is DROther............................................12
A.1.3 N routers (n>=2) Exist on Broadcast Ethernet..............12
A.2 Point to Point networks .............................13
Security Considerations...................................13
Acknowledgments...........................................14
Normative References......................................14
Author Addresses..........................................14
Full Copyright Statement..................................14
1. Introduction
Currently£¬the time for OSPF routers to reach the ¡°ExStart¡± state
depends on the OSPF HelloInterval. To reach the ¡°ExStart¡± state as
soon as possible, one of approach is to shorten HelloInterval.
This document specifies another method that can be applied to
significantly reduce the time to reach the ¡°ExStart¡± state. With
this method, a router will immediately reply a Hello Packet to its
peer when receiving a neighbor¡¯s Hello Packet. The ¡°ExStart¡± state
and mechanism of OSPF Hello is described in [OSPFV2].
2. Motivation
According to [Pierre Franc¡¯s paper], the IGP convergence can be
characterized as D + O + F + SPT + RIB + DD where D is the link
failure detection time, O is the time to originate the LSA describing
the new topology after the link failure, F is the complete flooding
Kou , Yang & Feng [Page 2]
Internet Draft Update to OSPF Hello procedure December 2005
time from the node detecting the failure (i.e. Failure node) to the
rerouting nodes that must perform a FIB update to bring the network
in a consistent forwarding state, SPT is the shortest-path tree
computation time, RIB is the time to update the RIB and the FIB on
the main CPU and DD is the time to distribute the FIB updates to the
linecards in the case of a distributed router architecture.
The F can be considered as the time of neighbor recovery when a failed
OSPF link is recovered (e.g. Interface down/up). In OSPF, the recovery
time is equal to the sum of the time to reach the ¡°ExStart¡± state and
LSDB synchronization time. on broadcast and NBMA networks, the time
to reach the¡°ExStart¡± state is approximate equal to the Waiting time
and, on P2P, P2MP and Virtual Link networks, the time to reach the
¡° ExStart¡± state is approximate equal to the time to reach the ¡°2-Way¡±
state. Generally, it takes 1 to 2 seconds for 10,000 LSAs to be
synchronized. OSPF default HelloInterval is 10 seconds. On broadcast
networks (e.g. Ethernet), the Waiting time is approximate 40 seconds,
i.e. 4 times of HelloInterval. On P2P networks (e.g. POS),the time to
reach the ¡°2-Way¡±state is approximate the HelloInterval (10s).Namely,
the time to reach the ¡°2-Way¡± state or the Waiting time accounts for
80%-95% of the total recovery time.
Therefore, if a technique could reach the OSPF¡°ExStart¡± state £¨the
time to reach the ¡°2-Way¡± state or Waiting time£© more quickly and
at the same time it would not increase the traffic and burden of
the router CPU, it will reduce the convergence time remarkably. In
particular, if a router interface attached to OSPF networks goes
down and then up, the recovery time will be much shorter than past.
The experiment showing the improvement on the recovery time is
described in appendix A.
3. Potential Solution
Fast Hello is a mechanism that achieves the intention, but it
increases OSPF Hello traffic significantly. It is also not fit for
all kinds of routers, for example, link bandwidth is constrained or
CPU capability is limited.
4. Proposed Solution: Immediately Replying Hello
Immediately Replying Hello is the mechanism that an OSPF router
replies to its peer as soon as it receives the Hello Packet if needed,
which can reach the ¡°ExStart¡± state quickly without increasing the
OSPF packet traffic which brings heavy burden to CPU. This technique
Kou , Yang & Feng [Page 3]
Internet Draft Update to OSPF Hello procedure December 2005
can make ¡°ExStart¡± state to be reached quickly, however it does not
speed up the neighbor failure detection.
5. Immediately Replying Hello
Immediately Replying Hello is described as follow:
1£©After a router whose neighbor state is less than ¡°2-Way¡± received
a Hello Packet from the neighbor, it SHOULD send a Hello Packet
immediately to this neighbor rather than waiting for Hello Timer to
expire. Hello sending is described in 6.1.
2£©After a Hello Packet from a neighbor is processed, and if the
router neighbor state changes from "2-Way" or greater into "Init",
it SHOULD immediately send Hello Packet back to the neighbor. Hello
sending is described in 6.1.
3£©After DR is elected, the router whose interface state changed
SHOULD send Hello Packet immediately to notify other routers of the
change about BDR and DR on networks. Hello sending is described in
6.1.
A few additional Hello Packets are brought by Immediately Replying
Hello, but will be clear away when the neighbor state reaches the
¡°2-Way¡± state. The mechanism is independent of OSPF LSDB size. It
only reduces the time of OSPF neighbor state reaching ¡°ExStart¡±.
6. Description of the Revised protocol behavior
Immediately Replying Hello has some changes in current standard.
6.1 Modifications to Sending Hello packets
The sending Hello Packets as it exists in section 9.5 of [OSPFV2]
remains Unchanged except for the action associated with condition of
sending Hello Packet. To incorporate the Immediately Replying Hello
in [OSPFV2] this action is changed to the following.
6.1.1 Modification to section 9.5 of [OSPFV2]
The segment 5 to section 9.5 of [OSPFV2] will be replaced by the
following.
On broadcast networks,
o Hello packets are sent every HelloInterval seconds to the IP
multicast address AllSPFRouters.
Kou , Yang & Feng [Page 4]
Internet Draft Update to OSPF Hello procedure December 2005
o The Hello Packet of the Immediately Replying Hello is replied
respectively to each neighbor address in case of 1) or 2) in section
5.
o The Hello Packets of the Immediately Replying Hello are sent to the
IP multicast address AllSPFRouters in order to notify other routers of
the change about BDR and DR on networks when a router interface state
changed in case of 3) in section 5.
On physical point-to-point networks, Hello packets are sent every
HelloInterval seconds to the IP multicast address AllSPFRouters.
The Hello Packets of the Immediately Replying Hello are sent to the
IP multicast address AllSPFRouters in case of 1) or 2) in section 5.
On virtual links, Hello packets are sent as unicasts (addressed
directly to the other end of the virtual link) every HelloInterval
seconds. The Hello Packets of the Immediately Replying Hello are sent
as unicasts in case of 1) or 2) in section 5. The behavior of this
mechanism on Sham-link, is same to virtual link.
On Point-to-MultiPoint networks, separate Hello packets are sent to
each attached neighbor every HelloInterval seconds. The Hello Packets
of the Immediately Replying Hello are sent to the IP multicast address
AllSPFRouters in case of 1) or 2) in section 5.
6.1.2 Modification to section 9.5.1 of [OSPFV2]
The segment 3 to section 9.5.1 of [OSPFV2] will be replaced by the
following.
If the router is eligible to become Designated Router, it must
periodically send Hello Packets to all neighbors that are also eligible.
It SHOULD also send an Hello Packet in reply to an Hello Packet received
from any eligible neighbor in case of 1) or 2) in section 5. In
addition, if the router is itself the Designated Router or Backup
Designated Router, it must also send periodic Hello Packets to all other
neighbors. This means that any two eligible routers are always exchanging
Hello Packets, which is necessary for the correct operation of the
Designated Router election algorithm. To minimize the number of Hello
Packets sent, the number of eligible routers on an NBMA network should be
kept small.
6.2 Modifications to Electing the Designated Router
The election of Designated Router as it exists in section 9.4 of [OSPFV2]
remains unchanged except for the step (7). To incorporate the Immediately
Replying Hello in [OSPFV2] ,step (7) is changed to the following.
(7) If the above calculations have caused the identity of either the
Designated Router or Backup Designated Router to change, the set of
adjacencies associated with this interface will need to be modified.
The router whose interface state changes SHOULD send hello packet
Kou , Yang & Feng [Page 5]
Internet Draft Update to OSPF Hello procedure December 2005
immediately to notify other routers of the change about BDR or DR on
networks (Hello sending is described in 6.1). Some adjacencies may need
to be formed, and others may need to be broken. To accomplish this,
invoke the event AdjOK? on all neighbors whose state is at least 2-Way.
This will cause their eligibility for adjacency to be reexamined.
6£®3 Modifications To The Neighbor State Machine
The state machine as it exists in section 10.3 of [OSPFV2]
remains unchanged except for the action associated with State: Init,
Event: 2-WayReceived and State 2-Way or greater, Event: 1-WayReceived.
To incorporate Immediately Replying Hello in [OSPFV2] this
action is changed to the following.
State(s): Init
Event: 2-WayReceived
New state: Depends upon action routine.
Action: Determine whether an adjacency should be established
with the neighbor (see Section 10.4 of [OSPFV2]). If
not, the new neighbor state is 2-Way and it SHOULD
send Hello Packet immediately back to the neighbor.
Otherwise (an adjacency should be established) the
neighbor state transitions to ExStart. Upon
entering this state, the router increments the DD
sequence number in the neighbor data structure. If
this is the first time that an adjacency has been
attempted, the DD sequence number should be assigned
some unique value (like the time of day clock). It
then declares itself master (sets the master/slave
bit to master), and starts sending Database
Description Packets, with the initialize (I), more
(M) and master (MS) bits set. This Database
Description Packet should be otherwise empty. This
Database Description Packet should be retransmitted
at intervals of RxmtInterval until the next state is
entered (see Section 10.8 of [OSPFV2]). Hello sending
is described in 6.1.
State(s): 2-Way or greater
Event: 1-WayReceived
Kou , Yang & Feng [Page 6]
Internet Draft Update to OSPF Hello procedure December 2005
New state: Init
Action: The Link state retransmission list, Database summary
list and Link state request list are cleared of LSAs.
Hello packets are sent immediately to the neighbor
leading to the Event. Hello sending is described in
6.1.
7. Benefit
On P2P, P2MP, Sham-link and virtual links networks, the time to reach
the ¡°ExStart¡± state is reduced to sub-second by Immediately Replying
Hello.
On broadcast and NBMA networks, the time to reach the ¡°ExStart¡± state
is reduced to sub-second by Immediately Replying Hello when DR or BDR
exists.
Appendix A. Immediately Replying Hello Experiment Report
The method of experiment is described as follow:
o DUT(device-under-test) interface goes down and up.
o The following list is the time to reach the ¡°Full¡± state since the
DUT interface goes up. The experiment is repeated five times for each
condition.
o The networks delay(from line-card to master-card) is not considered.
o The unit is millisecond.
o The HelloInterval is 10 seconds.
o No routing entry is imported on the experiment. So LSDB synchronization
time is 0 on the case and the recovery time is equal to the time to reach
the ¡°ExStart¡± state.
Kou , Yang & Feng [Page 7]
Internet Draft Update to OSPF Hello procedure December 2005
A.1 Broadcast networks
A.1.1 No BDR on Broadcast networks
+---+ +---+
|DUT| |RTA|
+---+ +---+
| ETH |
+----------------------+
| ETH |
+---+ +---+
|RTB| |RTC|
+---+ +---+
Figure 1: Topology of broadcast networks
A.1.1.1 DUT is DR
Topology description:
o Networks is Ethernet.
o Boxes are connected as Figure 1.
o DUT is DR.
The time for DUT to reach the¡°Full¡± state with others is described
as follow:
+-----------+---------+------+------+------+------+------+
| without | with RTA|44222 |42483 |44781 |43844 |42078 |
| +---------+------+------+------+------+------+
| the | with RTB|44225 |42486 |44787 |43841 |42070 |
| +---------+------+------+------+------+------+
| method | with RTC|44221 |42485 |44791 |43840 |42079 |
+-----------+---------+------+------+------+------+------+
| with | with RTA|43328 |41406 |40016 |40156 |40922 |
| +---------+------+------+------+------+------+
| the | with RTB|43321 |41406 |40020 |40110 |40912 |
| +---------+------+------+------+------+------+
| method | with RTC|43323 |41408 |40036 |40159 |40905 |
+-----------+---------+------+-------+-------+-------+---+
Table 1. DUT recovery time on broadcast networks
Analysis:
The recovery time = the time to reach the ¡°ExStart¡± state + LSDB
synchronization time.
The time to reach the ¡°ExStart¡± state = Waiting time(40s).
LSDB synchronization time = 0.
Kou , Yang & Feng [Page 8]
Internet Draft Update to OSPF Hello procedure December 2005
When DUT interface goes up, DR will be reelected because no BDR exists.
The Waiting time can not be avoided, therefore the effect of this
technique is not obvious.
A.1.1.2 DUT is DROther
Topology description:
o Networks is Ethernet.
o Boxes are connected as Figure 1.
o RTA is DR.
The time for DUT to reach ¡°Full¡± state with others is described
as follow:
+-------------------------------+-------+-------+-------+-------+-------+
|without the method (with RTA) |11951 |11283 |14561 |5803 |6687 |
+-------------------------------+-------+-------+-------+-------+-------+
|with the method (with RTA) |156 |140 |141 |156 |157 |
+-------------------------------+-------+-------+-------+-------+-------+
Table 2. DUT recovery time on broadcast networks
Analysis:
The recovery time = the time to reach the ¡°ExStart¡± state + LSDB
synchronization time.
LSDB synchronization time = 0.
The time to reach ¡°ExStart¡± state is equal to the time to reach
¡°2-Way¡± because DR is not changed without the Immediately Replying
Hello.
If DUT interface goes up, the time to reach ¡°2-Way¡±state consists
mostly of expiration time of Hello Timer. It is approximate HelloInterval
(10s). However, the time to reach ¡°2-Way¡±state is very short with the
Immediately Replying Hello. Accordingly, the recovery time is shorter.
A.1.2 BDR Exists on Broadcast
+---+ +---+
|DUT| |RTA|
+---+ +---+
| ETH |
+----------------------+
| ETH |
+---+ +---+
|RTB| |RTC|
+---+ +---+
Figure 2: Topology on Broadcast networks
Kou , Yang & Feng [Page 9]
Internet Draft Update to OSPF Hello procedure December 2005
A.1.2.1 DUT is DR
Topology description:
o Networks is Ethernet.
o Boxes are connected as Figure 2.
o DUT is DR,RTA is BDR
The time for DUT to reach the ¡°Full¡± state with others is described
as follow:
+-------------------+----------+-------+-------+-------+-------+-------+
| |with RTA |10032 |14453 |14125 |10656 |15922 |
| +----------+-------+-------+-------+-------+-------+
|without the method |with RTB |6235 |14516 |9750 |11031 |12500 |
| +----------+-------+-------+-------+-------+-------+
| |with RTC |10236 |14513 |9751 |11038 |12520 |
+-------------------+----------+-------+-------+-------+-------+-------+
| |with RTA |500 |328 |469 |235 |515 |
| +----------+-------+-------+-------+-------+-------+
|with the method |with RTB |500 |328 |469 |204 |515 |
| +----------+-------+-------+-------+-------+-------+
| |with RTC |500 |328 |469 |206 |515 |
+-------------------+----------+-------+-------+-------+-------+-------+
Table 3. DUT recovery time on broadcast networks
Analysis:
The recovery time = the time to reach the ¡°ExStart¡± state + LSDB
synchronization time.
LSDB synchronization time = 0.
The time to reach the ¡°ExStart¡± state is equal to BackupSeen time
because DR is changed and BDR will become DR.
If DUT interface goes up, the time to reach the ¡°2-Way¡±state consists
mostly of expiration time of BackupSeen. It is approximate HelloInterval
(10s). However, the time to reach ¡°2-Way¡±state is very short with the
Immediately Replying Hello. Accordingly, the recovery time is shorter.
Kou , Yang & Feng [Page 10]
Internet Draft Update to OSPF Hello procedure December 2005
A.1.2.2 DUT is BDR
Topology description:
o Networks is Ethernet.
o Boxes are connected as Figure 2.
o DUT is BDR,RTA is DR
The time for DUT to reach the¡°Full¡± state with others is described
as follow:
+---------------------+---------+-------+-------+-------+-------+-------+
| |with RTA |8375 | 14563 |16000 |14016 |12610 |
| +---------+-------+-------+-------+-------+-------+
|without the method |with RTB |7969 |14500 |6547 |11032 |7016 |
| +---------+-------+-------+-------+-------+-------+
| |with RTC |7961 |14509 |6547 |11002 |7010 |
+---------------------+---------+-------+-------+-------+-------+-------+
| |with RTA |250 |187 |235 |204 |172 |
| +---------+-------+-------+-------+-------+-------+
|with the method |with RTB |250 |187 |235 |204 |172 |
| +---------+-------+-------+-------+-------+-------+
| |with RTC |250 |187 |235 |204 |172 |
+---------------------+---------+-------+-------+-------+-------+-------+
Table 4. DUT recovery time on broadcast networks
Analysis:
The recovery time = the time to reach the ¡°ExStart¡± state + LSDB
synchronization time.
LSDB synchronization time = 0.
The time to reach ¡°ExStart¡± state is equal to the time to reach
¡°2-Way¡± state because DR is not changed.
If DUT interface goes up, the time to reach ¡°2-Way¡±state consists
mostly of expiration time of BackupSeen. It is approximate
HelloInterval (10s). However, the time to reach ¡°2-Way¡±state is
very short with the Immediately Replying Hello. Accordingly, the
recovery time is shorter.
Kou , Yang & Feng [Page 11]
Internet Draft Update to OSPF Hello procedure December 2005
A.1.2.3 DUT is DROther
Topology description:
o Networks is Ethernet.
o Boxes are connected as Figure 2.
o DUT is DROther,RTA is DR,RTB is BDR.
The time for DUT to reach the ¡°Full¡± state with others is described
as follow:
+--------------------+----------+-------+-------+-------+-------+-------+
| |with RTA |18219 |12625 |9328 |14375 |10235 |
|without the method +----------+-------+-------+-------+-------+-------+
| |with RTB |18219 |12313 |9891 |14781 |10454 |
+-------------------------------+-------+-------+-------+-------+-------+
| |with RTA |141 |156 |172 |172 |156 |
|with the method +----------+-------+-------+-------+-------+-------+
| |with RTB |141 |156 |172 |172 |156 |
+--------------------+----------+-------+-------+-------+-------+-------+
Table 5. DUT recovery time on broadcast networks
Analysis:
The recovery time = the time to reach the ¡°ExStart¡± state + LSDB
synchronization time.
LSDB synchronization time = 0.
The time to reach the ¡°ExStart¡± state is equal to the time to reach
the ¡°2-Way¡± state because DR is not changed.
if DUT interface goes up, the time to reach ¡°2-Way¡±state consists
mostly of expiration time of Hello Timer. It is approximate
HelloInterval (10s). However, the time to reach ¡°2-Way¡±state is
very short with the Immediately Replying Hello. Accordingly, the
recovery time is shorter.
A.1.3 N routers (n>=2) Exist on Broadcast Ethernet
Immediately Replying Hello is used to reduce the time to reach the
¡°ExStart¡± state. It is independent of the number of OSPF router.
So the result of A.1 is generalized to other condition on
multi-access networks.
Kou , Yang & Feng [Page 12]
Internet Draft Update to OSPF Hello procedure December 2005
A.2 Point to Point networks
+---+ +---+
|DUT|-----------------------|RTA|
+---+ +---+
Figure 3: P2P networks
Topology description:
o Networks is PoS.
o Boxes are connected as Figure 3.
The time for DUT to reach ¡°Full¡± state with others is described
as follow:
+---------------------+-------+-------+-------+-------+-------+
|without the method |10062 |15797 |10938 |15703 |10547 |
+---------------------+-------+-------+-------+-------+-------+
|with the method |94 |109 |93 |141 |109 |
+---------------------+-------+-------+-------+-------+-------+
Table 6. DUT recovery time on P2P networks
Analysis:
The recovery time = the time to reach the ¡°ExStart¡± state + LSDB
synchronization time.
The time to reach the¡°ExStart¡± state = the time to reach the
¡°2-Way¡± state.
LSDB synchronization time = 0.
if DUT interface goes up , the time to reach ¡°2-Way¡±state consists
mostly of expiration time of Hello Timer. The time is approximate
HelloInterval (10s). However, the time to reach the ¡°2-way¡± state
is very quick with the Immediately Replying Hello. So, the recovery
time is shorter.
Security Considerations
This memo does not create any new security issues for the OSPF protocol.
Security considerations for base OSPF protocol are covered in [OSPFV2].
Kou , Yang & Feng [Page 13]
Internet Draft Update to OSPF Hello procedure December 2005
Acknowledgments
The author would like to thank Renhai Zhang, Xiaoyi Guo, Acee Lindem and
Lixia Zhang for their helpful comments on this work.
Normative References
[OSPFV2] Moy ,J. "OSPF Version 2", STD 54, RFC 2328, April 1998.
[Pierre Franc¡¯s paper] July'05 issue of ACM Computer Communication Review
¡°Achieving sub-second IGP convergence in large IP networks¡±.
Author Addresses
Zengjie Kou
Huawei technology
kouzengjie@huawei.com
Feng Yang
Huawei technology
feng.yang@huawei.com
Lu Feng
Huawei technology
hifenglu@huawei.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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 translations of it MAY be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation MAY be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself MAY not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
Kou , Yang & Feng [Page 14]
Internet Draft Update to OSPF Hello procedure December 2005
copyrights defined in the Internet Standards process MUST be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
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 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.
Kou , Yang & Feng [Page 15]
Internet Draft Update to OSPF Hello procedure December 2005