Figure 5 - Modified test setup for test case 2.21
Since some features like virtual links or authentication are not needed in the OSPF implementation, these will not be implemented soon. Because of this it is not yet specified, how these features will be configured in DML. Therefore, the DML configurations for the according test cases can also not yet be prepared and are not considered in the following sections. However, no basic functionality of OSPF depends on these features.
Most of the test cases for the Hello Protocol can be implemented with standard SSFNet components and the UnreliableIP class to take links up and down. The only exception to this is test 1.10, which verifies, that no adjacency can be formed, when the neighbors do not agree on certain parameters in their hello packets. One of these parameters is the network mask, which cannot be modified directly in SSFNet, since IP neworks (and the associated configuration) are assigned automatically. The IPwithErrorInjection class is used here to modify the Netmask field in all hello packets of one of the routers.
Test case 1.11 is a special case as well. When two routers do not agree about the network they are connected to (i.e. the network masks are the same, but the network addresses indicate another network), no adjacency may be formed. Because of SSFNet's automatic IP address assignment, this class of errors will never occur. All interfaces connected to the same link are always configured properly. Therefore this test will pass implicitly.
On multiaccess networks not every two routers form an adjacency. Test 2.1 is used to verify the correct building of adjacencies in these networks. Since multiaccess networks are not yet available, this test cannot be performed yet.
Test case 2.3 tests, how a router behaves, when the MTU field is not set correctly during the database description process. Since this value cannot be configured, it must be manipulated directly in the database description packets. For this, the IPwithErrorInjection class can be used.
When a router receives a self-originated LSA, that is newer than the instance of this LSA contained in its own link state database, it must originate a new instance of this LSA to keep the link state databases of all routers in the network consistent. This behavior is verified in test case 2.5. In order to do so, the router must be shut down, after it has synchronized its database with its neighbor. When the router is restarted it originates a new LSA, beginning with the InitialSequenceNumber (0x80000001). This is realized with the Reset class. To assure, that the LSA in the neighbor's database has a higher sequence number (indicating that it is newer), the link between both routers is taken down several times, everytime waiting for longer than RouterDeadInterval. This causes the adjacencies to be taken down and up again and assures, that new instances of the routers' LSAs are originated.
The first part of the test verifies, that the slave does not retransmit database description packets. The tester must be the master for this test (i.e. it must have a higher Router ID). The PacketGenerator drops all database description packets, that are coming from the OSPF session, but the initial one. This behavior can be activated using the name dd_retransmit1.
The second part of this test case (dd_retransmit2) is used to assure, that the slave properly retransmits its previous database description packet, when it receives a retransmission from the master. For this, the link state database of the tester must be filled with enough LSAs to fill at least four database description packets. This is done by connecting a network to the tester, which contains enough routers (see Section \ref{sec:implementation:dictionary}). Again, the tester is the master in the database description process. The PacketGenerator now simply drops the third database description packet coming from the RUT. After RxmtInterval, the OSPF session on the tester will retransmit its last packet to the RUT. This test implicitly verifies, that the master correctly retransmits database description packets after RxmtInterval, when it does not receive a packet from the slave.
An explicit test for this can be done, using the dd_retransmit3 behavior. This time, the tester must be the slave. All database description packets from the master but the first two packets are dropped. So the OSPF session on the tester only receives these first two packets. Since the slave must not retransmit any database description packets unless it receives a retransmission from the master, it does not send any packets after that.
The fourth part of this test verifies, that the slave retains its last database description packet for RouterDeadInterval after it receives the final packet from the master. For this test, the tester must again be the master. The PacketGenera\-tor waits for the last database description packet from the slave. Once, this packet is received, a timer is started, which expires after RouterDeadInterval. When the timer fires, the last database description packet is retransmitted to the slave. The slave must now retransmit its last packet in response. This test behavior is activated using the name dd_retransmit4 in the DML configuration of the tester.
When the options field in database description packets of a neighbor changes during the database description process, it must be aborted immediately and then be restarted. The PacketGenerator waits for the second database description packet from the neighbor. The options field of the database description packet, which is sent to the neighbor in response, is then manipulated.
The second test verifies, if a router correctly restarts the database exchange, when it receives an initial database description packet unexpectedly. For this, the PacketGenerator simply sets the Initial-bit in its third database description packet.
Whenever a database description packet is received during the database exchange process, which has a sequence number that is higher than expected, the database exchange must be restarted. To verify this, the PacketGenerator simply increases the sequence number of the third database description packet.
The fourth test step is used to verify, that a router correctly restarts he database exchange, when it receives a database description packet, which has the sequence number set too low. This is implemented in the PacketGenerator by decreasing the sequence number of the third database description packet.
The next test step verifies, that the database exchange is restarted, when the master does not claim to be the master anymore during the database exchange. For this, the tester must be the master during database exchange (i.e. it must have the higher router ID). When the neighbor sends its first non-initial database description packet, the PacketGenerator simply clears the Master-bit in its next database description packet.
When a router receives a database description packet more than RouterDeadInterval after the final database description packet has been sent, it must restart the database exchange process. So, after the final packet is received, the PacketGenerator starts a timer, which waits for 50 seconds. When this timer fires, an additional database description Packet is sent to the neighbor.
The seventh test step verifies, that the database exchange is restarted, when a router receives an LSA header with an unknown LS type in a database description packet. For this, the PacketGenerator adds a new LSA header with LS type 0x7F in its second Database Description packet.
The last test step verifies, that the database exchange is restarted, when a router receives a header of an AS-external LSA in a stub area. AS-external LSAs are not yet implemented in OSPF. Because of this, the according test behavior for the PacketGenerator is not yet implemented.
The first test step verifies, that a router properly retransmits requests for LSAs, that are not received within RxmtInterval. For this, the tester is connected to a network with 57 routers in order to have its link state database filled. After that it is connected to another router. During the database exchange it sends several database description packets full of LSA headers. These LSAs are then requested by the neighbor, but no updates for these LSAs are sent to the neighbor.
When a router receives updates for some of the requested LSAs, it must not retransmit requests for these LSAs anymore. This is verified in the second test step. The PacketGenerator is again connected to a network in order to fill its link state database. Again, the router is then connected to another router, which requests all LSAs. The PacketGennerator now drops all link state update packets but the first one, so some of the requested LSAs are sent to the neighbor.
The first test step verifies, that the database exchange is restarted, when a neighbor requests an LSA that is not in the router's link state database. For this, the PacketGenerator adds a header for an imaginary LSA to the first link state request packet sent to its neighbor.
In the second test step it must be verified, that a router restarts the database exchange process, when it receives an LSA that it has requested from its neighbor, but which is older than an instance of the same LSA, that is already contained in the router's link state database. To test this, the PacketGenerator sends an update for its own Router LSA after the adjacency has been brought up. This LSA instance has sequence number 0x80000105. Then the OSPF session is shut down for longer than RouterDeadInterval to bring the adjacency down. When the OSPF session is restarted, the PacketGenerator indicates during the database description process, that its Router LSA has sequence number 0x80000205. This causes the neighbor to request this LSA. When the tester sends an update for the LSA, a sequence number smaller than 0x80000105 is used.
After all routes have synchronized their databases, the link between TR and RUT is taken down. The PacketGenerator on the tester now sends an update for its router LSA, including an imaginary stub network, so RUT begins retransmitting this update to TR. After 20 seconds, the tester again announces an update for its router LSA, this time without the imaginary stub network. When RUT receives this update it must delete the old instance from its link state database.
Because of the early state of the OSPFv2 implementation, there are currently only router LSAs. Since most of the link state advertisement tests deal with the origination of different LSA types, most of these tests can not yet be performed. However, the DML configurations for these tests can be provided in a straightforward manner, using only standard SSFNet classes and the UnreliableIP class. Some of the test scenarios additionally require the use of the Configurator class to update link costs during the simulation. Since the test configurations are clear, the tests can be performed as soon as other LSA types become available. The tests dealing with router LSAs can also be performed only partially at the moment, since the only link types available at the moment are router links and stub network links. Again, the remaining tests can be performed as soon as the features are implemented in OSPF.
Tests number 3.13 and 3.14 are used to verify the correct use of area address ranges. Area address ranges can be used to help area border routers when originating summary LSAs. Multiple networks can so be combined and advertised together in a single summary LSA. Since SSFNet assigns IP addresses automatically, it is not easy to configure these address ranges from DML. Indeed, this problem will be solved, when summary LSAs are implemented. Until then, these tests can not yet be performed.
The process of building the routing table is done in several stages (see Section \ref{sec:ospf:calculation}). The first stage calculates the shortest path tree for an area using only router- and network-LSAs. The following stages add stub-networks, inter-area routes and AS-external routes. A closer look at the routing tests in the IOL test suite shows, that the basic calculation of the shortest path tree and the calculation of next-hops is not tested explicitly. Tests for these calclations have to be added, to assure, that a router properly calculates the routing table and the next-hop interfaces. A description of these additional tests can be found later in this Section.
In the later stages of the routing table calculation, summary-LSAs and AS-external LSAs are used. In the current release of OSPF these are not yet implemented. As a consequence, these stages of the routing table calculation are not implemented as well. As a consequence, the routing tests from the IOL test suite cannot be performed yet. Nevertheless, the DML configurations for these tests can be obtained from the test descriptions using the UnreliableIP, Reset and Configurator classes.
Again, many of the tests verify things that are not yet implemented in the current version of OSPF. Other tests are not applicable in the SSFNet environment at all, because behavior that is tested in these test cases can never occur in the SSFNet implementation of OSPF. Tests 5.9 to 5.13 are used to verify different "length" fields, such as the packet length, the number of LSAs contained in a packet or the number of links in a router LSA. In OSPF implementations for real routers, packets are transmitted as arrays of bytes, which may be of variable length. The different length fields are needed to determine, where a packet ends. But in SSFNet, packets are not byte arrays. Packets are objects in SSFNet. So, there is no need to determine where the packet ends. Lists of LSAs or LSA headers are also not byte arrays in SSFNet. They are contained in the packtes as vectors of LSAs. The number of LSAs is not saved explicitly in the packets but can be obtained through the use of appropriate methods of the Vector class. For the test suite, this means, that the class of errors that is tested by these test cases will never occur in the SSFNet implementation. So these test cases can be omitted.
All OSPF packets should have the IP precedence field to Internetwork Control (0xC0). This is validated by test 5.4. SSFNet implements only a subset of the IP standard, which is sufficient to simulate most scenarios. The IP precedence field is not implemented in SSFNet, so this test cannot be performed. Most of the other tests are used to test features of OSPF which are not yet implemented in the current version. This includes authentication and virtual links. These test cases cannot be performed yet.
Test number 5.8 verifies, if a router properly evaluates the checksums of LSAs. Since the checksum field is not yet provided by the LSA datastructure, a tester for this test case can not be implemented. Once checksums are implemented for LSAs, the IPwithErrorInjection class can be modified to support the manipulation of the checksums in all LSA headers in order to model this test behavior.
