The Full Wiki

Open Shortest Path First: Wikis


Note: Many of our articles have direct quotes from sources you can cite, within the Wikipedia article! This article doesn't yet, but we're working on it! See more info or our list of citable articles.


From Wikipedia, the free encyclopedia

Open Shortest Path First (OSPF) is a dynamic routing protocol for use in Internet Protocol (IP) networks. Specifically, it is a link-state routing protocol and falls into the group of interior gateway protocols, operating within a single autonomous system (AS). It is defined as OSPF Version 2 in RFC 2328 (1998) for IPv4.[1] The updates for IPv6 are specified as OSPF Version 3 in RFC 5340 (2008).[2]

OSPF is perhaps the most widely-used interior gateway protocol (IGP) in large enterprise networks; IS-IS, another link-state routing protocol, is more common in large service provider networks. The most widely-used exterior gateway protocol is the Border Gateway Protocol (BGP), the principal routing protocol between autonomous systems on the Internet.

The Internet Protocol Suite
Application Layer
BGP · DHCP · DNS · FTP · GTP · HTTP · IMAP · IRC · Megaco · MGCP · NNTP · NTP · POP · RIP · RPC · RTP · RTSP · SDP · SIP · SMTP · SNMP · SOAP · SSH · Telnet · TLS/SSL · XMPP · (more)
Transport Layer
TCP · UDP · DCCP · SCTP · RSVP · ECN · (more)
Internet Layer
IP (IPv4, IPv6) · ICMP · ICMPv6 · IGMP · IPsec · (more)
Link Layer
ARP/InARP · NDP · OSPF · Tunnels (L2TP) · PPP · Media Access Control (Ethernet, DSL, ISDN, FDDI) · (more)



OSPF is an interior gateway protocol that routes Internet Protocol (IP) packets solely within a single routing domain (autonomous system). It gathers link state information from available routers and constructs a topology map of the network. The topology determines the routing table presented to the Internet Layer which makes routing decisions based solely on the destination IP address found in IP datagrams. OSPF was designed to support variable-length subnet masking (VLSM) or Classless Inter-Domain Routing (CIDR) addressing models.

OSPF detects changes in the topology, such as link failures, very quickly and converges on a new loop-free routing structure within seconds. It computes the shortest path tree for each route using a method based on Dijkstra's algorithm, a shortest path first algorithm.

The link-state information is maintained on each router as a link-state database (LSDB) which is a tree-image of the entire network topology. Identical copies of the LSDB are periodically updated through flooding on all OSPF routers.

The OSPF routing policies to construct a route table are governed by link cost factors (external metrics) associated with each routing interface. Cost factors may be the distance of a router (round-trip time), network throughput of a link, or link availability and reliability, expressed as simple unitless numbers. This provides a dynamic process of traffic load balancing between routes of equal cost.

An OSPF network may be structured, or subdivided, into routing areas to simplify administration and optimize traffic and resource utilization. Areas are identified by 32-bit numbers, expressed either simply in decimal, or often in octet-based dot-decimal notation, familiar from IPv4 address notation.

By convention, area 0 (zero) or represents the core or backbone region of an OSPF network. The identifications of other areas may be chosen at will, often, administrators select the IP address of a main router in an area as the area's identification. Each additional area must have a direct or virtual connection to the backbone OSPF area. Such connections are maintained by an interconnecting router, known as area border router (ABR). An ABR maintains separate link state databases for each area it serves and maintains summarized routes for all areas in the network.

OSPF does not use a TCP/IP transport protocol (UDP, TCP), but is encapsulated directly in IP datagrams with protocol number 89. This is in contrast to other routing protocols, such as the Routing Information Protocol (RIP), or the Border Gateway Protocol (BGP). OSPF handles its own error detection and correction functions.

OSPF uses multicast addressing for route flooding on a broadcast network link. For non-broadcast networks special provisions for configuration facilitate neighbor discovery.[1] OSPF multicast IP packets never traverse IP routers, they never travel more than one hop. OSPF reserves the multicast addresses (all SPF/link state routers, also known as AllSPFRouters) and (all Designated Routers, AllDRouters), as specified in RFC 2328.

