The Open Shortest Path First (OSPF) protocol is an IP link-state routing protocol, recommended for distributing routing information among the routers in a single autonomous system (AS), with explicit support for classless inter-domain routing (CIDR) address allocation.
SSF.OS.OSPF is a partial implementation of OSPFv2, based on the Internet Engineering Task Force's Request for Comments number 2328 (RFC 2328), "OSPF Version 2" [1]. It is designed to quickly compute the routing tables for arbitrary topologies of OSPF areas in SSFNet network models, and to flood the area with external route announcements from the ASBR routers running the BGP-4 inter-domain routing protocol. The unsupported requirements involve dynamic neighbor discovery and link state updates in response to dynamic topology changes.
This implementation is referred to as sOSPF (static OSPF). See SSF.OS.OSPFv2 for the more complete implementation of OSPFv2 including the dynamic responses to routing topology changes.
sOSPF is a static version of OSPF which retrieves the adjacency information of all routers in the same AS directly from the underlying network topology database. It then forms the link state databases by retrieving the link properties, and subsequently invokes the shortest path algorithm to compute the routing tables. In this release each router maintains its own link state database. This arrangement permits simulations to be run in parallel (with multiple timelines). However, since all link state databases within an area are essentially identical, for the purpose of saving memory in a simulation it is possible to maintain a single shared link database per area, provided the updates from routers are carefully synchronized to avoid possible errors in a multi-timeline simulation. Such a solution can be provided in a future release.
In sOSPF version 0.1.14 only one area per AS is supported. However, sOSPF can accept dynamic AS external route information from inter-AS routing protocols, such as BGP. The routing table computed by an sOSPF ProtocolSession contains the entries for:
but it does not contain addresses of point-to-point networks between sOSPF
routers inside the area that are not directly attached to this router. That
does not affect routing of IP packets between hosts. See the OSPF/test/ directory for examples.
An sOSPF ProtocolSession accepts AS external routing information from inter-AS
routing protocols, such as BGP. These other protocols inject routing
information using the method sOSPF.acceptASExternalRoute(). Such
routes are inserted first into the link state database, as stipulated by RFC
2328. Then sOSPF.buildRoutingTable() is called, where Dijkstra's
algorithm is run again on the database, and the router's forwarding table is
updated.
This release has not yet been exercised under a sufficiently broad range of scenarios, and we would welcome ideas for additional tests to help establish a canonical test suite for all OSPF implementations.
1. Link Cost Specification in the network DML database
sOSPF permits arbitrary link cost values to be used. However, it does not yet
permit to specify the link costs directly in the network configuration DML
database. This will be provided in the next release.
2. Support for Multiple Areas
3. Broadcast, Non-Broadcast Networks, Designated Router and Backup Designated Router
OSPF can run on both broadcast and non-broadcast networks. Version 0.1.14
makes no such distinction. OSPF can run over non-broadcast networks in NBMA or
Point-to-MultiPoint mode. In NBMA mode, OSPF emulates operation over a
broadcast network: a Designated Router is elected for the NBMA network, and the
Designated Router originates an LSA for the network. NBMA mode is the most
efficient way for non-broadcast networks, but it requires all routers attached
to the NBMA network to be able to communicate directly. In Point-to-MultiPoint
mode, OSPF treats all router-to-router connections over the non-broadcast
network as if they were point-to-point links. No Designated Router is elected
for the network, nor is there an LSA generated for the network. In fact, a
vertex for the Point-to-MultiPoint network does not appear in the graph of the
link-state database. Refer to RFC 2328 sections 2.1.1, 7.3, and 7.4.
4. IP Multicast
IP multicast is not used in version 0.1.14. Refer to RFC 2328 section 4.4.
5. Neighbor State Machine
RFC 2318 goes into great length specifying the neighbor state machine, and the
neighbor states such as HelloReceived, Adjacent, Down. This is not needed in
the static version, but will be required in dynamic version. Refer to RFC 2328
section 10.3.
6. Representation of Type of Service
In the dynamic version the TOS informaton can be included in the router-LSAs,
summary-LSAs and AS-external-LSAs. However, they are not implemented in sOSPF
version 0.1.14. Refer to RFC 2328 section 12.3.
Archived Java source: http://www.ssfnet.org/ospf/
Modification history: OSPF/doc/HISTORY
SSFNet uses an interactive FAQ (the SSFNet Faq-O-Matic) which contains several answers to frequently asked questions about SSFNet and all of its components, including SSF.OS.OSPF. Users can also log in and post new questions, which others in the SSFNet modeling community can respond to by posting their own answers. The SSFNet Faq-O-Matic is located at http://www.cs.dartmouth.edu/research/ssfnet/faq/fom.cgi.
[2]
Routing in the Internet by Christian Huitema
SSF.OS.OSPF was originally authored by by Philip Kwok under the advisership of Andy Ogielski. Myongsu Choe implemented DML configurability, NHI addressing, and a number of bugfixes. BJ Premore collaborated throughout the project, and has taken over as maintainer and developer as of version 0.1.0. Validation tests were originally written by Philip Kwok and have been updated and modified by Myongsu Choe, Andy Ogielski, and BJ Premore.