[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02

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


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