For routing multicast IP traffic, OSPF supports the Multicast Open Shortest Path First protocol (MOSPF) as defined in RFC 1584.[3] Neither Cisco or Juniper Networks include MOSPF in their OSPF implementations. PIM (Protocol Independent Multicast) in conjunction with OSPF or other IGPs, (Interior gateway protocol), is widely deployed.

The OSPF protocol, when running on IPv4, can operate securely between routers, optionally using a variety of authentication methods to allow only trusted routers to participate in routing. OSPFv3, running on IPv6, no longer supports protocol-internal authentication. Instead, it relies on IPv6 protocol security (IPsec).

OSPF version 3 introduces modifications to the IPv4 implementation of the protocol.[2] Except for virtual links, all neighbor exchanges use IPv6 link-local addressing exclusively. The IPv6 protocol runs per link, rather than based on the subnet. All IP prefix information has been removed from the link-state advertisements and from the Hello discovery packet making the protocol essentially protocol-independent. Despite the expanded IP addressing to 128-bits in IPv6, area and router identifications are still based on 32-bit values.

Neighbor relationships

Routers in the same broadcast domain or at each end of a point-to-point telecommunications link form adjacencies when they have detected each other. This detection occurs when a router identifies itself in a hello OSPF protocol packet. This is called a two way state and is the most basic relationship. The routers in an Ethernet or frame relay network select a designated router (DR) and a backup designated router (BDR) which act as a hub to reduce traffic between routers. OSPF uses both unicast and multicast to send "hello packets" and link state updates.

As a link state routing protocol, OSPF establishes and maintains neighbor relationships in order to exchange routing updates with other routers. The neighbor relationship table is called an adjacency database in OSPF. Provided that OSPF is configured correctly, OSPF forms neighbor relationships only with the routers directly connected to it. The routers that it forms a neighbor relationship with must be in the same area as the interface with which it is using to form a neighbor relationship. An interface can only belong to a single area.

Area types

An OSPF domain is divided into areas that are labeled with 32-bit area identifiers. The area identifiers are commonly, but not always, written in the dot-decimal notation of an IPv4 address. However, they are not IP addresses and may duplicate, without conflict, any IPv4 address. The area identifiers for IPv6 implementations of OSPF (OSPFv3) also use 32-bit identifiers written in the same notation. While most OSPF implementations will right-justify an area number written in other than dotted decimal format (e.g., area 1), it is wise to always use dotted-decimal formats. Most implementations expand area 1 to the area identifier, but some have been known to expand it as

Areas are logical groupings of hosts and networks, including their routers having interfaces connected to any of the included networks. Each area maintains a separate link state database whose information may be summarized towards the rest of the network by the connecting router. Thus, the topology of an area is unknown outside of the area. This reduces the amount of routing traffic between parts of an autonomous system.

Several "special" area types are defined:


Backbone area

