[ Up ] [ Proposal ] [ Current Status ] [ Previous Status ]

Quality of Service for Communications Networks Status Report - 2nd Quarter, 1999

Network Management  - S. Keshav

We have made substantial progress on our goals in the last quarter. Here, we summarize our achievements in two of our research areas: network simulation and network discovery.

Network Simulation:

We have designed and implemented the Simphony protocol development environment. Figure 1 outlines the architecture of the system. At the top level, Simphony can be viewed as a process that runs entirely in user space, and can interact both with other processes and with physical network interfaces. Its switch box component listens for commands and supplies status information. Developers connect to the switch box with a telnet connection to give configuration commands in a simple language. The switch box also generates status and monitoring information for use by an external visualization engine.

The Simphony process supports multiple Virtualized Networking Kernels (VNKs). Each VNK (pronounced ‘vink’) exactly implements the networking services found in the 4.4 BSD kernel. Multiple virtualized processes can run on each VNK. Each virtualized process carries out a user-level protocol and redirects its system calls to the VNK. VNKs can be connected using wires that represent communication links. Examples of wires are Ethernet busses and point-to-point links. The final abstraction in Simphony is that of an external process. An external process is not virtualized, but is able to communicate both with virtualized processes and with other external processes by means of a proxy process.

From a developer’s perspective, Simphony provides the abstraction of a ‘network in a box’. Each VNK corresponds to a machine on the Internet, and each virtualized process corresponds to a process running on that machine. Since Simphony can support several thousand VNKs, developers can work with large topologies when developing and testing protocols. A developer can instantiate new protocols either directly on a VNK, or as an external process, and test its behavior when interacting with other network protocols already implemented within Simphony. Note that because Simphony is entirely in user space, a developer with access to the source code can monitor or modify any aspect of the entire protocol stack without having to make any changes to the kernel.

While Simphony is written in C++, it can interoperate with Java applets. A Java interface component links calls in the net class to a proxy virtualized process. This allows all Java applications to use the Simphony infrastructure with no change.

Finally, Simphony can directly control a physical network device through a VNK. Simphony therefore interfaces seamlessly with all Internet protocols at layer 3 and above. For example, if we connect a machine running Simphony to another, unmodified machine using an Ethernet hub, the unmodified machine cannot distinguish between packets forwarded among Simphony VNKs and packets forwarded on the Internet. Thus, a program like traceroute can be used to find the path to a destination within a simulated network, and an HTTP server running within Simphony can be used to serve web pages to a browser running on an external machine. We can also use this interface to link multiple simphony processes together, allowing us to emulate large topologies.

Network discovery:

In large and constantly evolving networks, it is difficult to determine how the network is actually laid out. Yet this information is invaluable for network management, simulation, and server siting. Traditional topology discovery algorithms are based on SNMP, which is not universally deployed. We have developed several heuristics and algorithms to discover both intra-domain and Internet backbone topology while making as few assumptions about the network as possible. We quantitatively evaluated their performance and also came up with a new technique for visualizing Internet backbone topology. An example of a discovered topology is a small fraction of the NYSERNET backbone shown below. An interactive viewer for this topology can be found at http://www.cs.cornell.edu/cnrg/topology/nysernet/index.html.

As is evident, displaying backbone topology is difficult because of the large number of nodes. Therefore, we have come up with a visualization technique called a hop contour map that summarizes topology information. Intuitively, a hop contour map shows the number of routers on a contour line corresponding to a certain number of hops from a source. The Y-axis of a hop contour map is a hop count, and the X-axis is the number of routers found at that hop count. For example, Figure 3, a hop contour map of the NYSERNET backbone, shows that we discovered three routers six hops away from Cornell. Figure 4 is a concatenation of hop contour maps for a number of ISP backbones. Here, the Y-axis is the number of hops from the Cornell probe point and the X-axis is a concatenation of contour maps for different ISPs. The distance between two columns is 500 routers. The plot shows, for example, that ISPs ‘alter’ and ‘MCI’ have 200 routers at some hops and an individual ISP can have more than 1000 routers. From this plot, we estimate that the number of backbone routers in the Internet is in the 20,000-router range.

Last modified on: 10/12/99