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]