Ospf nonstop routing synchronization nack

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of <patcit id="pcit0001" dnum="US61541064A"><text>U.S. Provisional Application No. 61/541,064, filed September 29, 2011</text></patcit> which is hereby incorporated by reference.

Field

Embodiments of the invention relate to the field of computer networking; and more specifically, to synchronization of dynamic Open Shortest Path First (OSPF) data in Nonstop Routing (NSR).

BACKGROUND

A computer network is a geographically distributed collection of interconnected communication links and subnetworks for transporting data between nodes, such as computers. Many types of computer networks are available, with the types ranging from local area networks (LANs) to wide area networks (WANs). A LAN is an example of a subnetwork that provides relatively short distance communication among the interconnected stations, whereas a wide area network enables long distance communication over a larger geographic area using links provided by public or private telecommunications facilities. The nodes typically communicate by exchanging discrete frames or packets of data according to predefined protocols. In this context, a protocol consists of a set of rules defining how the nodes interact with each other.

Computer networks may be further interconnected by an intermediate node, called a router, to extend the effective "size" of each network. Since management of a large system of interconnected computer networks can prove burdensome, smaller groups of computer networks may be maintained as routing domains or autonomous systems. The networks within an autonomous system are typically coupled together by conventional intradomain routers. These routers manage communication among local networks within their domains and communicate with each other using an intradomain routing (or an interior gateway) protocol. An example of such a protocol is the Open Shortest Path First (OSPF) routing protocol described in <nplcit id="ncit0001" npl-type="b"><text>Request for Comments (RFC) 2328, OSPF Version 2, by J. Moy (1998</text></nplcit>). The OSPF protocol is based on link-state technology and, therefore, is hereinafter referred to as a link state routing protocol.

SUMMARY

A network element is configured for synchronizing dynamic open shortest path first (OSPF) data between an active OSPF instance and a backup OSPF instance. The active OSPF instance determines that a first dynamic OSPF data synchronization event has occurred and determines a first set of OSPF synchronization data to synchronize with the backup OSPF instance. The first set of OSPF synchronization data is based on a subset of dynamic OSPF data in the active OSPF instance that needs synchronization to the backup OSPF instance. The active OSPF instance communicates the first set of OSPF synchronization data to the backup OSPF instance. The backup OSPF instance receives the first set of OSPF synchronization data and determines whether a data structure exists in the backup OSPF instance that is required for the synchronization of the subset of dynamic OSPF data. If the data structure exists, the backup OSPF instance adds the subset of dynamic OSPF data to the data structure. If the data structure does not exist, the backup OSPF instance returns a negative acknowledgement (NACK) to the active OSPF instance. The NACK indicates that dynamic OSPF data synchronization failed. Furthermore, the backup OSPF instance clears dynamic OSPF data from the backup OSPF instance. Responsive to receiving the NACK, the active OSPF instance determines that a second dynamic OSPF data synchronization event has occurred. The active OSPF instance then determines a second set of OSPF synchronization data based on dynamic OSPF data in the active OSPF instance and communicates the second set of OSPF synchronization data to the backup OSPF instance.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention may best be understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the invention. In the drawings:

<figref idref="f0001">Figure 1</figref> illustrates an exemplary network that implements OSPF Nonstop Routing (NSR) with synchronization of dynamic OSPF data according to one embodiment;

<figref idref="f0002">Figure 2</figref> is a flow diagram that illustrates exemplary operations for responding to synchronization of dynamic OSPF data according to one embodiment;

<figref idref="f0003">Figure 3</figref> is a flow diagram that illustrates exemplary operations for synchronizing dynamic OSPF data according to one embodiment; and

<figref idref="f0004">Figure 4</figref> is a transaction diagram that illustrates exemplary operations for dynamic OSPF data synchronization according to one embodiment.

DESCRIPTION OF EMBODIMENTS

In the following description, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure the understanding of this description. Those of ordinary skill in the art, with the included descriptions, will be able to implement appropriate functionality without undue experimentation.

References in the specification to "one embodiment," "an embodiment," "an example embodiment," etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

In the following description and claims, the terms "coupled" and "connected," along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. "Coupled" is used to indicate that two or more elements, which may or may not be in direct physical or electrical contact with each other, co-operate or interact with each other. "Connected" is used to indicate the establishment of communication between two or more elements that are coupled with each other.

