OSPF is a link-state routing protocol that was developed as a replacement for the distance vector routing protocol RIP. RIP was an acceptable routing protocol in the early days of networking and the Internet, but its reliance on hop count as the only measure for choosing the best route quickly became unacceptable in larger networks that needed a more robust routing solution. OSPF is a classless routing protocol that uses the concept of areas for scalability. RFC 2328 defines the OSPF metric as an arbitrary value called cost. The Cisco IOS uses bandwidth as the OSPF cost metric.
The initial development of OSPF began in 1987 by the Internet Engineering Task Force (IETF) OSPF Working Group. At that time the Internet was largely an academic and research network funded by the U.S. government.
In 1989, the specification for OSPFv1 was published in RFC 1131. There were two implementations written: one to run on routers and the other to run on UNIX workstations. The latter implementation later became a widespread UNIX process known as GATED. OSPFv1 was an experimental routing protocol and never deployed.
In 1991, OSPFv2 was introduced in RFC 1247 by John Moy. OSPFv2 offered significant technical improvements over OSPFv1. At the same time, ISO was working on a link-state routing protocol of their own, Intermediate System-to-Intermediate System (IS-IS). Not surprisingly, IETF chose OSPF as their recommended IGP (Interior Gateway Protocol).
In 1998, the OSPFv2 specification was updated in RFC 2328 and is the current RFC for OSPF.
Note: In 1999 OSPFv3 for IPv6 was published in RFC 2740. RFC 2740 was written by John Moy, Rob Coltun, and Dennis Ferguson. OSPFv3 is discussed in CCNP.
OSPF Packet Type
The figure shows the five different types of OSPF LSPs. Each packet serves a specific purpose in the OSPF routing process:
1. Hello – Hello packets are used to establish and maintain adjacency with other OSPF routers. The hello protocol will discuss in detail on the next post.
2. DBD – The Database Description (DBD) packet contains an abbreviated list of the sending router’s link-state database and is used by receiving routers to check against the local link-state database.
3. LSR – Receiving routers can then request more information about any entry in the DBD by sending a Link-State Request (LSR).
4. LSU – Link-State Update (LSU) packets are used to reply to LSRs as well as to announce new information. LSUs contain seven different types of Link-State Advertisements (LSAs). LSUs and LSAs are briefly discussed in a later topic.
5. LSAck - When an LSU is received, the router sends a Link-State Acknowledgement (LSAck) to confirm receipt of the LSU.