OSPFD Release 2.0
Release 2.x of the OSPFD software contains support
for OSPF Opaque-LSAs. It is built upon patch 1.28. The differences
between 1.28 and 2.0 have been captured in
diff file format.
The current 2.x release can be downloaded
gzipped tar format.
The above gzipped tar file contains all patches currently available.
However, if you want to see the list of patches that have been made to
2.0, each in a separate diff file, click
Additions to the OSPFD API
bool OSPF::adv_link_opq(int phyint, InAddr ifaddr, lsid_t lsid, byte *body, int blen, bool adv)
bool OSPF::adv_area_opq(aid_t a_id, lsid_t lsid, byte *body, int blen, bool adv)
void OSPF::adv_as_opq(lsid_t lsid, byte *body, int blen, bool adv)
void OSPF::register_for_opqs(int conn_id, bool disconnect)
bool OSPF::get_next_opq(int conn_id, int &phyint, InAddr &if_addr,
aid_t &a_id, struct LShdr * &hdr)
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 (
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
phyint my be left unspecified
(set equal to -1) on numbered interfaces. If the router does not have a
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.
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
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,
is returned. When returning the next Opaque-LSA, the LSA's scope is indicated
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
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
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.