As used herein, a network element (e.g., a router, switch, bridge) is a piece of networking equipment, including hardware and software, that communicatively interconnects other equipment on the network (e.g., other network elements, end stations). Some network elements are "multiple services network elements" that provide support for multiple networking functions (e.g., routing, bridging, switching, Layer 2 aggregation, session border control, Quality of Service, and/or subscriber management), and/or provide support for multiple application services (e.g., data, voice, and video). Subscriber end stations (e.g., servers, workstations, laptops, netbooks, palm tops, mobile phones, smartphones, multimedia phones, Voice Over internet Protocol (VOIP) phones, user equipment, terminals, portable media players, GPS units, gaming systems, set-top boxes) access content/services provided over the Internet and/or content/services provided on virtual private networks (VPNs) overlaid on (e.g., tunneled through) the Internet. The content and/or services are typically provided by one or more end stations (e.g., server end stations) belonging to a service or content provider or end stations participating in a peer to peer service, and may include, for example, public webpages (e.g., free content, store fronts, search services), private webpages (e.g., username/password accessed webpages providing email services), and/or corporate networks over VPNs. Typically, subscriber end stations are coupled (e.g., through customer premise equipment coupled to an access network (wired or wirelessly)) to edge network elements, which are coupled (e.g., through one or more core network elements) to other edge network elements, which are coupled to other end stations (e.g., server end stations).

Network elements are commonly separated into a control plane and a data plane (sometimes referred to as a forwarding plane or a media plane). In the case that the network element is a router (or is implementing routing functionality), the control plane typically determines how data (e.g., packets) is to be routed (e.g., the next hop for the data and the outgoing port for that data), and the data plane is in charge of forwarding that data. For example, the control plane typically includes one or more routing protocols (e.g., Border Gateway Protocol (BGP), Interior Gateway Protocol(s) (IGP) (e.g., Open Shortest Path First (OSPF), Routing Information Protocol (RIP), Intermediate System to Intermediate System (IS-IS)), Label Distribution Protocol (LDP), Resource Reservation Protocol (RSVP)) that communicate with other network elements to exchange routes and select those routes based on one or more routing metrics.

Each network element running the OSPF protocol maintains an identical link state database (LSDB) describing the topology of the autonomous system (AS). Each individual piece of the LSDB is a particular network element's local state, e.g., the network element's usable interfaces and reachable neighbors or adjacencies. As used herein, neighboring network elements (or "neighbors") are two network elements that have interfaces to a common network, wherein an interface is a connection between a network element and one of its attached networks. Moreover, an adjacency is a relationship formed between selected neighboring network elements for the purpose of exchanging routing information and abstracting the network topology. One or more network element adjacencies may be established over an interface.

The adjacencies are established and maintained through the use of the well-known Hello protocol. Broadly stated, the Hello protocol ensures that communication between neighbors is bi-directional by periodically sending Hello packets out of all of the network element interfaces. Bi-directional communication is indicated when the network element "sees" itself listed in the neighbor's Hello packet. On broadcast and non-broadcast multi-access (NBMA) networks, the Hello protocol elects a designated router (DR) and backup designated router (BDR) for the network.

Once a network element becomes adjacent, it notifies other network elements on the network by sending link state advertisements (LSAs). These LSAs are distributed through a process called reliable flooding, in which a first network element receives a new instance of an LSA from a second network element and forwards the LSA to all of its neighbor network elements, except the second network element if the first network element received the LSA from that network element.

For greater reliability, some OSPF implementations use a technique called Nonstop Routing (NSR), in which state is synchronized between an active and backup OSPF instance to assure that a failure on the active OSPF instance and switchover to the backup OSPF instance does not result in any loss of OSPF protocol synchronization.

Typically, the state must be synchronized between OSPF instances using Inter-Process Communication (IPC) which is much slower than normal memory access. As the complexity of supporting various configurations of active and backup OSPF instances increases, so does the need to support NSR OSPF synchronization occurring at various stages of processing. For example, it is desirable to recover from errors in the NSR OSPF synchronization due to timing issues between the active OSPF instance and backup OSPF instance.

In one embodiment, a network element includes at least two OSPF instances, where a first one acts as an active OSPF instance (or sometimes referred to as a primary OSPF instance) and the second one acts as a backup OSPF instance (or sometimes referred to as a standby OSPF instance or secondary OSPF instance). The active and backup OSPF instances may be executed by routing processors (RPs) on different hardware or the same hardware. For example, one of the OSPF instances may be executed by an RP on a first control card while the other OSPF instance is executed by an RP on a second control card. As another example, the OSPF instances may be executing on different cores of a single processor. As yet another example, the OSPF instances may be running on different processors on the same card.

