The baseline model contains 20 campuses that form a ring. Shortcuts between these campuses are available for those campuses that are 4 and 10 hops apart. Each campus comes with a total of 508 hosts and 30 routers. 4 of the hosts are running TCP and UDP server applications. The rest 504 hosts are running client applications, either TCP or UDP. One of the routers is running BGP for inter-domain routing (between campuses), the rest of the routers are running OSPF. In total, the entire network has 10,080 client hosts, 80 server hosts, and 600 routers.
Here's a tar ball of all required DML files need to run for both Java SSFNet and DaSSFNet: baseline20x500.tgz. When you untar the file, it'll create a directory called baseline. The DML files are located in that directory and the sub-directory called 20-campuses.
The three DML files in the 20-campuses directory describe the top-level network topology. They are baseline20x500tcp.dml, baseline20x500udp.dml, and baseline20x500tcpudp.dml. They correspond to three types of traffic: one for pure TCP traffic, one for pure UDP, and one being a mixture of the two. In case of pure TCP or pure UDP, the 504 clients on one campus are all trying to retrieve a file of 50KB in size from the 4 servers on the campus next to it in the ring. In case of mixed TCP and UDP traffic, TCP clients are connecting to servers on the next campus; UDP clients are connecting to servers on the campus three hops away down the ring. Each campus has 264 TCP clients and 240 UDP clients.
Let's look at baseline20x500.dml as an example. The top-level Net first defines traffic load of the model:
Net [
traffic [
pattern [
client 10
servers [list "forTCP" port 10 nhi_range [from 11:1:2(0) to 11:1:5(0)]]
]
pattern [
client 11
servers [list "forTCP" port 10 nhi_range [from 12:1:2(0) to 12:1:5(0)]]
]
...
pattern [
client 29
servers [list "forTCP" port 10 nhi_range [from 10:1:2(0) to 10:1:5(0)]]
]
]
...
]
The first traffic pattern specifies that the TCP clients in the sub-network 10 should talk to the servers in the first sub-network within sub-network 11 (i.e. 11:1). They are hosts with ids from 2 to 5. The servers are listening on interface 0 and port 10. The rest of the traffic patterns can be explained similarly. As we mentioned earlier, the TCP clients on a campus are connecting to the servers on a campus next to it in the ring.
Next, the 20 campuses are defined as sub-networks of the top-level network. Their ids range from 10 to 29. All these sub-networks are defined elsewhere (in networks.dml). The DML only specifies that the attributes of the sub-networks should extend ".networks.campus504tcp.Net". We'll look at the sub-networks in detail in the next section.
Net [
traffic [ ... ]
Net [id 10 _extends .networks.campus504tcp.Net]
Net [id 11 alignment "s1" _extends .networks.campus504tcp.Net]
...
Net [id 29 alignment "s19" _extends .networks.campus504tcp.Net]
...
]
The alignment attributes are used to assign a different timeline to each of the sub-networks. SSFNet support simulation on parallel architectures. A timeline is an independent simulation module capable of running on a different processor. This model divides the entire network into 20 timelines, each with a separate campus. In DaSSFNet, we are able to run this model on a 20-workstation cluster.
In the end, links are defined to connect these campuses:
Net [
...
# ring links
link [attach 10:0:0(3) attach 11:0:0(4) _find .params.as2as.delay]
link [attach 11:0:0(3) attach 12:0:0(4) _find .params.as2as.delay]
...
link [attach 29:0:0(3) attach 10:0:0(4) _find .params.as2as.delay]
# cross links
link [attach 10:0:0(5) attach 20:0:0(5) _find .params.as2as.delay]
link [attach 12:0:0(5) attach 22:0:0(5) _find .params.as2as.delay]
link [attach 14:0:0(5) attach 24:0:0(5) _find .params.as2as.delay]
link [attach 16:0:0(5) attach 26:0:0(5) _find .params.as2as.delay]
link [attach 18:0:0(5) attach 28:0:0(5) _find .params.as2as.delay]
# pentagon links
link [attach 10:0:0(7) attach 14:0:0(6) _find .params.as2as.delay]
link [attach 14:0:0(7) attach 18:0:0(6) _find .params.as2as.delay]
link [attach 18:0:0(7) attach 22:0:0(6) _find .params.as2as.delay]
link [attach 22:0:0(7) attach 26:0:0(6) _find .params.as2as.delay]
link [attach 26:0:0(7) attach 10:0:0(6) _find .params.as2as.delay]
]
The links can be classified into three groups. The first group of links connect the campuses adjacent to each other in the ring. As we see later, there is one border router within each campus running both BGP and OSPF. For example, the NHI address of the router in sub-network 10 is "10:0:0". For each pair of adjacent campuses, the border routers are connected together: interface 3 of one border router is linked with interface 4 of the next. The delay for a packet to be transferred via the link is defined elsewhere and pointed to using _find (in params.dml). The second group of links connect campuses that are 10 hops apart. The third group are for campuses 4 hops apart.
The networks.dml file specifies the campus network. It is defined methodologically in hierarchy. At the top level, it specifies that the campus network extends common definitions described in ".networks.campus504". Also, the campus contains two other sub-networks 2 and 3.
networks [
campus504tcp [
Net [ _extends .networks.campus504
Net [id 2 _extends .networks.network2tcp.Net]
Net [id 3 _extends .networks.network3tcp.Net]
]
]
...
]
The attribute ".network.campus504" defines two more sub-networks 0 and 1, and two routes 4 and 5, which are used to route traffic from the four sub-networks. The links are also defined to connect these four sub-networks and and the two routers.
networks [
...
campus504 [
...
Net [id 0 _extends .networks.network0.Net]
Net [id 1 _extends .networks.network1.Net]
# router between net 0 and net 2
router [ id 4
interface [ id 0 _extends .params.as2as.interface ]
interface [ id 1 _extends .params.as2as.interface ]
interface [ id 2 _extends .params.r2r.interface ]
interface [ id 3 _extends .params.r2r.interface ]
...
]
# router between net 0 and net 3
router [ id 5
interface [ id 0 _extends .params.as2as.interface ]
interface [ id 1 _extends .params.r2r.interface ]
interface [ id 2 _extends .params.r2r.interface ]
interface [ id 3 _extends .params.as2as.interface ]
...
]
link [attach 4(1) attach 5(3) _find .params.r2r.delay]
# links from backbone net 0 to routers 4, 5, 1:0
link [attach 0:0(2) attach 4(0) _find .params.r2r.delay]
link [attach 0:1(1) attach 5(0) _find .params.r2r.delay]
link [attach 0:2(0) attach 1:0(3) _find .params.r2r.delay]
# links to connect router 4 to net 2
link [attach 4(2) attach 2:1(0) _find .params.r2r.delay]
link [attach 4(3) attach 2:0(0) _find .params.r2r.delay]
# links to connect router 5 to network3
link [attach 5(2) attach 3:0(0) _find .params.r2r.delay]
link [attach 5(1) attach 3:1(0) _find .params.r2r.delay]
]
...
]
We're not going to explain further how these four sub-networks are configured. You'll notice that network 0 is used as the backbone to connect the other three networks. Network 1 is a server farm. It contains two routers and four hosts running TCP server. Network 2 and 3 are client networks: one with 7 routers and 7 sub-networks, the other with 4 routers and 5 sub-networks. Each sub-network comes with four local area networks and a total of 42 hosts.
There are four types of protocol graphs defined. The first type is the protocol graph used as TCP servers (in network 0). The protocol graph contains protocol session including IP, TCP, Socket, and the TCP server application. There are four such hosts per campus. The protocol graph is extended from the TCPserver attribute:
TCPserver [
interface [ id 0 _extends .params.as2as.interface]
graph [
ProtocolSession [
name TCPserver use SSF.OS.TCP.test.tcpServer
port 10
_find .params.queue_limit
_find .dictionary.TCPsession.request_size
_find .dictionary.TCPsession.show_report
_find .dictionary.TCPsession.debug
]
ProtocolSession [name socket use SSF.OS.Socket.socketMaster]
ProtocolSession [name tcp use SSF.OS.TCP.tcpSessionMaster
_find .params.tcpinit]
ProtocolSession [name ip use SSF.OS.IP]
]
]
The second type is the protocol graph used for TCP clients. There are 504 client hosts for each campus. The protocol graph for TCP client is almost the same as that for TCP server, except that the application is running a TCP server protocol:
TCPclient [
interface [ id 0 _extends .params.lan.interface]
graph [
ProtocolSession [
name TCPclient use SSF.OS.TCP.test.tcpClient
_find .params.start_time # earliest time to send request to server
_find .params.start_window # send request to server at randomly chosen time
# in interval [start_time, start_time+start_window]
_find .dictionary.TCPsession.request_size
_find .dictionary.TCPsession.show_report
_find .dictionary.TCPsession.debug
server_list "forTCP" # identifies server list(s) name in traffic pattern
_find .params.file_size # requested file size (payload bytes)
error_recovery true
]
ProtocolSession [name socket use SSF.OS.Socket.socketMaster]
ProtocolSession [name tcp use SSF.OS.TCP.tcpSessionMaster
_find .params.tcpinit]
ProtocolSession [name ip use SSF.OS.IP]
]
]
The third type of protocol graph is for the routers internal to the campus network. There are 29 such routers in total per campus network. These routers are running the OSPF protocol on top of IP:
IR [graph [
ProtocolSession [name ospf use SSF.OS.OSPF.sOSPF]
ProtocolSession [name ip use SSF.OS.IP]
]]
The last type of protocol graph is for the border router that connects to other campuses. There is only one such router per campus. The router is running both OSPF and BGP protocols. Since BGP uses TCP sockets, the protocol graph also contains Socket and TCP protocols as well.
ASBR [
graph [
ProtocolSession [ name bgp use SSF.OS.BGP4.BGPSession ]
ProtocolSession [ name ospf use SSF.OS.OSPF.sOSPF ]
ProtocolSession [ name socket use SSF.OS.Socket.socketMaster ]
ProtocolSession [ name tcp use SSF.OS.TCP.tcpSessionMaster ]
ProtocolSession [ name ip use SSF.OS.IP ]
]
]