January 29, 2003
In this document, we present a generalized packet switched network model. This model is composed of basic, abstract components extracted from the Internet, and hence the name Internetworking Simulation Platform (INET). Although the model is derived from the Internet, it is general enough to serve as a base model for other network architectures, such as the IETF Integrated/Differentiated Services architecture, the mobile wireless network architecture, and the WDM-based optical network architecture. We first present the core service layer, and discuss how we decompose the core service layer based on the ``arbitrary and complex protocol graphs with simple protocols'' concept for better module reuse. Then, we describe the implementation of INET in J-Sim, an implementation of the autonomous component architecture in Java.
We design the core service layer in compliance with the thin waist model of the protocol hour-glass, and include in the core service layer the most fundamental core services that should be provided to clients --- protocol modules in the protocol module layer. Services provided by the core service layer include
These services are defined in terms of contracts. A protocol module that uses the core services may own a port that is bound to the specific service contract. The protocol module is actually connected to the core service layer by wiring its port to the corresponding port of the core service layer only at system integration time.
As shown in Figure 1, a typical INET node is composed of the core service layer and one or more application and transport layer protocols. Note that applications and transport protocols are part of an end host but not part of routers inside the network.
Figure 1: The internal
structure of an INET node.
The data sending/delivery service consists of two contracts, one for each direction of data flows (upward or downward).
In addition to the packet forwarding and delivery services, the core service layer also exports a packet arrival event (see Exporting Information at Run Time) whenever a packet arrives at an upper or lower data port.
The core service layer maintains a list of identities, or addresses, of the node known by other nodes in the network. In INET, a unicast address is an identity owned by at most one node in the network, while a multicast address is an identity by which more than one node may be identified in the network. An upper layer protocol may look up and/or configure the identities of the node through the following two service contracts:
In addition to the lookup and configuration services, the core service layer exports an event (see Exporting Information at Run Time) whenever the set of identities changes. The changes include addition or removal of an identity, or modification of the timer associated with an identity.
The core service layer at each node maintains a routing table and, for each packet to be forwarded, looks up appropriate interfaces in the table, based on the source address, the destination address, and the incoming interface on which the packet arrived. An upper layer protocol may look up and/or configure the routing table through the following routing service contracts:
In addition, the core service layer exports an event (see Exporting Information at Run Time) whenever the routing table changes. The change includes addition, removal or modification, of an entry.
The core service layer maintains a database to keep the information of all the interfaces of the node. The information for an interface includes the local address , the addresses of the neighbors that can be reached on the interface, the size of the outgoing buffer, the bandwidth, the maximum transmission unit (MTU) and so on. The core service layer provides the services for upper layer protocols to retrieve the information, and to be notified of neighboring events, such as the neighbor-up event (the event that a new neighbor is discovered) and the neighbor-down event (the event that an existing neighbor is gone).
The neighboring information may be manually, statically configured into the core service layer. In this case, the core service layer exports all the neighbor-up events at node boot-up time. Alternatively, the core service layer may be instrumented to build the neighbor information and export the neighbor events dynamically (by running some generic Hello protocol).
Packet filters are conceptually the extensible part of the core service layer. Each interface of a node may contain a bank of packet filters. When the core service layer forwards a packet on an outgoing interface, the packet may go through a subset of packet filters in the bank before being placed in the outgoing buffer of the interface. When a packet arrives on an interface of a node, it may also traverse a (possibly different) subset of packet filters in the bank before being handed to the dispatching function of the core service layer. While different implementations of core service layer may have different sets of packet filters installed, all implementations should provide this configuration service for upper layer protocols to configure the installed packet filters.
In compliance with the four categories of services provided by the core service layer, we decompose the core service layer into five components (Figure 2): PacketDispatcher, Identify, RoutingTable, Hello, and PacketFilterSwitch (along with one or more extensible packet filter banks). The decomposition is grounded on the philosophy of the ``complex protocol graph and simple protocols''1,2 for better component reuse.
1 S. W. O'Malley and L. L. Peterson, "A
dynamic network architecture," ACM Trans. on Computer
Systems, Vol. 10, No. 2, pages 110-143, May 1992.
2 R. Morris, E. Kohler, J. Jannotti, and M.
F. Kaashoek, "The Click modular router," Proc. of 17th
ACM Symposium on Operating Systems Principles (SOSP'99),
December 1999.
In what follows, we discuss each of the components:
We lay out the generalized packet switched network model on top of ACA. This is done by defining generic network components and their contracts, with the intent to capture their fundamental features and yet allow flexibility to accommodate other technology advances. By virtue of the layered, component-based architecture with well-defined contracts, it is easy to extend the abstract network model to accommodate other network architectures, e.g., wireless LANs, optical networks with WDM technology, networks with satellite communication links, and/or ad hoc networks consisting primarily of mobile sensors.
Specifically, to model a network architecture, one need only to sub-class an appropriate generic component, and re-defines its attributes and/or methods for manipulating these attributes. For example, one needs only to modify the link and network interface card (NIC) components to incorporate the error characteristics of wireless links and the mobility characteristics of mobile subscribers in order to model a wireless mobile network. One possible module stack that can be derived from the abstract network model is depicted in Figure 3.
Figure 3: A possible module stack using the abstract network model.
Based on the INET abstract network model, we have implemented a network simulation environment on top of J-Sim/ACA. Building INET in such a component-based software architecture is a natural task. The concepts of service contracts and component decomposition in INET directly follow those in the software architecture.
We implement every component in INET as a class, and organized classes into layers. Figure 4 depicts the five-layer class organization in J-Sim.
Figure 4: The class pyramid in J-Sim.
The following table gives the algorithms/models currently supported or under development in J-Sim.
| Network Architecture | Application | Socket Layer | Transport | Routing | Traffic Model | Tagger Marker | Buffer Management | NI Scheduling | |
|---|---|---|---|---|---|---|---|---|---|
| Best Effect Services | FTP, FSP WWW |
Java Socket | TCP-Reno TCP-Tahoe TCP-Vegas TCP Sack UDP |
RIP (DV) OSPFv2 Multicast shortest path tree DVMRP CBT |
Drop-Tail | FIFO | |||
| Differentiated Services | Token Bucket TSW ETSW |
FIFO RED FRED SRED BRED |
Priority Queue, Weighted Round-robin, 3ColorQueue | ||||||
| Integrated Services | RSVP | Unicast QoS routing QoS-enhanced OSPFv2 QoS-enhanced CBT |
Periodic message (CBR) Peak rate model Leaky bucket model Token bucket model IETF/Intserv Flowspec (r,t)-smooth model (C,D)-smooth model |
RM EDF Stop-and-go DCTS VirtualClock LFVC SCFQ PGPS STQ WF2Q |
| FTP: file transfer protocol | FSP: file service protocol |
| TCP: transmission control protocol | RIP: routing information protocol |
| OSPF: open shortest path first | DVMRP: distance vector multicast routing protocol |
| CBT: core based tree protocol | FIFO: first in first out |
| TSW: time sliding window | ETSW: enhanced time sliding window |
| RED: random early drop | FRED: fair random early drop |
| SRED: stable random early drop | BRED: balanced random early drop |
| RSVP: Resource reservation protocol | CBR: constant bit rate |
| RM: rate monotonic | EDF: earliest deadline first |
| DCTS: distance constrained task system | LFVC: leap forward virtual clock |
| SCFQ: self-clocked fair queueing | PGPS: packet-by-packet generalized processing sharing |
| STQ: start time fair queueing | WF2Q: worst-case fair weighted fair queueing |
By virtue of the autonomous component architecture, INET supports hierarchical networks of arbitrary depth. Specifically, an internetwork consists of networks, nodes and (backbone) links. A network, in turn, contains nodes, links and networks of smaller sizes. The internetworking system itself is a network entity, and the ancestor of all entities contained in it.
To address nodes at different levels of the network hierarchy, INET uses the address allocation mechanism, called Classless Inter- Domain Routing (CIDR, or supernetting)3,4, to allocate numerical addresses to networks and nodes in the system. Succinctly speaking, CIDR uses variable length subnet masks to assign addresses in unbalanced hierarchical networks, where by an unbalanced network, we mean a network that contains at least two networks with unequal number of nodes. Due to the use of variable length subnet masks, we can achieve more efficient address assignment, meaning that the number of un-used addresses can be reduced, as compared to the traditional class-based address assignment.
3 Y. Rekhter and T. Li, "An
architecture for IP address allocation with CIDR," RFC 1518,
September 1993.
4 V. Fuller, T. Li, J. Y. Yu and K. Varadhan,
"Classless inter-domain routing (CIDR): an address
assignment and aggregation strategy," RFC 1519, September
1993.
In CIDR, a network is represented
by an address with a network mask in the format of <address>/<mask>,
where a network mask is an address that starts, in the binary form, with contiguous 1's
and followed by 0's thereafter. For
example, the network address 10xy/1100 with x, y in
[0,1] is equivalent to 1000/1100, and contains only the nodes
with addresses in the format of 10xy with x, y in
[0,1]. A network address can also be represented in the format of <address>/<number
of 1's>. For example, the above network address can also
be represented as 1000/2.
Example: Figure 5 (a) depicts a network system of 3 levels and totally 10 nodes. The system is unbalanced because net0 and net1 contain 6 and 3 nodes, respectively. If a straightforward address allocation method is used to allocate sufficient bits to each level of the network hierarchy, start from the first level, totally 6 bits are needed. This is done by (i) assigning 2 bits to the three immediate children node0, net0, and net1 of the system; (ii) going down one level and assigning 2 bits to the three immediate children of net0 and net1; and (iii) going down to one level further and assigning 2 bits to the two immediate children of net2 and the three immediate children of net3. A more efficient CIDR-based address assignment assigns a unique 4-bit address to each network and node for the same system. One such solution is given in Figure 5 (b).
|
||||||
Note that in the above example addresses are associated with node instead of with interfaces of a node. As a matter of fact, INET supports both per-node addressing and per-interface addressing. The way in which INET supports per-interface addressing is to allow assignment of multiple addresses to a node (see Node Identity Service).
~ END ~