During participation in an OSPF network, the active OSPF instance receives, and generates, dynamic OSPF data that is used to modify the active OSPF instance's state and this dynamic OSPF data is synchronized with the backup OSPF instance to modify the backup OSPF instance's state.

<figref idref="f0001">Figure 1</figref> illustrates an exemplary network that implements OSPF Nonstop Routing (NSR) with synchronization of dynamic OSPF data according to one embodiment. The network includes the network elements 100, 101, and 111A-111N. The network element 100 includes the OSPF instances 104A and 104B, where the OSPF instance 104A is currently acting as the active OSPF instance and the OSPF instance 104B is currently acting as the backup OSPF instance in an NSR implementation. The network element 100 further includes a router configuration interface 170 that is capable of providing an interface to an administrative user for entering static data such as OSPF configuration data. In one embodiment, the router configuration interface 170 provides a command line interface while in another embodiment it provides a graphical user interface.

The router configuration interface 170 is coupled with an active router configuration module (RCM) 180A and is coupled with a backup RCM 180B. While the network element 100 is in operation, configuration events occur that cause the configuration of the active OSPF instance 104A, the backup OSPF instance 104B, or both. In response to configuration events, the active RCM 180A applies the static configuration data 185A to the active OSPF instance 104A while the backup RCM 180B applies the static configuration data 185B to the backup OSPF instance 104B.

The static configuration data includes area definitions and interface definitions. The area definitions specify a group of contiguous networks and hosts and each area definition includes one or more interface definitions that each specifies an interface used by OSPF for that area. A RCM, either active RCM 180A or backup RCM 180B, uses the static configuration data 185A or 185B to initialize one or more areas and/or interfaces.

As shown in <figref idref="f0001">Figure 1</figref>, the active RCM 180A has used the static configuration data 185A to initialize two areas in the active OSPF instance 104A. As an area is initialized, an area data structure (ADS) and an LSDB are initialized and associated with that area. In <figref idref="f0001">Figure 1</figref>, the active OSPF instance 104A includes a first area associated with a first ADS 110A and a second area associated with a second ADS 130A. The first ADS 110A is associated with a first LSDB 111A while the second ADS 130A is associated with a second LSDB 131A.

Furthermore, the active RCM 180A has used the static configuration data 185A to initialize two interfaces associated with the first area and one interface associated with the second area. As each interface is initialized, an interface data structure (INF DS) is initialized that is associated with that interface. The INF DS includes information associated with the corresponding interface, some of which is determined from the static configuration data and some of which is determined from dynamic OSPF data received at the OSPF instance during the OSPF instance's participation in the OSPF network. In <figref idref="f0001">Figure 1</figref>, the first ADS 110A is associated with a first INF DS 112A and a second INF DS 114A. Furthermore, the second ADS 130A is associated with a third INF DS 132A.

In <figref idref="f0001">Figure 1</figref>, the first INF DS 112A is associated with a neighbor data structure (NDS) 113A that was generated based on OSPF Hello Protocol communication with the other network elements 101, and 111A-111N. Furthermore, the third INF data structure 132A is associated with an NDS 133A also generated based on OSPF Hello Protocol communication. The Hello Protocol is further capable of determining a designated router and a backup designated router for each interface. Thus, an interface designated router (INF DR) or an interface backup designated router (INF BDR) might be associated with each interface in that interface's data structure. While not shown in <figref idref="f0001">Figure 1</figref>, the network element 100 further receives LSAs from its neighboring network elements. For example, the network element 100 receives LSA(s) from the network element 101 over the link 102. Specifically, the OSPF instance 104A receives LSA(s) from the network element 101 over the link 102. The OSPF instance 104A processes the received LSAs including storing the information from the LSA into an LSDB corresponding to the area associated with the source network element; in this case the source network element being network element 101.

With respect to the backup OSPF instance 104B, the backup RCM 180B has used the static configuration data 185B, which is substantially similar to the static configuration data 185A, to initialize one area in the backup OSPF instance 104B. The backup OSPF instance 104B includes a first area associated with a first ADS 110B. The first ADS 110B is associated with a first LSDB 111B. However, the static configuration data 185B further includes configuration information for initializing a second area in the backup OSPF instance 104B, thereby matching the configuration of the active OSPF instance 104A. However, at the point shown in <figref idref="f0001">Figure 1</figref>, the second area in the backup OSPF instance 104B is not yet initialized. Therefore, <figref idref="f0001">Figure 1</figref> shows, in dashed markings, a second ADS structure 130B that is associated with a second LSDB 131B and a second INF DS 132B. These elements are dashed to indicate that, though those elements will be present once the second area and third interface are initialized, they are not currently present in the backup OSPF instance 104B.