The backbone area (also known as area 0 or area forms the core of an OSPF network. All other areas are connected to it, and inter-area routing happens via routers connected to the backbone area and to their own associated areas. It is the logical and physical structure for the 'OSPF domain' and is attached to all nonzero areas in the OSPF domain. Note that in OSPF the term Autonomous System Boundary Router (ASBR) is historic, in the sense that many OSPF domains can coexist in the same Internet-visible autonomous system, RFC1996 (ASGuidelines 1996, p. 25).[4]

The backbone area is responsible for distributing routing information between nonbackbone areas. The backbone must be contiguous, but it does not need to be physically contiguous; backbone connectivity can be established and maintained through the configuration of virtual links.

All OSPF areas must connect to the backbone area. This connection, however, can be through a virtual link. For example, assume area has a physical connection to area Further assume that area has no direct connection to the backbone, but this area does have a connection to area Area can use a virtual link through the transit area to reach the backbone. To be a transit area, an area has to have the transit attribute, so it cannot be stubby in any way.

Stub area

A stub area is an area which does not receive route advertisements external to the autonomous system (AS) and routing from within the area is based entirely on a default route. This reduces the size of the routing databases for the area's internal routers.

Modifications to the basic concept of stub areas exist in the not-so-stubby area (NSSA). In addition, several other proprietary variation have been implemented by systems vendors, such as the totally stubby area (TSA) and the NSSA totally stubby area, both an extension in Cisco Systems routing equipment.

Not-so-stubby area

A not-so-stubby area (NSSA) is a type of stub area that can import autonomous system external routes and send them to other areas, but still cannot receive AS external routes from other areas. NSSA is an extension of the stub area feature that allows the injection of external routes in a limited fashion into the stub area.

Proprietary extensions

Several vendors, (Cisco, Juniper, Huawei, Quagga), now implement below two extensions to stub and NSSA area and although not covered by RFC they are considered by many to be standard features in OSPF implementations.

Totally stubby area
A totally stubby area is similar to a stub area. However, this area does not allow summary routes in addition to not having external routes, that is, inter-area (IA) routes are not summarized into totally stubby areas. The only way for traffic to get routed outside of the area is a default route which is the only Type-3 LSA advertised into the area. When there is only one route out of the area, fewer routing decisions have to be made by the route processor, which lowers system resource utilization.
Occasionally, it is said that a TSA can have only one ABR.[citation needed] This is not true. If there are multiple ABRs, as might be required for high availability, routers interior to the TSA will send non-intra-area traffic to the ABR with the lowest intra-area metric (the "closest" ABR).
NSSA totally stubby area
An addition the standard functionality of an NSSA, called a NSSA totally stubby area. It takes on the attributes of a TSA, meaning that type 3 and type 4 summary routes are not flooded into this type of area. It is also possible to declare an area both totally stubby and not-so-stubby, which means that the area will receive only the default route from area, but can also contain an autonomous system boundary router (ASBR) that accepts external routing information and injects it into the local area, and from the local area into area
Redistribution into an NSSA area creates a special type of LSA known as TYPE 7, which can exist only in an NSSA area. An NSSA ASBR generates this LSA, and an NSSA ABR router translates it into type 5 LSA which gets propagated into the OSPF domain.

Stub areas

An area can simultaneously be not-so-stubby and totally stubby. This is done when the practical place to put an ASBR, as, for example, with a newly acquired subsidiary, is on the edge of a totally stubby area. In such a case, the ASBR does send externals into the totally stubby area, and they are available to OSPF speakers within that area. In Cisco's implementation, the external routes can be summarized before injecting them into the totally stubby area. In general, the ASBR should not advertise default into the TSA-NSSA, although this can work with extremely careful design and operation, for the limited special cases in which such an advertisement makes sense.

By declaring the totally stubby area as NSSA, no external routes from the backbone, except the default route, enter the area being discussed. The externals do reach area via the TSA-NSSA, but no routes other than the default route enter the TSA-NSSA. Routers in the TSA-NSSA send all traffic to the ABR, except to routes advertised by ASBR.

Transit area

A transit area is an area with two or more OSPF border routers and is used to pass network traffic from one adjacent area to another. The transit area does not originate this traffic and is not the destination of such traffic.

Path preference

OSPF uses path cost as its basic routing metric, which was defined by the standard not to equate to any standard value such as speed, so the network designer could pick a metric important to the design. In practice, it is determined by the speed (bandwidth) of the interface addressing the given route, although that tends to need network-specific scaling factors now that links faster than 100 Mbit/s are common. Cisco uses a metric like 10^8/bandwidth (the base value, 10^8 by default, can be adjusted). So, a 100Mbit/s link will have a cost of 1, a 10Mbit/s a cost of 10 and so on. But for links faster than 100Mbit/s, the cost would be <1.

Metrics, however, are only directly comparable when of the same type. There are four types of metrics, with the most preferred type listed in order below. An intra-area route is always preferred to an inter-area route regardless of metric, and so on for the other types.

  1. Intra-area
  2. Inter-area
  3. External Type 1, which includes both the external path cost and the sum of internal path costs to the ASBR that advertises the route,
  4. External Type 2, the value of which is solely that of the external path cost

Traffic engineering

OSPF-TE is an extension to OSPF extending the expressivity to allow for traffic engineering and use on non-IP networks (RFC 3630).[5] More information about the topology can be exchanged using opaque LSA carrying type-length-value elements. These extensions allow OSPF-TE to run completely out of band of the data plane network. This means that it can also be used on non-IP networks, such as optical networks.

Uses of OSPF-TE include the following.

GMPLS networks, as a means to describe the topology over which GMPLS paths can be established. 
GMPLS then uses its own path setup and forwarding protocols, once it has the full network map.
Recording and flooding RSVP (Resource reservation protocol) signaled bandwidth reservations for LSPs, (Label switched  paths), within the LSDB.

Other extensions

RFC 3717 documents work in optical routing for IP, based on "constraint-based" extensions to OSPF and IS-IS.[6]

OSPF router types

OSPF defines the following router types:

  • Area border router (ABR)
  • Autonomous system boundary router (ASBR)
  • Internal router (IR)
  • Backbone router (BR)

The router type is an attribute of an OSPF process. A given physical router may have one or more OSPF processes. For example, a router that is connected to more than one area, and which receives routes from a BGP process connected to another AS, is both an area border router and an autonomous system boundary router.

Each router has an identifier, customarily written in the dotted decimal format (e.g., of an IP address. This identifier must be established in every OSPF instance. If not explicitly configured, the highest logical IP address will be duplicated as the router identifier. However, since the router identifier is an IP address, it does not have to be a part of any routable subnet in the network, and often isn't to avoid confusion.

These router types should not be confused with the terms designated router (DR), or backup designated router (BDR), which are attributes of a router interface, not the router itself.

Area border router

An area border router (ABR) is a router that connects one or more areas to the main backbone network. It is considered a member of all areas it is connected to. An ABR keeps multiple copies of the link-state database in memory, one for each area to which that router is connected.

Autonomous system boundary router

An autonomous system boundary router (ASBR) is a router that is connected to more than one autonomous system (AS) and that exchanges routing information with routers in other ASs. ASBRs typically also run an exterior routing protocol (e.g., BGP), or use static routes, or both. An ASBR is used to distribute routes received from other, external ASs throughout its own autonomous system.

Internal router

An internal router is a router that has OSPF neighbor relationships with interfaces in the same area.

Backbone router

Backbone routers are all routers that are connected to the OSPF backbone, irrespective whether they are also area border routers or internal routers of the backbone area. An area border router is always a backbone router, since all areas must be either directly connected to the backbone or connected to the backbone via a virtual link (spanning across another area to get to the backbone).

Designated router

A designated router (DR) is the router interface elected among all routers on a particular multiaccess network segment, generally assumed to be broadcast multiaccess. Special techniques, often vendor-dependent, may be needed to support the DR function on nonbroadcast multiaccess (NBMA) media. It is usually wise to configure the individual virtual circuits of a NBMA subnet as individual point-to-point lines; the techniques used are implementation-dependent.

Do not confuse the DR with an OSPF router type. A given physical router can have some interfaces that are designated (DR), others that are backup designated (BDR), and others that are non-designated. If no router is DR or BDR on a given subnet, the DR is first elected, and then a second election is held if there is more than one BDR. [7] The DR is elected based on the following default criteria:

  • If the priority setting on a OSPF router is set to 0, that means it can NEVER become a DR or BDR (Backup Designated Router).
  • When a DR fails and the BDR takes over, there is another election to see who becomes the replacement BDR.
  • The router sending the Hello packets with the highest priority wins the election.
  • If two or more routers tie with the highest priority setting, the router sending the Hello with the highest RID (Router ID) wins. NOTE: a RID is the highest logical (loopback) IP address configured on a router, if no logical/loopback IP address is set then the Router uses the highest IP address configured on its active interfaces. (e.g. would be higher than
  • Usually the router with the second highest priority number becomes the BDR.
  • The priority values range between 0 - 255[8], with a higher value increasing its chances of becoming DR or BDR.
  • IF a HIGHER priority OSPF router comes online AFTER the election has taken place, it will not become DR or BDR until (at least) the DR and BDR fail.
  • If the current DR 'goes down' the current BDR becomes the new DR and a new election takes place to find another BDR. If the new DR then 'goes down' and the original DR is now available, it then becomes DR again, but no change is made to the current BDR.

DR's exist for the purpose of reducing network traffic by providing a source for routing updates, the DR maintains a complete topology table of the network and sends the updates to the other routers via multicast. All routers in an area will form a slave/master relationship with the DR. They will form adjacencies with the DR and BDR only. Every time a router sends an update, it sends it to the DR and BDR on the multicast address The DR will then send the update out to all other routers in the area, to the multicast address This way all the routers do not have to constantly update each other, and can rather get all their updates from a single source. The use of multicasting further reduces the network load. DRs and BDRs are always setup/elected on Broadcast networks (Ethernet). DR's can also be elected on NBMA (Non-Broadcast Multi-Access) networks such as Frame Relay or ATM. DRs or BDRs are not elected on point-to-point links (such as a point-to-point WAN connection) because the two routers on either sides of the link must become fully adjacent and the bandwidth between them cannot be further optimized.

Backup designated router

A backup designated router (BDR) is a router that becomes the designated router if the current designated router has a problem or fails. The BDR is the OSPF router with second highest priority at the time of the last election.

OSPF v3 Packet Formats

The "Main OSPF Packet Header" is the same for all 5 types of packets (with exception of the Type field) where as the following sub-headers will vary from type to type and are shown below the Main OSPF Packet Header.

The Main OSPF Packet Header
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 Version Type Packet Length
32 Router ID
64 Area ID
96 Checksum Instance ID 0

As per Appendix A.3 of RFC 5340 (OSPFv3 for IPv6) there are 5 OSPF Packet formats as follows:

Type Description
1 Hello
2 Database Description
3 Link State Request
4 Link State Update
5 Link State Acknowledgement

The five different formats for each "Type" of OSPF v3 packet are listed below:

Type 1: The Hello Packet

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 3 {Ver} 1 {Type} Packet Length
32 Router ID
64 Area ID
96 Checksum Instance ID 0
128 Interface ID
160 Rtr Priority Options (Explained below)
192 HelloInterval RouterDeadInterval
224 Designated Router ID
256 Backup Designated Router ID
288 Neighbor ID
~ ...

Type 2: The Database Description Packet

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 3 {Ver} 2 {Type} Packet Length
32 Router ID
64 Area ID
96 Checksum Instance ID 0
128 0 Options (Explained below)
160 Interface MTU 0 0 0 0 0 0 I M MS
192 DD sequence number
224 An LSA Header
~ ...

Type 3: The OSPF Link State Request Packet

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 3 {Ver} 3 {Type} Packet Length
32 Router ID
64 Area ID
96 Checksum Instance ID 0
128 0 LS Type
160 Link State ID
192 Advertising Router
~ ...

Type 4: The OSPF Link State Update Packet

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 3 {Ver} 4 {Type} Packet Length
32 Router ID
64 Area ID
96 Checksum Instance ID 0
128 # LSAs
160 LSAs
~ ...

Type 5: The OSPF Link State Acknowledgement Packet

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 3 {Ver} 5 {Type} Packet Length
32 Router ID
64 Area ID
96 Checksum Instance ID 0
128 An LSA Header (Shown below)
~ ...

The OSPFv3 (24 Bit) Options Field

This "Options Field" is used in OSPF Hello packets, Database Description packets, and certain LSAs (router-LSAs, network-LSAs, inter-area-router-LSAs, and link-LSAs).
(Note: Previous OSPF versions {v1 & v2} DO NOT not support all of the options/fields listed here.)
Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
                                  * * DC R N x E V6
Explanation of the bits in the Options field:
There are currently only 7-bits assigned.
V6-bit: "V6" stands for IP[v6] routing calculations are to be used.
E-bit: "E" stands for [E]xternal as in AS-External-LSA flooding as specified in OSPFv2.
x-bit: This is currently depreciated. It was previously used by MOSPF.
N-bit: "N" stands for [N]SSA (Not So Stubby Area) and used for routers which are attached to NSSA networks.
R-bit: "R" stands for [R]outer and specifies whether the router is Active or not.
DC-bit: "DC" stands for [D]emand [C]ircuts and is specified in RFC 1793.
  • -bits: These two bits are reserved for migration of OSPFv2 protocol extensions.
The remaining 16-bits have yet to be assigned.

OSPF in broadcast multiple access topologies

Neighbor adjacency is formed dynamically using multicast hello packets to A DR and BDR are elected normally, and function normally.

OSPF in NBMA topologies

As described in RFC 2328, has defined the following two official modes for OSPF in NBMA topologies:

  • nonbroadcast
  • point-to-multipoint

Cisco has defined the following three additional modes for OSPF in NBMA topologies:

  • point-to-multipoint nonbroadcast
  • broadcast
  • point-to-point


Test Equipment

Other testing solutions for conformance and load or stress testing is available from vendors such as:


OSPF was the first widely deployed routing protocol that could converge a network in the low seconds, and guarantee loop-free paths. It has many features that allow the imposition of policies about the propagation of routes that it may be appropriate to keep local, for load sharing, and for selective route importing more than IS-IS. IS-IS, in contrast, can be tuned for lower overhead in a stable network, the sort more common in ISP than enterprise networks. There are some historical accidents that made IS-IS the preferred IGP for ISPs, but ISP's today may well choose to use the features of the now-efficient implementations of OSPF,[11] after first considering the pros and cons of ISIS in service provider environments.[12]

As mentioned, OSPF can provide better load-sharing on external links than other IGPs. When the default route to an ISP is injected into OSPF from multiple ASBRs as a Type I external route and the same external cost specified, other routers will go to the ASBR with the least path cost from its location. This can be tuned further by adjusting the external cost.

In contrast, if the default route from different ISPs is injected with different external costs, as a Type II external route, the lower-cost default becomes the primary exit and the higher-cost becomes the backup only.

RFC history

The following image gives a visual view of how the older OSPF related RFCs have transpired into their current state today.

Number Title (Current as of: 2010/02/25) Date More Info (Obs&Upd) Status
RFC 5709 OSPFv2 HMAC-SHA Cryptographic Authentication 2009/10/01 Updates RFC 2328 PROPOSED STANDARD
RFC 5643 Management Information Base for OSPFv3 2009/08/01   PROPOSED STANDARD
RFC 5642 Dynamic Hostname Exchange Mechanism for OSPF 2009/08/01   PROPOSED STANDARD
RFC 5614 Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding 2009/08/01   EXPERIMENTAL
RFC 5613 OSPF Link-Local Signaling 2009/08/01 Obsoletes RFC 4813 PROPOSED STANDARD
RFC 5523 OSPFv3-Based Layer 1 VPN Auto-Discovery 2009/04/01   EXPERIMENTAL
RFC 5449 OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks 2009/02/01   EXPERIMENTAL
RFC 5392 OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering 2009/01/01   PROPOSED STANDARD
RFC 5340 OSPF for IPv6 2008/07/01 Obsoletes RFC 2740 PROPOSED STANDARD
RFC 5329 Traffic Engineering Extensions to OSPF Version 3 2008/09/01   PROPOSED STANDARD
RFC 5252 OSPF-Based Layer 1 VPN Auto-Discovery 2008/07/01   PROPOSED STANDARD
RFC 5250 The OSPF Opaque LSA Option 2008/07/01 Obsoletes RFC 2370 PROPOSED STANDARD
RFC 5243 OSPF Database Exchange Summary List Optimization 2008/05/01   INFORMATIONAL
RFC 5187 OSPFv3 Graceful Restart 2008/06/01   PROPOSED STANDARD
RFC 5185 OSPF Multi-Area Adjacency 2008/05/01   PROPOSED STANDARD
RFC 5088 OSPF Protocol Extensions for Path Computation Element (PCE) Discovery 2008/01/01   PROPOSED STANDARD
RFC 4973 OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering 2007/07/01   EXPERIMENTAL
RFC 4972 Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership 2007/07/01   PROPOSED STANDARD
RFC 4970 Extensions to OSPF for Advertising Optional Router Capabilities 2007/07/01   PROPOSED STANDARD
RFC 4940 IANA Considerations for OSPF 2007/07/01   BEST CURRENT PRACTICE
RFC 4915 Multi-Topology (MT) Routing in OSPF 2007/06/01   PROPOSED STANDARD
RFC 4813 OSPF Link-Local Signaling 2007/03/01 Obsoleted by RFC 5613 EXPERIMENTAL
RFC 4812 OSPF Restart Signaling 2007/03/01   INFORMATIONAL
RFC 4811 OSPF Out-of-Band Link State Database (LSDB) Resynchronization 2007/03/01   INFORMATIONAL
RFC 4750 OSPF Version 2 Management Information Base 2006/12/01 Obsoletes RFC 1850 PROPOSED STANDARD
RFC 4577 OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) 2006/06/01 Updates RFC 4364 PROPOSED STANDARD
RFC 4552 Authentication/Confidentiality for OSPFv3 2006/06/01   PROPOSED STANDARD
RFC 4222 Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance 2005/10/01   BEST CURRENT PRACTICE
RFC 4203 OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) 2005/10/01 Updates RFC 3630 PROPOSED STANDARD
RFC 4167 Graceful OSPF Restart Implementation Report 2005/10/01   INFORMATIONAL
RFC 4136 OSPF Refresh and Flooding Reduction in Stable Topologies 2005/07/01   INFORMATIONAL
RFC 4063 Considerations When Using Basic OSPF Convergence Benchmarks 2005/04/01   INFORMATIONAL
RFC 4062 OSPF Benchmarking Terminology and Concepts 2005/04/01   INFORMATIONAL
RFC 4061 Benchmarking Basic OSPF Single Router Control Plane Convergence 2005/04/01   INFORMATIONAL
RFC 3883 Detecting Inactive Neighbors over OSPF Demand Circuits (DC) 2004/10/01 Updates RFC 1793 PROPOSED STANDARD
RFC 3630 Traffic Engineering (TE) Extensions to OSPF Version 2 2003/09/01 Updates RFC 2370, Updated by RFC 4203 PROPOSED STANDARD
RFC 3623 Graceful OSPF Restart 2003/11/01   PROPOSED STANDARD
RFC 3509 Alternative Implementations of OSPF Area Border Routers 2003/04/01   INFORMATIONAL
RFC 3166 Request to Move RFC 1403 to Historic Status 2001/08/01   INFORMATIONAL
RFC 3137 OSPF Stub Router Advertisement 2001/06/01   INFORMATIONAL
RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option 2003/01/01 Obsoletes RFC 1587 PROPOSED STANDARD
RFC 2844 OSPF over ATM and Proxy-PAR 2000/05/01   EXPERIMENTAL
RFC 2740 OSPF for IPv6 1999/12/01 Obsoleted by RFC 5340 PROPOSED STANDARD
RFC 2676 QoS Routing Mechanisms and OSPF Extensions 1999/08/01   EXPERIMENTAL
RFC 2370 The OSPF Opaque LSA Option 1998/07/01 Obsoleted by RFC 5250, Updated by RFC 3630 PROPOSED STANDARD
RFC 2329 OSPF Standardization Report 1998/04/01   INFORMATIONAL
RFC 2328 OSPF Version 2 1998/04/01 Obsoletes RFC 2178, Updated by RFC 5709 STANDARD
RFC 2178 OSPF Version 2 1997/07/01 Obsoletes RFC 1583, Obsoleted by RFC 2328 DRAFT STANDARD
RFC 2154 OSPF with Digital Signatures 1997/06/01   EXPERIMENTAL
RFC 1850 OSPF Version 2 Management Information Base 1995/11/01 Obsoletes RFC 1253, Obsoleted by RFC 4750 DRAFT STANDARD
RFC 1793 Extending OSPF to Support Demand Circuits 1995/04/01 Updated by RFC 3883 PROPOSED STANDARD
RFC 1765 OSPF Database Overflow 1995/03/01   EXPERIMENTAL
RFC 1745 BGP4/IDRP for IP---OSPF Interaction 1994/12/01   HISTORIC [pub as:PROPOSED STANDARD]
RFC 1587 The OSPF NSSA Option 1994/03/01 Obsoleted by RFC 3101 PROPOSED STANDARD
RFC 1586 Guidelines for Running OSPF Over Frame Relay Networks 1994/03/01   INFORMATIONAL
RFC 1585 MOSPF: Analysis and Experience 1994/03/01   INFORMATIONAL
RFC 1584 Multicast Extensions to OSPF 1994/03/01   HISTORIC [pub as:PROPOSED STANDARD]
RFC 1583 OSPF Version 2 1994/03/01 Obsoletes RFC 1247, Obsoleted by RFC 2178 DRAFT STANDARD
RFC 1403 BGP OSPF Interaction 1993/01/01 Obsoletes RFC 1364 HISTORIC [pub as:PROPOSED STANDARD]
RFC 1370 Applicability Statement for OSPF 1992/10/01   HISTORIC [pub as:PROPOSED STANDARD]
RFC 1364 BGP OSPF Interaction 1992/09/01 Obsoleted by RFC 1403 PROPOSED STANDARD
RFC 1253 OSPF Version 2 Management Information Base 1991/08/01 Obsoletes RFC 1252, Obsoleted by RFC 1850 PROPOSED STANDARD
RFC 1252 OSPF Version 2 Management Information Base 1991/08/01 Obsoletes RFC 1248, Obsoleted by RFC 1253 PROPOSED STANDARD
RFC 1248 OSPF Version 2 Management Information Base 1991/07/01 Obsoleted by RFC 1252, Updated by RFC 1349 PROPOSED STANDARD
RFC 1247 OSPF Version 2 1991/07/01 Obsoletes RFC 1131, Obsoleted by RFC 1583, Updated by RFC 1349 DRAFT STANDARD
RFC 1246 Experience with the OSPF Protocol 1991/07/01   INFORMATIONAL
RFC 1245 OSPF Protocol Analysis 1991/07/01   INFORMATIONAL
RFC 1131 OSPF specification 1989/10/01 Obsoleted by RFC 1247 PROPOSED STANDARD
Note: Grayed out RFCs have been obsoleted.

See also


  1. ^ a b Moy, J. (April 1998). [RFC 2328 "OSPF Version 2"]. The Internet Society. RFC 2328. Retrieved 2007-09-28. 
  2. ^ a b Coltun, R.; D. Ferguson, J Moy, A. Lindem (July 2008). [RFC 5340 "OSPF for IPv6"]. The Internet Society. RFC 5340. Retrieved 2008-07-23. 
  3. ^ RFC 1584, Multicast Extensions to OSPF, J. Moy, The Internet Society (March 1994)
  4. ^ Hawkinson, J; T. Bates (March 1996). "Guidelines for creation, selection, and registration of an Autonomous System". Internet Engineering Task Force. Retrieved 2007-09-28. 
  5. ^ Katz, D; D. Yeung (September 2003). [RFC 3630 "Traffic Engineering (TE) Extensions to OSPF Version 2"]. The Internet Society. RFC 3630. Retrieved 2007-09-28. 
  6. ^ Rajagopalan, B; J. Luciani & D. Awduche (March 2004). [RFC 3717 "IP over Optical Networks: A Framework"]. Internet Engineering Task Force. RFC 3717. Retrieved 2007-09-28. 
  7. ^ RFC 2328, page 75
  8. ^
  9. ^ | GateD R3_5_6 OSPF Copyright
  10. ^ OSPF Test Tool
  11. ^ Berkowitz, Howard (1999), "OSPF Goodies for ISPs", North American Network Operators Group NANOG 17, Montreal, OSPFforISPs, 
  12. ^ Katz, Dave (2000), "OSPF and IS-IS: A Comparative Anatomy", North American Network Operators Group NANOG 19, Albuquerque, OSPFvsISIS, 

Further reading

External links


Got something to say? Make a comment.
Your name
Your email address