OSPF::adv_link_opq(), OSPF::adv_area_opq() and OSPF::adv_as_opq() allow applications to inject Opaque-LSAs into the OSPF routing domain. Separate entry points are used for each Opaque flooding scope. Common to all flooding scopes, the Opaque-LSA's Link State ID (lsid, including 8 bit Opaque type and 24 bits of Opaque ID), a pointer to the Opaque-LSA's contents (body) and the length of same (blen), and whether the LSA should be advertised or flushed (adv), are specified as arguments. Other than the Link State ID, the OSPF Link State header is not passed through these API routines.

OSPF::adv_link_opq() is used to add a link-local scoped (LS type 9) Opaque-LSA. The link to which the LSA is added is specified by its physical interface number (phyint) and IP interface address (ifaddr). phyint my be left unspecified (set equal to -1) on numbered interfaces. If the router does not have a matching interface, false is returned.

OSPF::adv_area_opq() is used to add area-scoped (LS Type 10) Opaque-LSAs. The area to which the LSA is to be added is specified by its OSPF Area ID (a_id). If the specified area is not currently defined on the router, false is returned.

OSPF::adv_as_opq() is used to add global-scoped (LS Type 11, also called AS-scoped) Opaque-LSAs.

OSPF::register_for_opqs() and OSPF::get_next_opq() were added to enable applications to receive Opaque-LSAs originated by other routers. Together they implement a polled interface. An application calls OSPF::register_for_opqs() to inform OSPFD that it wants to get copies of Opaque-LSAs. Multiple applications can request copies of the Opaque-LSAs, with each application distinguished by the conn_id argument. Opaque-LSAs are then queued for the application. The application can get the Opaque-LSA on the top of the queue by calling OSPF::get_next_opq(). If there are no Opaque-LSAs awaiting delivery, false is returned. When returning the next Opaque-LSA, the LSA's scope is indicated by phyint and if_addr for link-local Opaque-LSAs, or by a_id for area-scoped Opaque-LSAs. A pointer to the Opaque-LSA (hdr) is given, starting with its link-state header. No filtering is done in the interface; all Opaque-LSAs are given to the application, including Opaque-LSAs originated by local applications (i.e., those running on the local router), even those originated by the application itself. Simple LSA refreshes are also handed to the applications, while flushes of an LSA are indicated by handing the application an LSA with age equal to MaxAge.

To inform OSPFD that copies of Opaque-LSAs are no longer desired, disconnect is set to true in a call to OSPF::register_for_opqs().

Using the updated API, the OSPFD monitoring interface described in Section 13.13 of OSPF Complete Implementation has been enhanced to enable uploading of Opaque-LSAs through the packetized TCP connection. The new query type MonReq_OpqReg requests Opaque-LSAs be delivered, and MonReq_OpqNext polls for next Opaque-LSA in the queue. This extension to the monitoring interface is used by the new Opaque-LSAs link in the OSPFD browser.

For more details on the OSPFD API, see Section 4.3 of OSPF Complete Implementation.

Summary of changes to OSPFD internals

• Changes required by the addition of link-level scoping.
• New data structures required for Opaque-LSAs.