As described above, it is important for the active OSPF instance 104A to synchronize its state information with the backup OSPF instance 104B. The state information includes the dynamic OSPF data generated or received during participation in the OSPF network that is contained in the ADSs 110A and 130A; the INF DSs 112A, 114A, and 132A; and the LSDBs 111A and 131A. To effectuate the synchronization of the dynamic OSPF data, the active OSPF instance 104A includes an active NSR synchronization module 160A that performs NSR state synchronization with a backup NSR synchronization module 160B in the backup OSPF instance 104B.

<figref idref="f0001">Figure 1</figref> illustrates dynamic OSPF data 190 being synchronized from the active NSR synchronization module 160A to the backup NSR synchronization module 160B. Specifically, the dynamic OSPF data 190 includes information for synchronizing NDS 133A to the, not yet initialized, second area. Upon receiving the dynamic OSPF data associated with NDS 133A, the backup NSR synchronization module 160B will recognize that INF DS 132B corresponding with the interface associated with NDS 133A does not exist.

In one embodiment, the backup NSR synchronization module 160B will be unable to generate an NDS 133B in association with INF DS 132B since INF DS 132B does not yet exist. Since the synchronization will have failed, the backup NSR synchronization module 160B will send a NACK 191 to the active NSR synchronization module 160A in response to that failure. The backup NSR synchronization module 160B expects for the active NSR synchronization module 160A to react to the NACK 191 by initiating a resynchronization of all dynamic OSPF data represented in the ADSs 110A and 130A; the INF DSs 112A, 114A, and 132A; and the LSDBs 111A and 131A. In anticipation of the resynchronization of the dynamic OSPF data from the active OSPF instance 104A, the backup OSPF instance 104B clears all of its dynamic OSPF data. Specifically, the backup OSPF instance 104B deletes NDS 113B and clears previously synchronized dynamic OSPF data from ADS 110B; the INF DSs 112B and 114B; and the LSDB 111B. After a set amount of time, the active NSR synchronization module 160A begins the resynchronization of dynamic OSPF data with the expectation that all requisite initialization on the backup OSPF instance 104B will have occurred.

While the NACK 191 is described specifically in reference to an interface associated with INF DS 132B not being initialized, the NACK approach may be utilized in any scenario in which the backup NSR synchronization module 160B receives some dynamic OSPF data for synchronization at a time in which the received dynamic OSPF data cannot be processed. In other words, the backup NSR synchronization module 160B may send a NACK when receiving dynamic OSPF data associated with an uninitialized area or uninitialized interface. Specifically, the backup NSR synchronization module 160B responds with a NACK if it receives dynamic OSPF data containing an LSA associated with an Area or LSDB that has not yet been created. The backup NSR synchronization module 160B responds with a NACK if it receives dynamic OSPF data containing an INF DR/DBR message associated with an INF DS that has not yet been generated. The backup NSR synchronization module 160B also responds with a NACK if it receives dynamic OSPF data containing an NDS message associated with an INF DS that has not yet been generated. Furthermore, the NACK 191 is useful in the scenario in which the backup NSR synchronization module 160B is unable to process the dynamic OSPF data even if the requisite areas and interfaces are fully initialized; for example, if the backup OSPF instance 104B is not ready to process the dynamic OSPF data.

This approach optimizes for the normal, most frequent case where the backup OSPF instance 104B is ready to process dynamic OSPF data from the active OSPF instance 104A. In the rare case when backup OSPF instance 104B is not ready, the NACK buys time for backup OSPF instance 104B to receive configuration events and initialize the requisite areas, interfaces, and data structures so that it will be ready to process dynamic OSPF data in the future. When the resynchronization occurs, the backup OSPF instance 104B will be ready to process the data. Additionally, a single NACK can cover all possible out-of-order scenarios. Even when resynchronization is triggered, there is little overhead expected because if resynchronization occurs at all, it occurs near the creation of the backup OSPF instance 104B or at an update of the configuration of the backup OSPF instance 104B. These events are expected to be rare.

