Advanced OSPF Features

This section introduces traffic-engineering (TE) extensions to OSPF, opaque LSA types, and a specialty of the Quagga OSPF implementation: the OSPF application programming interface (API).

Traffic-Engineering Extensions

The issue of TE extensions to link-state routing protocols has largely been driven by enthusiastic adoption of the MPLS paradigm. Nowadays, TE extensions are strongly related to MPLS-TE.

To be able to set up LSPs (MPLS label-switched paths) to forward similar traffic belonging to forwarding equivalence classes (FECs), traditional link information stored in an LSDB has proven inadequate and insufficient. Therefore, TE extensions were developed for OSPF and IS-IS, which led to the notion of OSPF-TE and IS-IS (TE). The extended TE topology (link bandwidth and administrative constraints) results in the population of a separate TE-LSDB and the deployment of the extended CSPF (constrained SPF) algorithm for computation. TE introduces additional issues and difficulties at area boundaries as well as increased computation burden on OSPF nodes.

Opaque LSAs

The vehicles used to accommodate the new sets of information discussed in the previous section are opaque LSAs (LSA Type 9,10,11) for OSPF (RFC 2370) and sub-TLVs for IS-IS, which serve the same purpose. This topological knowledge forms the basis for two signaling alternatives, CR-LDP and RSVP-TE, to establish end-to-end unidirectional TE circuits (LSPs in MPLS notation).

The preceding explanation of opaque LSAs is extremely high level, but it is enough to put things into perspective and to sufficiently understand why there exists an MPLS-TE feature for the Zebra ospfd. Early versions of RSVP-TE, CR-LDP, and LDP exist for Linux and some other open-source operating systems. There exist similarities as well as fundamental differences to policy routing approaches.

Opaque LSAs per se are a flexible and generic vehicle to disseminate arbitrary information by flooding mechanisms, because the payload information contained in these LSA types is completely transparent for the OSPF routing process. According to RFC 2370, "The link-state type field of the opaque LSA identifies the LSA's range of topological distribution. This range is referred to as the flooding scope." These LSAs can be picked up and processed by other modules such as MPLS-TE or dedicated applications such as SRRD (Service Routing Redundancy daemon).

Quagga's Implementation

Quagga's OSPF implementation is flexible and supports both opaque LSAs and OSPF-TE. The capability opaque configuration statement in the ospfd router configuration section indicates this. In addition, the OSPF LSDB of the OSPF daemon can be accessed via a generic interface, the OSPF API.

Besides LSDB access, the API allows origination and dissemination of opaque LSAs and hence provides an interface to arbitrary payload information contained within opaque LSAs. Figure 9-4 demonstrates the architecture (courtesy of Dr. Ralph Keller of the Swiss Federal Institute of Technology). The OSPF API itself consists of a client and server module and is capable of dealing with concurrent client requests. It can retrieve and originate opaque LSAs.

The SRRD uses the opaque LSAs to manage cluster resources based on proven OSPF signaling concepts and timers in contrast to conventional unicast or multicast heartbeat approaches or proprietary cluster management. This results in failover times of less than 30 seconds and significantly improves availability of multi-interface nodes, because a cluster constituent is available as long as one of its interfaces is reachable, thanks to OSPF.

According to my correspondence with SRRD's author, Amir Guindehi, "SRRD uses opaque LSAs for service discovery (member service), service selection, as well as service state and configuration flooding. It then creates service routes by conventional means (interface aliases plus OSPF host routes) using these for service routing to the active node."^[3] Therefore, the cluster nodes can be distributed over an entire OSPF domain and even span WANs, which greatly improves redundancy in terms of single-site disasters. This is an especially intriguing concept if OSPF is your choice of IGP anyway; just enable opaque LSAs in Quagga at compile time. Cisco IOS Software supports opaque LSAs as well.