OSPF Working Group Zengjie Kou Internet Draft Feng Yang Expires: August 2007 Huaiyuan Ma January 18, 2007 Update to OSPF Hello procedure draft-kou-ospf-immediately-replying-hello-02.txt 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 August 18, 2007. 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 & Ma Expires August 18, 2007 [Page 1] Internet-Draft Update to OSPF Hello procedure January 2007 Table of Contents 1. Introduction................................................2 2. Motivation..................................................3 3. Potential Solution..........................................4 4. Proposed Solution: Immediately Replying Hello...............4 5. Immediately Replying Hello..................................4 6. Interoperation..............................................5 6.1. Compatibility with [OSPFV2]............................5 6.2. Interoperation within Immediately Replying Hello.......5 7. Description of the Revised protocol behavior................5 7.1. Modifications to Sending Hello packets.................5 7.1.1. Modification to section 9.5 of [OSPFV2]...........6 7.1.2. Modification to section 9.5.1 of [OSPFV2].........7 7.2. Modifications to Electing the Designated Router........7 7.3. Modifications To The Neighbor State Machine............7 8. Benefit.....................................................9 9. Security Considerations.....................................9 10. Acknowledgments............................................9 APPENDIX A: Immediately Replying Hello Experiment Report.......10 A.1. Broadcast networks.....................................10 A.1.1. No BDR on Broadcast networks......................10 A.1.1.1. DUT is DR....................................11 A.1.1.2. DUT is DROther...............................12 A.1.2. BDR Exists on Broadcast...........................13 A.1.2.1. DUT is DR....................................14 A.1.2.2. DUT is BDR...................................15 A.1.2.3. DUT is DROther...............................16 A.1.3. N routers (n>=2) Exist on Broadcast Ethernet......18 A.2. Point to Point networks................................18 11. References.................................................19 11.1. Normative References..................................19 11.2. Informative References................................19 Author's Addresses.............................................20 Intellectual Property Statement................................20 Disclaimer of Validity.........................................20 Copyright Statement............................................21 Acknowledgment.................................................21 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 Kou , Yang & Ma Expires August 18, 2007 [Page 2] Internet-Draft Update to OSPF Hello procedure January 2007 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 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. Kou , Yang & Ma Expires August 18, 2007 [Page 3] Internet-Draft Update to OSPF Hello procedure January 2007 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 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. On broadcast/NBMA networks, default configuration is set to disable. Immediately Replying Hello automatically boots after DR is elected. Thus, the additional Hello Packets will be avoided. The mechanism has no effect on the size of OSPF LSDB. It only reduces the time of OSPF neighbor state reaching "ExStart". Kou , Yang & Ma Expires August 18, 2007 [Page 4] Internet-Draft Update to OSPF Hello procedure January 2007 6. Interoperation 6.1. Compatibility with [OSPFV2] Immediately Replying Hello process is compliant to [OSPFV2] implementation. It has no effect on [OSPFV2] router. 6.2. Interoperation within Immediately Replying Hello In order to achieve the best effort, the requirements of networks with Immediately Replying Hello are following: On p2p, p2mp and virtual link networks, both routers of a link are required to support Immediately Replying Hello. On broadcast/NBMA networks, all routers are required to support the function in an area. 7. Description of the Revised protocol behavior Immediately Replying Hello has some changes in current standard. 7.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. Kou , Yang & Ma Expires August 18, 2007 [Page 5] Internet-Draft Update to OSPF Hello procedure January 2007 7.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. 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. Kou , Yang & Ma Expires August 18, 2007 [Page 6] Internet-Draft Update to OSPF Hello procedure January 2007 7.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. 7.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 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. 7.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: Kou , Yang & Ma Expires August 18, 2007 [Page 7] Internet-Draft Update to OSPF Hello procedure January 2007 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 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. Kou , Yang & Ma Expires August 18, 2007 [Page 8] Internet-Draft Update to OSPF Hello procedure January 2007 8. 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. 9. 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]. 10. Acknowledgments The author would like to thank Renhai Zhang, Xiaoyi Guo, Acee Lindem and Lixia Zhang for their helpful comments on this work. Kou , Yang & Ma Expires August 18, 2007 [Page 9] Internet-Draft Update to OSPF Hello procedure January 2007 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. A.1. Broadcast networks A.1.1. No BDR on Broadcast networks +---+ +---+ |DUT| |RTA| +---+ +---+ | ETH | +----------------------+ | ETH | +---+ +---+ |RTB| |RTC| +---+ +---+ Kou , Yang & Ma Expires August 18, 2007 [Page 10] Internet-Draft Update to OSPF Hello procedure January 2007 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 Kou , Yang & Ma Expires August 18, 2007 [Page 11] Internet-Draft Update to OSPF Hello procedure January 2007 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. 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 | +-----------------------------+------+------+------+-----+-----+ Kou , Yang & Ma Expires August 18, 2007 [Page 12] Internet-Draft Update to OSPF Hello procedure January 2007 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 theImmediately 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 & Ma Expires August 18, 2007 [Page 13] Internet-Draft Update to OSPF Hello procedure January 2007 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 Kou , Yang & Ma Expires August 18, 2007 [Page 14] Internet-Draft Update to OSPF Hello procedure January 2007 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. 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 | | +--------+------+------+------+------+------+ Kou , Yang & Ma Expires August 18, 2007 [Page 15] Internet-Draft Update to OSPF Hello procedure January 2007 | |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. A.1.2.3. DUT is DROther Topology description: o Networks is Ethernet. o Boxes are connected as Figure 2. Kou , Yang & Ma Expires August 18, 2007 [Page 16] Internet-Draft Update to OSPF Hello procedure January 2007 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 Kou , Yang & Ma Expires August 18, 2007 [Page 17] Internet-Draft Update to OSPF Hello procedure January 2007 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. 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 | +---------------------+-------+-------+-------+-------+-------+ Kou , Yang & Ma Expires August 18, 2007 [Page 18] Internet-Draft Update to OSPF Hello procedure January 2007 |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. 11. References 11.1. Normative References [OSPFV2] Moy ,J. "OSPF Version 2", STD 54, RFC 2328, April 1998. 11.2. Informative References [Pierre Franc's paper] July'05 issue of ACM Computer Communication Review "Achieving sub-second IGP convergence in large IP networks". Kou , Yang & Ma Expires August 18, 2007 [Page 19] Internet-Draft Update to OSPF Hello procedure January 2007 Author's Addresses Zengjie Kou Huawei technology kouzengjie@huawei.com Feng Yang Huawei technology feng.yang@huawei.com Huaiyuan Ma Huawei technology mahuaiyuan@huawei.com Intellectual Property Statement 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. Disclaimer of Validity 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, Kou , Yang & Ma Expires August 18, 2007 [Page 20] Internet-Draft Update to OSPF Hello procedure January 2007 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. Copyright Statement Copyright (C) The Internet Society (2007). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Kou , Yang & Ma Expires August 18, 2007 [Page 21]