In another embodiment (not shown), the backup OSPF instance 104B receives the dynamic OSPF data 190 and, in recognition that INF DS 132B does not yet exist, generates a temporary data structure to hold the information included in the dynamic OSPF data 190. This temporary data structure holds the unprocessed dynamic OSPF data 190 until the INF DS 132B is generated during the initialization of the interface associated with INF DS 132B. At that time, the backup NSR synchronization module 160B, or some other process running along with the backup OSPF instance 104B, can determine that INF DS 132B has been created and use the temporary data structure to synchronize NDS 133A with NDS 133B in association with INF DS 132B.

<figref idref="f0002">Figure 2</figref> is a flow diagram that illustrates exemplary operations for responding to synchronization of dynamic OSPF data according to one embodiment. The operations of this flow diagram and other flow diagrams will be described with reference to the exemplary embodiments of <figref idref="f0001">Figure 1</figref>. However, it should be understood that the operations of the flow diagrams can be performed by embodiments of the invention other than those discussed with reference to <figref idref="f0001">Figure 1</figref>, and the embodiments of the invention discussed with reference to <figref idref="f0001">Figure 1</figref> can perform operations different than those discussed with reference to the flow diagrams.

At operation 200, the backup OSPF instance 104B receives OSPF synchronization data that includes dynamic OSPF data for synchronization from the active OSPF instance 104A. For example, the backup OSPF instance 104B receives LSAs, NDSs, and/or INF DR/BDRs from the active OSPF instance 104A to be synchronized in the backup OSPF instance 104B. Flow optionally moves to operation 210 at which the backup OSPF instance 104B determines whether its state allows for the addition of the dynamic OSPF data. If the backup OSPF instance's 104B state allows for the addition of the dynamic OSPF data, the flow moves to operation 220 otherwise the flow moves to operation 260.

At operation 220, the backup OSPF instance 104B determines whether the data structure(s) associated with the dynamic OSPF data exists. If the data structure(s) exists the flow moves to operation 240 otherwise the flow moves to operation 260. At operation 240, the backup OSPF instance 104B adds the dynamic OSPF data to the corresponding data structure(s) and optionally continues by returning an acknowledgment message at operation 250.

At operation 260, the backup OSPF instance 104B returns a NACK message to the active OSPF instance 104A and optionally continues by clearing previously added dynamic OSPF data from the backup OSPF instance 104B at operation 270.

<figref idref="f0003">Figure 3</figref> is a flow diagram that illustrates exemplary operations for synchronizing dynamic OSPF data according to one embodiment. In cycle of the operations, the flow begins in operation 300 with the active OSPF instance 104A receiving dynamic OSPF data from a neighbor network element. While in another cycle of the operations, the flow begins at operation 310 with the active OSPF determining a dynamic OSPF synchronization event has occurred.

As shown in operation 305, the active OSPF instance 104A receives dynamic OSPF data such as an LSA, NDS, or INF DR/BDR from a neighboring network element. Furthermore, the active OSPF instance 104A adds the dynamic OSPF data to data structures in the active OSPF instance 104A such as ADS 110A, LSDB 111A, or INF DS 112A in operation 305.

With reference to determining that a dynamic OSPF data synchronization event occurred, the active OSPF instance recognizes a number of events as dynamic OSPF data synchronization events. As described with reference to operation 300, the receipt of dynamic OSPF data from a neighbor network element is one such dynamic OSPF data synchronization event. Another dynamic OSPF data synchronization event is when the active OSPF instance 104A generates an LSA for transmission to one or more neighboring network elements. Further, the receipt of a NACK during dynamic OSPF data synchronization with a backup OSPF instance is a dynamic synchronization event.

The flow continues at operation 315 with determining the synchronization data that is to be communicated to the backup OSPF instance 104B. For example, the receipt, or generation, or dynamic OSPF data that needs to be synchronized means the received, or generated, dynamic OSPF data is the synchronization data. However, in the case of receiving a NACK during NSR data synchronization with a backup OSPF instance, all dynamic OSPF data associated with the active OSPF instance must be synchronized and therefore all dynamic OSPF data in the active OSPF instance is the synchronization data. In response to determining the synchronization data, the active OSPF instance 104A optionally adds the synchronization data to a synchronization data queue in operation 320.

