Previous: The LS Protocol, Up: Using Verkkoke as Student



3.3 Routing Table Submission

The student's client sends its routing table to the server using a separate submission protocol which uses TCP. The server then compares the submitted routing table with the routing table of the student's node in the simulation.

The submission protocol advances as follows:

First, the client sends the authentication message. The server responds with the message AUTH_OK. Then, the client sends its routing table in this format: x,y,z;x,y,z;...;x,y,z;, where x is the name of a destination (router), y is the distance to that destination, and z is the number of the interface, through which the destination is reached. Each routing table row ends with a semicolon (;). The server responds with a message of the form SUBMISSION OK, feedback, or SUBMISSION FAILED, reason, if the routing table message was invalid or there was some internal error. Finally, the server closes the TCP connection.

The requirements for the submitted routing table are different for the DV protocol and the LS protocol. The difference is that for the LS protocol, if there are multiple shortest paths (of equal cost) with different next hops (and thus different interface ids) for a destination, the routing table must contain an entry for each of these options. This is called Equal Cost Multipath (ECMP) routing. ECMP is required so that the student can demonstrate that the algorithm used in the client finds all the shortest paths. In real-world routing, ECMP can be used for load balancing. ECMP is supported by OSPF. ECMP is not required with the DV protocol, however. The ECMP requirement in the LS protocol also serves to balance the difficulty of implementing the two protocols, since the DV protocol involves implementing stop-and-wait ARQ, whereas the LS protocol just uses TCP.

The submission server compares the submitted routing table with the routing table of the student's node in the simulation. The simulation table contains all ECMP entries. The feedback to the student consists of a score (passed/failed) and the number of incorrect or missing routing table destinations. The submission server sends this information to the student's client. The result can later be accessed through the LMS, on the result page.