Net [
host [ id 1 interface [ id 1 ] ]
host [ id 2 interface [ id 1 ] ]
link [ attach 1(1) attach 2(1) ]
]
As you may have noticed, the model is described as a list of attributes defined within a Net attribute. Each host is identified by an id number. Within each host, there is an interface attribute representing the NIC. NICs are identified with numbers as well. The link attribute is used to describe the connection of the two hosts. It defines two attachment points. One attached to the interface named "1(1)", the other "2(1)". In SSFNet DML, we use so-called NHI addresses to refer to hosts, routers, and their interfaces. For example, "2(1)" means that it's interface No.1 in host No.2.
Now, let's put a router and two more hosts in this network. The hosts are connected using a Ethernet this time, instead of a direct cable. The router contains 2 NICs: one connects to the Ethernet and the other is expected to be connected to the outside world.
Net [
host [ id 1 interface [ id 1 ] ]
host [ id 2 interface [ id 1 ] ]
host [ id 3 interface [ id 1 ] ]
host [ id 4 interface [ id 1 ] ]
router [ id 5
interface [ id 1 ]
interface [ id 2 ]
]
link [
attach 1(1) attach 2(1) attach 3(1)
attach 4(1) attach 5(1)
]
]
Sometimes it becomes an inconvenience to describe all the hosts one by one. After all, they are the same in this model except the id number. One way to get rid of the repetition is to use the id_range attribute instead of id. The same rule applies to interfaces in a host or router. The following DML describes exactly the same model as the one above:
Net [
host [ id_range [ from 1 to 4 ] interface [ id 1 ] ]
router [ id 5
interface [ id_range [ from 1 to 2 ] ]
]
link [
attach 1(1) attach 2(1) attach 3(1)
attach 4(1) attach 5(1)
]
]
The above DML shows one small local area network with four hosts and one router. If we decide to expand the model with two sub-networks. The DML provides a very simple way of doing so:
Net [
Net [ id 1
host [ id_range [ from 1 to 4 ] interface [ id 1 ] ]
router [ id 5
interface [ id_range [ from 1 to 2 ] ]
]
link [
attach 1(1) attach 2(1) attach 3(1)
attach 4(1) attach 5(1)
]
]
Net [ id 2
host [ id_range [ from 1 to 4 ] interface [ id 1 ] ]
router [ id 5
interface [ id_range [ from 1 to 2 ] ]
]
link [
attach 1(1) attach 2(1) attach 3(1)
attach 4(1) attach 5(1)
]
]
link [ attach 1:5(2) attach 2:5(2) ]
]
As you see, we just make two copies of the previous defined network. We assign a unique network id to each of them. The outermost network does not need an id. In the end, we provide another link to connect these two sub-networks. The link comes with two attachment points. The NHI address "1:5(2)" means that it's the interface No.2 of the host No.5 in the sub-network No.1.
You can easily image how a large network model can be constructed in the above fashion. The NHI addressing scheme allows a network previous defined to become a subnet of a larger network. The entire network can be defined in a hierarchical way.
In the previous section, the DML is only used to define hosts, routers, their interfaces, and how they connect to each other. Without proper protocols running within these hosts and routers, the network doesn't do anything. Protocols running inside each host or routers are organized as a protocol stack. In SSFNet term, a protocol stack is a protocol graph, which consists of a number of protocol sessions.
In the following example, we make the four hosts in one subnet all running the same five protocols: IP, TCP, Socket, a TCP server. and a TCP client:
host [ id_range [ from 1 to 4 ] interface [ id 1 ]
graph [
ProtocolSession [ name TCPserver use SSF.OS.TCP.test.tcpServer ]
ProtocolSession [ name TCPclient use SSF.OS.TCP.test.tcpClient ]
ProtocolSession [ name socket use SSF.OS.Socket.socketMaster ]
ProtocolSession [ name tcp use SSF.OS.TCP.tcpSessionMaster ]
ProtocolSession [ name ip use SSF.OS.IP ]
]
]
The name attribute specifies a name of the protocol and the use attribute specifies the name of the class that implements the protocol. The order in which these protocols are defined in a host may or may not be important, depending on the implementation. In Java SSFNet, the order must be kept in such a way that protocols higher in the protocol stack must be listed first than those lower in the protocol stack. The order affects how the protocols are initiated: the initialization of a protocol may depend on the protocol below it in the protocol stack. The restrict is removed in DaSSFNet. One can define the protocols in any order.
The router defines the protocols it uses in the same fashion. Instead of running protocols like Socket, TCP client, and TCP server, the router replace them with routing protocols, such as BGP and OSPF:
router [ id 5 interface [ id_range [ from 1 to 2 ] ]
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 ]
]
]
Each protocol can be further configured with more attributes. For example, the TCP client must specify when it should starts sending request to the server, and what is the size of the request to be sent to the server, and what is the file size to be transferred from the server. On the other hand, the TCP server must know the port number it is servicing requests and agree with the request size. These parameters are listed together within the ProtocolSession attribute of the corresponding protocol:
graph [
ProtocolSession [
name TCPserver use SSF.OS.TCP.test.tcpServer
port 10 # port number
request_size 4 # client request message size (in bytes)
]
ProtocolSession [
name TCPclient use SSF.OS.TCP.test.tcpClient
start_time 1.0 # earliest time (seconds) to send one request to server
start_window 1.0 # send request to server at randomly chosen time
# in interval [start_time, start_time + start_window]
request_size 4 # client request message size (in bytes)
file_size 10000000 # requested file size (in bytes)
]
# other protocol sessions ...
]
The hardware of the network is configured nice and ready. Now, we need to add traffic to the model. This is done by providing a traffic attribute within the top-level Net. The traffic attribute contains a list of traffic patterns, each one describing a set of servers, using NHI addresses, the specified client or clients, also using NHI, should connect to.
In the example network model, we have two sub-networks, each with four hosts running both TCP server and client sessions. We make the clients in the first sub-network talk to the servers in the second sub-network, and vice versa:
Net [
traffic [
pattern [
client 1
servers [ port 10 nhi_range [ from 2:1(1) to 2:4(1) ] ]
]
pattern [
client 2
servers [ port 10 nhi_range [ from 1:1(1) to 1:4(1) ] ]
]
]
# the rest defines the two sub-networks ...
]
The first traffic pattern says that all clients defined in the sub-network No.1 should talk to the servers that fit the given description. The servers are all listening to port 10. The servers' IP addresses should correspond to the NHI addresses of the given range. In this case, they're the first interface of host 1 to 4 in the sub-network No.2.
This section only describes major features of the DML used for configuring a network model. For more information, we strongly recommend the reader to continue with the Network Configuration Tutorial, at www.ssfnet.org, which provides a more detailed description.