Flow continues at operation 325 in which the active OSPF instance 104A communicates the synchronization data to the backup OSPF instance 104B. In at least one embodiment, there is a delay before continuing operation 325 to give the backup OSPF instance 104B an amount of time from which it is expected the backup OSPF instance 104B will be able to utilize the synchronization data. In at least one embodiment, flow continues at operation 327 with determining whether the OSPF synchronization data was successfully communicated to the backup OSPF instance 104B. If the data was not successfully communicated then the flow continues back at operation 325, otherwise the flow continues on to operation 330 for embodiments that utilize a synchronization data queue according to operation 320. At operation 330 the active OSPF instance 104A removes the synchronization data from the synchronization data queue. The flow continues at operation 335 at which time the active OSPF instance 104A receives a NACK from the backup OSPF instance 104B indicating that the synchronization of dynamic OSPF data failed. In response to the receipt of the NACK, the flow continues at operation 340 for embodiments utilizing a synchronization data queue as described in operations 320 and 330. In operation 340, the active OSPF instance 104A clears the synchronization data queue as the active OSPF instance 104A will be resynchronizing all dynamic OSPF data with the backup OSPF instance 104B. In response to receiving the NACK, the operation continues back at 310. However, the dynamic OSPF data synchronization event is now the receipt of the NACK which initiates a resynchronization of all dynamic OSPF data from the active OSPF instance 104A to the backup OSPF instance 104B.

<figref idref="f0004">Figure 4</figref> is a transaction diagram that illustrates operations for dynamic OSPF data synchronization according to one embodiment. At operation 1, an LSA 401 is received from the network element 101 at the active OSPF instance 104A. Next, at operation 2, the active OSPF instance 104A optionally adds the LSA 401 to a synchronization data queue. Next, at operation 3, the active OSPF instance 104A synchronizes the LSA 401 with the backup OSPF instance 104B and, optionally, removes the LSA 401 from the synchronization data queue at operation 4.

At operation 5, the backup OSPF instance 104B updates an LSBD corresponding to the data included in LSA 401 by adding the LSA 401 to the LSDB or updating data included in the LSDB. At operation 6, the backup OSPF instance 104B optionally sends an ACK message 415 to the active OSPF instance 104A to indicate the successful synchronization of the dynamic OSPF data.

At operation 7, an LSA 420 is received from the network element 101 at the active OSPF instance 104A. Next, at operation 8, the active OSPF instance 104A optionally adds the LSA 420 to a synchronization data queue. Next, at operation 9, the active OSPF instance 104A synchronizes the LSA 420 with the backup OSPF instance 104B and, optionally, removes the LSA 401 from the synchronization data queue at operation 10.

With respect to LSA 420, the backup OSPF instance 104B determines that one or more data structures associated with LSA 420 do not exist at operation 11. Specifically, the backup OSPF instance 104B expects an area and an interface related to the LSA to be initialized and associated data structures to exist in order to process the LSA 420. Therefore, if either the associated area or associated interface is not yet initialized then the backup OSPF instance 104B will determine that one or more of the requisite data structures are not present. This is considered a failed dynamic OSPF data synchronization.

In response to the failed dynamic OSPF data synchronization, the backup OSPF instance 104B clears all previously synchronized dynamic data from its data structures in operation 12 and sends a NACK 425 in operation 13 to inform the active OSPF instance 104A of the synchronization failure.

In response to the NACK 425, the active OSPF instance 104A generates OSPF synchronization data 430 from the dynamic data included the data structures of the active OSPF instance 104A at operation 14. Next, at operation 15, the active OSPF instance 104A optionally adds the OSPF synchronization data 430 to a synchronization data queue. Next, at operation 16, the active OSPF instance 104A synchronizes OSPF synchronization data 430 with the backup OSPF instance 104B and, optionally, removes the OSPF synchronization data 430 from the synchronization data queue at operation 17. In at least one embodiment, there is a delay before continuing operation 16 to give the backup OSPF instance 104B an amount of time from which it is expected the backup OSPF instance 104B will be able to utilize the synchronization data.

At operation 18, the backup OSPF instance 104B updates the corresponding data structures based on the OSPF synchronization data 430. At operation 19, the backup OSPF instance 104B optionally sends an ACK message 435 to the active OSPF instance 104A to indicate the successful synchronization of the OSPF synchronization data.

While the flow diagrams in the figures show a particular order of operations performed by certain embodiments of the invention, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

While the invention has been described in terms of several embodiments, those skilled in the art will recognize that the invention is not limited to the embodiments described, can be practiced with modification and alteration within the spirit and scope of the appended claims. The description is thus to be regarded as illustrative instead of limiting.