Project Description 1 Overview - ns-3

Project Description 1 Overview Discrete-event network simulation is a powerful research tool for investigating protocol design, protocol interactions, and large-scale performance issues. While simulation is not the only tool used for data networking research, it is extremely useful because it often allows research questions and prototypes to be explored at many orders-of-magnitude less cost and time than that required to experiment with real implementations and networks. Simulation is also quite effective in education, for the same reasons as above but also because key concepts can be studied and highlighted more clearly in isolation from other system elements. For Internet-based data networking, one simulation tool has dominated the research landscape in the past decade (Section 3.1 highlights the impact of this tool in terms of research publications). The tool, Network Simulator (ns) version 2, described more fully in Section 2.2, has been funded by a number of previous research projects, but none since 2004, and none directly as an infrastructure project since 2000. Most of the original ns-2 developers have moved on to other research projects. As a result, little active development is occuring on the main code tree, and the development occurring in the community is generally not integrated with the project. Beyond pure software maintenance, however, a clear need exists for additional focused development work to occur on ns. These needs are not being met with other simulators; in particular, commercially supported simulation platforms tend to focus on enterprise customers or defense contractors, and not on research. We have organized a multi-institution team of experienced PIs to lead a new four-year development effort to revise and extend ns, which we are calling ns version 3 (ns-3). The PIs are Tom Henderson (PI) and Sumit Roy (co-PI) at the University of Washington, George Riley (co-PI) at Georgia Tech University, and Sally Floyd (co-PI) at the ICSI Center for Internet Research in Berkeley, CA. Our project, however, will expand greatly beyond the institutions listed; we will provide the open-source development framework to continue to allow individuals and institutions from the around the world to contribute software to the project. Most of our project budget is allocated to fund dedicated staff programmers and students who will participate in the design, development, and maintenance of the simulator. In Table 1, we have identified five areas of project focus for a new ns-3 simulator. Section 2 provides more details on the specific goals and rationale. Focus area Core Integration Wireless Education Maintenance

New features Scalability improvements, modularity, class design for realism and abstraction Incorporation/use of outside software, emulation, and virtualization More models for Wi-Fi, cellular, and small mobile devices Animation, educational scripts, integration with courseware and projects Validation, documentation, distribution, and project management Table 1: Focal areas of our ns-3 project.

Core refactoring. This task will design and refactor the core of the ns-2 simulator. The output of this task will be a cleaner, more scalable, and more extensible core. George Riley (architect of the Georgia Tech Network Simulator [Ril03a] and parallel, distributed extensions to ns-2 [RFA00b][RAF+ 04]) will lead this task. While striving to maintain as much model reuse as possible (including a backward compatibility capability), this task will stress rearchitecting the simulator for better ease of use, scalability (principally by class redesign, natively supporting multi-processor and distributed simulations, and support for 64-bit machines), and support for integration of other software. The simulator should easily, with realistic models at different levels of abstraction, allow for simulations of IPv4 and IPv6 networks, as well as novel, research-oriented network architectures. Integration. We see a tremendous opportunity, with an open-source simulator, to leverage the software developed under other open-source projects. We have three specific goals in mind: 1. Extension of the simulation capability via integration with open-source tools; 2. Abstraction layers and interfaces for porting implementation code into the ns environment; and 3. Interfaces to allow users to easily migrate between simulation and network emulation environments.

1

Existing core ns-2 capability

New features for ns-3

Applications

ping, vat, telnet, FTP, multicast FTP, HTTP, probabilistic and trace-driven traffic generators, webcache

Native sockets API (to allow porting of existing applications to ns environment), peer-to-peer (e.g. BitTorrent)

Transport layer

TCP (many variants), UDP, SCTP, XCP, TFRC, RAP, RTP Multicast: PGM, SRM, RLM, PLM

TCP stack emulation (Linux, BSD), DCCP, high-speed TCP

Unicast: IP, MobileIP, generic dist. vector and link state, IPinIP, source routing, Nixvector Multicast: SRM, generic centralized MANET: AODV, DSR, DSDV, TORA, IMEP

full IPv4 support, full IPv6 support, NAT XORP/Click Routing support: BGP, OSPF, RIP, IS-IS, PIM-SM, IGMP/MLD

ARP, HDLC, GAF, MPLS, LDP, Diffserv Queueing: DropTail, RED, RIO, WFQ, SRR, Semantic Packet Queue, REM, Priority, VQ MACs: CSMA, 802.11b, 802.15.4 (WPAN), satellite Aloha

new 802.11 model, 802.11 variants (mesh, QoS), 802.16 (WiMax), TDMA, CDMA, GPRS

TwoWay, Shadowing, OmniAntennas, EnergyModel, Satellite Repeater

IEEE 802 physical layers, Rayleigh and Rician fading channels, GSM

Network layer

Link layer

Physical layer

Figure 1: Models planned for ns-3 project. Wireless models. The simulator needs updating to account for the tremendous growth in wireless networking, including the many variants of IEEE 802.11 networking, emerging IEEE standards such as WiMax (802.16), and cellular data services (GPRS, CDMA). Additional models beyond wireless are also needed; Figure 1 summarizes the models used in the current ns-2, as well as models planned for ns-3. Education. ns is first and foremost a simulator for the academic research community. The current simulator is not optimized for educational use, due to the current OTcl-based programming paradigm unfamiliar to undergraduates, abstraction and incompleteness of core ns-2 models, an animator that has not been actively developed for several years, and lack of a heavily populated educational script repository. Our project will emphasize making ns-3 more useful to educators with a specific goal of its integration into undergraduate networking courses. Maintenance. The project staff will perform the important, time-consuming activities of code maintenance, documentation, integration, validation, and educational script generation. However, the project will attempt to put in place self-sustaining development practices for the project, in the model of other open-source projects such as Apache, so that continued infrastructure funding is minimized downstream.

2 Infrastructure This section describes the software that will be developed and how the development will be managed. Section 2.1 provides more details on the need for this project. Section 2.2 describes the previous funding history of ns-2. Section 2.3 provides details on the design concept for each of the five focus areas of our project. Finally, Section 2.4 provides details of our management plan.

2.1 Need Forty industry leaders in science and engineering were recently asked to name the ”most important technology for the coming decade.” Of the forty responses, wireless and the Internet were cited by a third of the respondents (13 of 40), a much larger percentage than for any other disciplines [App04]. As networks become pervasive, scale to millions of users, and become the essential fabric of our economy, tools to aid network research, development, and education must keep pace with this rapid growth.

2

Experience suggests that two models of development have succeeded for network simulation tools. The first is based on commercial support. Prominent examples include OPNET [OPN] and, more recently, QualNet [SNT]. Large licensing fees provide funding for software development teams to evolve the simulation software. However, the licensing fees pose a barrier to widespread deployment. Because it is mainly business customers that provide the most revenue for these companies, the available protocol models in these commercial tools are tailored to enterprise networking; significantly fewer models exist for next-generation networking (e.g., IPv6, embedded or sensor networking, overlays, and peer-to-peer). More importantly, commercial tools do not promote a culture of community development of software; most companies keep their own extensions to themselves, and many programmers are reluctant to freely develop and contribute software for proprietary platforms. While there is a future for commercially-supported simulators, the PIs believe that the future does not intersect well with the needs of the research and educational community. The second model is based on open-source or community development. Besides ns-2, a number of other simulators have been developed, including GloMoSim [Glo], NCTUns [NCT], GTNetS [Ril03a], OMNET++ [Var99], SSFNet [CON02], and JiST [JiS]. ns-2 has clearly achieved much more widespread use than the others, not necessarily because of technical superiority, but instead (we believe) because of two factors. The first is the “network effect” or first-mover advantage– ns-2 developed, early on, a reputation for being the simulator of choice for networking research, leading to a burst of development activity in the late 1990s, and the large protocol model base (and active user community) is still one of the largest discriminators over other tools. The second is the platform’s commitment to open-source licensing; many other tools mentioned above (including GloMoSim, OMNET++, and SSFNet) place restrictions on use for commercial purposes, and thereby discourage a certain segment of the research community from contributing. Despite ns-2’s popularity, there is a critical need for additional funding to do core refactoring, software maintenance, and extension of the simulator. Experience has strongly shown that issues like software maintenance (e.g., tracking compiler and operating system evolution), documentation, educational development, and code integration are lesser priorities for individual contributors focusing their limited time primarily on producing research output for publications. The best case for funding ns-3 is to look back on the productivity during the DARPA VINT project years of the late 1990s. In particular, we have identified the following key areas that require development of a new ns-3 simulator: o Software core: The current ns-2 core often limits the scalability (both speed and memory footprint) to tens or perhaps a hundred or so nodes. The software is not 64-bit clean, is not modular, and does not have native support for multi-processor or distributed, federated simulations. The emulation capability (ability to interoperate with live networks) is outdated and of limited utility. o Internal composition: The software architecture places restrictions on how simulation objects may be combined in new ways. Many pieces of the software do not correctly interoperate (for example, wireless simulations can not use the OTcl-based routing protocols). This is a repeatedly reported source of frustration for ns users. o External software integration: ns-2 is currently missing out on opportunities to leverage the wide number of advanced, externally developed programs such as open-source routing daemons (quagga, XORP, OpenBGP), traffic generators (iperf, tcplib), network virtualization testbeds (IMUNES, PlanetLab), network analysis software (Ethereal, tcptrace), etc. These tools can be integrated by the development of better ns-3 APIs and approaches to syntactically port application- and kernel-level code into the simulator’s object-oriented architecture. o New models: The protocol and traffic model library needs updating to cover more recent growth of IEEE 802based wireless network and channel variants, IPv6 protocols, and newer popular applications and services (e.g., peer-to-peer, messaging, voice over IP, BitTorrent). o Documentation: The ns-2 documentation has not been significantly updated for many years, is no longer consistent with the software core, and does not include more recently added modules. o Visualization: The nam animator is not well integrated with much of the code (wireless, Ethernet, satellite) and needs updating or replacement. o Educational use: More work is needed to build a comprehensive set of educational scripts, such as tracking the contents of popular undergraduate networking texts, providing protocol models that map better to actual implementations, and providing “newbie” support for simulator operation, visualization, and simple model development.

3

We also observe the growing trend of the research community towards virtual machines (VNUML [VNU], IMUNES [IMU], Netkit [Net], Xen [Xen], VMware [VMw], Bochs [Boc]) and cluster-based or distributed network testbeds (PlanetLab [PCAR02], Emulab [Emu], and WHYNET [WHY]). Proponents of this type of network research infrastructure argue that tools beyond simulators are needed to evaluate the impact of new network protocols, implementations, or architectures on live, actual traffic traversing real network links, and they are exactly right– such infrastructure is essential as part of the technology evaluation process, and the controlled environment of simulation is not appropriate for all experiments. However, there remains a need for robust simulation tools, particularly to explore issues of scale and large protocol design spaces that are infeasible to accomplish on real testbeds. The challenge, we believe, is to develop simulation tools that integrate well with virtual machines, network testbeds, and actual implementation code, and we place a priority on this topic in our program. Indeed, ns-2 is already the simulation language used to configure Emulab experiments, and two of the PIs (Henderson and Riley) have experience in designing flexible simulation models that allow external C-based implementation code to be run, without modification, in simulators, on virtual machines, and on actual implementations, often just by recompiling the software with different flags. Other related projects which we plan to leverage have involved moving network kernel code to user-space, including Alpine [ESW01], the BSD Network Stack Virtualization project [Eli03], and the Network Simulation Cradle for ns-2 [Jan03]. Below, we outline a community resource development project that, seeded with the funding we seek for this effort, will establish the foundation for a larger community development project that should outpace any other network simulation efforts and greatly extend the lifespan of ns.

2.2 History of ns-2 Core ns-2 development * Split-object architecture * detailed TCP models * scheduler, queueing, links * routing, wireless, satellite * nam, topology generators 1997 98 99

2000

Mainly integration of contributed code * Sensor network MAC and routing * SCTP and XCP * Wireless enhancements * SAMAN and CONSER modules 01 02 03 04

05 (funding gap)

DARPA VINT

DARPA SAMAN NSF CONSER

Figure 2: Previous funding efforts and results ns-2 is the second major iteration of a discrete-event network simulation platform programmed in C++ and Object Tcl (OTcl). ns-2 was first released in 1996, and derives from earlier work on the REAL simulator [Kes88] and ns-1 simulator. ns-2 is a major architectural change from ns-1– the simulator became entirely based on the blend of OTcl and C++. The core of ns-2 is written in C++, but the C++ simulation objects are also linked to shadow objects in OTcl. Simulation scripts are written in the OTcl language (an extension of the Tcl scripting language). This structure permits simulations to be written and modified in an interpreted environment without having to resort to recompiling the simulator each time a structural change is made. In the timeframe that ns-2 was introduced (mid-1990s), this provided both a significant convenience in avoiding many time-consuming recompilations, and also allowing potentially easier scripting syntax for describing simulations. ns-2 has a companion animation object known as the Network Animator (nam), used for visualization of the simulation output and for (limited) graphical configuration of simulation scenarios. Presently, ns-2 consists of over 300,000 lines of source code, with probably a comparable amount of contributed code that is not integrated directly into the main distribution. Figure 2 illustrates the past funding history of ns. Technical citations corresponding to these projects can be found in the references to this proposal. o The DARPA VINT (Virtual InterNetwork Testbed) was a collaboration between USC/ISI, Xerox PARC, Lawrence Berkeley National Laboratory, and UC Berkeley. The project ran from 1997-2000, and was focused on developing the core simulation code for ns-2 and nam. During this period, ns-2 saw its most intense core development; it is this past project that most closely resembles the infrastructure project that we are proposing. During the course of building out ns-2, a number of research aims were also met, including the study of composable simu-

4

lation frameworks, abstraction techniques and tools, visualization techniques, real-time network emulation, and network topology and traffic generators. o From 2000-2004, ns-2 development was no longer funded directly by a dedicated project, but instead used two programs DARPA SAMAN (Simulation Augmented by Measurement and Analysis for Networks) and NSF CONSER (Collaborative Simulation for Education and Research) to fund code maintenance activities. During this period, core development of ns-2 and nam slowed, although a number of contributed modules were ported in annually. SAMAN focused on analytic pre-processing of simulation scenarios to rapidly discard uninteresting cases, application-level traffic models, and tools to rapidly parameterize traffic models. Some ns-related tools generated from SAMAN research included a tool to distill traffic traces and generate cumulative distribution functions of the traffic, a tool for analyzing the steady-state performance of a simulation configuration before running the simulation (to discard uninteresting cases), and a tool to reduce a large topology based on the intersection of attacker and cross-traffic paths. CONSER produced a number of research publications on wireless, audio, internet traffic control simulations, and on inter-domain routing measurements. CONSER also established an educational ns-edu project and developed some initial scripts for educational purposes, and conducted outreach (software dissemination) workshops. Initial educational support for ns-2, as well as substantial changes to the nam wireless and editor, were the major development areas. o Since 2004, no funding for ns-2 has been in place. Development and extension of the simulator has slowed further still; although there is still a quite active user community, there is less support to integrate contributed code into the project, and little available manpower for addressing core architectural issues. In 2005, the PI (Henderson) took over maintenance of the ns-users and ns-developers mailing lists, coordinated an effort to streamline the source code licensing (to conform all licenses to a free software license model), and initiated the move of the ns-2 project to the Sourceforge project hosting web site.

2.3 Design Concept The ns-3 development project is divided into multiple tasks. Below, we provide technical description and justification for each piece: i) core refactoring, ii) integration, iii) wireless models, iv) education, and v) maintenance. 2.3.1 Core refactoring This task will design and refactor the core of the ns-2 simulator. The output of this task will be a cleaner, more scalable, and more extensible core. George Riley (architect of GTNetS and parallel, distributed extensions to ns-2) will lead this task. In this section, we outline a set of design objectives for the ns-3 simulator. We see these as basic requirements for the design, implementation, and overall success of this tool. First, the ns-3 design and implementation should leverage large parts of the code base of existing tools, such as ns-2, GTNetS, and others. These existing tools have hundreds of thousands of lines of code, and hundreds of existing network models. While we fully expect some modifications to these code bases will be necessary to fit within our overall design, we will strive to avoid complete re–design or re–implementation of existing modules as much as possible. To achieve this goal, we plan to design an automated tool to analyze and convert of much of the existing ns-2 OTcl code to enable inclusion in our design. We expect to be able to reuse much of the existing ns-2 and GTNetS code. A key consideration in the design is in preserving as much backward compatibility as possible, most likely through providing a backward compatibility mode for existing scripts, and syntactic migration of legacy scripts to the new core, with re-verification of the output. Scalability One of the major concerns about ns-2 cited by its users is scalability. ns-2 is a sequential execution simulator with a single event processing loop running on a single processor. Although such a simulator can scale to hundreds of nodes when underlying communications models are heavily abstracted, the memory and processing resources of a single machine become a bottleneck when more sophisticated channel models (e.g., wireless) or higher-rate links (e.g., 10 Gbps) are included. Researchers have taken various approaches to improve ns-2 scalability, including the caching of redundant computations and function calls (the “Staged NS (SNS)” project at Cornell), use of on-demand route computation [RZA00], and partitioning the simulation into wireless clusters (the ns-2 gridkeeper and similar structures developed by Naoumov and Gross in [NG03]). There are a number of factors contributing to the scalability limitation, including overall software architecture, but the fundamental bottleneck is the execution on a single processor. We believe that the ns-3 simulator should

5

(a) Conceptual overview of PDNS (from [RFA99])

(b) Scalability of PDNS (from [PFPR03])

Figure 3: Parallel distributed ns (PDNS) be designed from the outset to support parallel and distributed simulation. The COMPASS, PADS, and MASCOTS research groups at Georgia Tech have developed a Federated Simulation Developers Kit (FDK) and a ghost–node approach, used in GTNetS [RJ04], which we plan to apply to ns-3. This approach creates a federated network simulation consisting of a number of instances of the simulator tied together using a Runtime Infrastructure (RTI) middleware software layer (Figure 3(a)), with the RTI-interconnected nodes communicating over Myrinet or Ethernet. With this approach, a small memory overhead is incurred at each of the distributed simulation processes, which obviates the need for complicated inter–simulator routing decisions and obviates the need for a simulated routing protocol. PDNS uses a conservative (blocking based) approach to synchronization. No federate in the parallel simulation will ever process an event that would later have to be undone due to receiving messages in the simulated past. This avoids the need to implement state saving in the existing ns code. The PADS research group at Georgia Tech has previously developed an extensive library of support software for implementing parallel and distributed simulations. The sofware has support for global virtual time management, group data communications, and message buffer management. It has support for a variety of communication interconnects, including shared memory, Myrinet and TCP/IP networks, and runs on a variety of platforms. By using this synchronization software for the parallelization of ns, we were able to rapidly modify the main event processing loop of ns to support the distributed time management functions needed to insure that no unsafe event is ever processed by any federate. The modifications needed to ns can be broadly classified in two major categories, the modifications to the ns event processing infrastructure, and extensions to the ns OTcl script syntax for describing simulations. In particular, 1. Any reference to a remote endpoint of a connection must be by network elements such as IP address and port number, rather than memory address pointers to the remote object. In a distributed simulation, there is no guarantee that a remote protocol object has a memory address or a representation on any given simulator instance. 2. Packet routing decisions may need topology information not present on a simulator instance, and thus some method must be designed to properly route packets in the presence of incomplete topology information. The obvious solution to this issue is the use of a routing protocol, such as OSPF, to compute routes. However, this approach reduces scalability due to the need for potentially large routing tables at each simulated node. ns-2 already provides a choice between centralized routing, the use of simple models of distributed routing (distance vector and link state) and NixVector routing– a form of source routing that can retain and use a complete routing path from a source to a destination in a very compact form. 3. Some method of packet serialization and reassembly must be provided, to allow for the flow of packets from one simulator instance to another. 4. The distributed simulation features of the simulator should not hinder in any way a simple sequential simulation. 5. It should be no more difficult to construct a distributed simulation than to construct a sequential simulation. Figure 3(b) illustrates scalability results from running PDNS on a large Linux cluster consisting of 16 SMP machines with eight 550MHz Pentium III XEON processors. The eight CPUs of each machine share 4 GB of RAM, 6

and each processor contains 32KB of non-blocking L1 cache and 2MB of full-speed, non-blocking unified L2 cache. The 16 SMP machines were interconnected via a dual Gigabit Etherent switch with EtherChannel aggregation. Our RTI software used shared memory for communications within an SMP, and TCP/IP for communications across SMPs. We were able to scale the sample “campus network topology” simulations to over 450000 nodes across 128 processors. PDNS achieved a speedup of a factor of 80 and a simulation speed of 6 million packet hops per second, on 128 processors [PFPR03]). The capacity was ultimately limited by memory to 8*4500 nodes/4GB. Other Design Considerations Our ns-3 design will also consider the following: 1. Object-design. A network simulation tool designed for use by the networking research community must be easily extended to included new protocols, modifications to existing protocols, or new types of routing (just to name a few). To achieve these goals, we carry forward the core object-oriented C++ design of ns-2 with a large number of base classes that describe basic functionality, and subclasses implementing this functionality. For example, we have a base Queue class which describes the methods needed by all specific queue implementations. Then, subclasses of this Queue object implement various queuing methods, such as DropTail and RED. Similarly, a base TCP object describes and implements much of the functionality of the TCP protocol, but subclasses provide the specific functionality of the TCP variants, such as Reno, New Reno, and SACK. Further, extensibility can be achieved by the use of callbacks at various points in the simulation execution. For example, a callback between layers 2 and 3 could implement the functionality of a firewall or other network filtering devices without requiring modification of the implementation either the layer 2 or layer 3 processor. However, the overall software architecture of ns-2 needs revision. Specifically, the current OTcl/C++ splitobject paradigm of ns-2, while providing scripting flexibility at the user interface, introduces a number of problems. First, it is frequently cited as a barrier to learning and debugging the tool, because students are not familiar with object-oriented Tcl, the OTcl/C++ glue is poorly documented, and disparate debugging tools are required. Second, the code introduces restrictions on how the C++ objects can be combined, in ways that are not immediately obvious. For example, to use a particular Channel object with a MobileNode, the Channel must support the add-node OTcl method, although it is not specified by the C++ interface and one must carefully read the MobileNode OTcl code to figure this out. Because the C++ top-level interfaces are not very typed, a lot of C++ objects perform downcasting, introducing hidden dependencies between C++ objects. Since a primary complaint of the ns-2 user community is the inability to build novel combinations of simulator objects, we plan to clean up these interfaces and explore the revision or elimination of the split-object framework, in favor of a purely C++ design. 2. Realism. The basic design of the simulator should closely match the design of real networks and real network elements. When questions arise about the design of an object, function, or interface, deference should be given to how things will be implemented in real-life, unless there are strong performance or efficiency considerations. This design principle should greatly help in code portability and educational use. One key to achieving this goal is the support of important interfaces used in practice, such as the user-to-kernel interface (sockets API) and the kernel-to-device-driver interface (i.e., IP to sub-IP). Further, there should be clear distinction between protocol layers in the software design, with well defined intra–layer exchange points. A protocol graph should be designed to facilitate multiplexing and demultiplexing decisions as packets flow up and down the stack. Simulator objects representing packets should consist of one or more protocol data units (PDUs) with sub–classed objects for each distinct protocol type. Simulation objects representing applications should interface with layer 4 protocols in a fashion familiar to Internet application developers, including calls for establishing connections, sending and receiving data, accepting or refusing incoming connection requests, and closing connections. 3. Memory-efficiency. The simulator should continue to support both data–less and data–full flows. In other words, an application model might specify to send 100,000 bytes of data to a remote endpoint, but the actual data contents are not meaningful and can be abstracted away. Current ns-2 is optimized for data–less operation. In other applications, such as a simulated application modeling the Gnutella peer–to–peer protocol, applications must be able to specify search requests, replies, and ultra–peer information in the data contents. This capability is also needed for directly ported application code, whose data is meaningful and must be supported by the simulation. There should be no difference between data–less and data–full packets below the transport layer, and we plan on straightforward support of both in ns-3. 4. Tracing. To facilitate large–scale simulations, the amount of data logged and traced as part of the simulation statistics should be highly configurable by the simulator user. For example, when studying end–to–end behavior 7

of TCP, the tracing of packet data at layers 2 and 3 at all hops along the TCP path is meaningless information. Thus, a user must be able to specify that only particular layer information is logged, and additionally can limit the logging to specific nodes or applications. Further, the type of data recorded at each layer should be defined by the user. For example, when studying TCP performance, the contents of the source port and destination port fields may or may not be of interest, depending on the number of flows defined at each node. In this case, the user should specify whether or not these fields should be logged as part of the simulator output. We plan to add support to directly trace packet flows in standard trace file formats, so that tools such as tcpdump can process them. 5. Statistics. For ease of use, the simulation must provide a number of support objects to facilitate data collection during the simulation execution. We will included objects for histograms, averaging, minimum and maximum tracking, probability distribution functions, cumulative distribution functions, and sequence versus time plots. We plan to add support for better statistics generation from similar objects in GTNetS. 6. Topology. For ease of use, a number of stock topology objects should be predefined. These stock objects can be instantiated by a single line of C++ code constructing the object, with configurable arguments. For example, the Dumbbell object would naturally create a dumbbell topology with a specified number of leaf nodes at each end, and with a specified bandwidth constriction factor at the bottleneck link. Other stock objects should include trees, meshes, stars, and random topologies of arbitrary size. We will incorporate such topology objects from GTNetS. 7. Visualization The simulator must support some form of visual animation of all or part of a simulation. This is useful for debugging and demonstrating the simulation to others. The network animator nam has been part of the simulator from the beginning, but outside of wireless extensions developed under NSF CONSER, has not been the subject of development for several years. 2.3.2 Integration A key step forward of our proposed ns-3 project will be the level of integration that we will obtain, leveraging the vast amount of free, open-source software and research projects available on the Web. We have three specific goals in mind: 1. Extension of the simulation capability via integration with open-source software (e.g., Ethereal packet analysis, Click/XORP routing); 2. Abstraction layers and interfaces for porting implementation code into the ns environment; and 3. Interfaces to allow users to easily migrate between simulation and network emulation environments. An opportunity that most every simulation environment has missed is the opportunity to leverage the extensive amount of free, open-source networking code within operating systems and applications. Typically, simulators reimplement protocols from scratch, leading to a costly software effort and divergence from actual implementation code. There are limited exceptions (the TCP code in QualNet, for example, is ported from BSD, and NCTUns uses a kernelreentrant programming paradigm to use actual Linux stack code), but predominantly, protocols are reimplemented for the simulation environment. Furthermore, simulation code often does not interact well with real implementations. Most commonly, simulation implementations of protocols are rewritten for use as implementation code, often because the simulation code makes use of abstractions and simplifications not present in real systems. We are aware of a number of cases in which companies or organizations have written an abstraction library for an existing simulator such as OPNET or ns-2, and also support the same library in an operating system, allowing software to be written once and used in both implementation and simulation environments; the Naval Research Laboratory’s protolib toolkit is an example of a publicly-available library of this type. This approach works well if a protocol implementation is written from scratch; however, it generally does not work so well when existing software, often written in a lower-level, non-object-oriented language such as C, is used. In the ns-3 project, we intend to focus on simulator design that facilitates the reuse of existing software and applications. Although there are dangers in relying exclusively on open-source networking code (such as inheriting bugs and design peculiarities of, e.g., Linux TCP), there simply is no cost-effective substitute for reusing software packages that others have spent years developing and maintaining. Such an approach helps to meet our educational goals as well, since the simulation models mimic how the software is run in real implementations. 8

Node

pointer to app

Kernel

apphead_ Position App

socket[]

...

...

Unix-like sockets API

PCB (e.g. UDP)

Kernel (sockets, PCBs, and IP stacks)

PCB

pcb_head_ Net/3-like interface API

Interface Energy

stackv4_

...

stackv6_

to/from interfaces

ifhead_ Main data structures i) array of sockets (file descriptors) ii) linked list of protocol control blocks (PCBs) iii) IPv4 and IPv6 protocol stacks

3 linked lists: i) (static) linked list of all nodes ii) linked list of all applications on a node iii) linked list of all interfaces on a node

Figure 4: Revised node architecture to support legacy application and kernel code porting. The PIs have experience in porting actual implementation code into the GTNetS and ns-2 simulation environments, including BGP and OSPF software from the quagga open-source routing suite, and application-level code that uses the sockets API. In 2004, the PI (Tom Henderson) developed a prototype variant of ns-2 with an architecture more resembling a traditional Unix implementation (Figure 4). A key feature of the design is a more faithful representation of the sockets API and the API existing between the network layer and device driver layer in BSD and Linux implementations. Specifically, client/server application code in C was taken from the TCP/IP sockets book by Calvert and Donahoo [CD01] and ported to this new framework, using the simulated representation of the sockets API. Insights from these past efforts will guide our development of more general support for such integration. Specifically, we see the following key opportunities for software integration and reuse: i) ported application code using sockets API, ii) routing protocols such as XORP, quagga, and OpenBGP, iii) network stack code such as the Network Simulation Cradle [Jan03], and iv) tools to parse output data such as tools that work on libpcap format traces such as tcpdump and Ethereal. Finally, we recognize the significant research infrastructure advances of the past few years, with such projects as PlanetLab, Emulab, and WHYNET. These testbeds provide opportunities to explore protocol interactions in less controlled environments (such as cluster-based, remotely executed testbeds including Utah’s Emulab) and to deploy long-running experimental services and overlays on the existing Internet (PlanetLab). Presently, Emulab uses ns scripting syntax to describe its experiments, and offers a version of the ns emulation environment to experimenters. There is presently no ns interface to PlanetLab. Our view is that ns should be flexible enough to run as simulations but be easily convertible (such as building with different flags) to run in an emulation environment. To achieve this, the ns emulation environment must be further developed (it is based on an older version of FreeBSD, does not fully support all ns protocol models, and has not undergone development for several years) and tested with Emulab and PlanetLab. Specifically, we envision that ns could run as an application within a PlanetLab slice, with the emulation interface tying into the PlanetLab Safe Raw Sockets API, and that ns could run on top of an Emulab virtual interface.. Our project will coordinate with testbed projects to ensure that ns can successfully execute in those environments and is well documented enough for ease of use. 2.3.3 Wireless Models While the wave of wireless innovation due to both successful commercial deployments (802.11, 2.5/3G) as well as other emergent or imminent standards of promise for 4G networks (802.15 for Wireless Personal Area Networking and 802.16 Wireless Metropolitan Area Networks) has continued, the lack of dedicated funding for ns-2 extensions over much of this period has meant that there is currently insufficient protocol support for these new technologies in ns-2. A key message from the data in Tables 2 - 4 is that the greatest need for new code is at layers 1-2 in ns-2 (which is where some researchers have migrated to alternative simulators). What particularly distinguishes this phase of innovation are significant protocol stack and architectural innovations

9

Simulators Transport layer and above Network layer MAC & PHY layers

ns-2 156(84%) 91(43%) 85(41%)

OPNET 29(16%) 90(42%) 108(53%)

QualNet/GloMoSim 0(0%) 33(15%) 12(6%)

Table 2: Percentage of published IEEE simulation papers citing use of simulators in different layers.

Simulators Transport layer and above Network layer MAC & PHY layers

ns-2 123(75%) 186(70%) 114(43%)

OPNET 30(18%) 48(18%) 96(36%)

QualNet/GloMoSim 11(7%) 31(12%) 55(21%)

Table 3: Percentage of published ACM simulation papers citing use of simulators in different layers.

Year IEEE ACM

2001 5 16

2002 9 22

2003 30 32

2004 34 33

Table 4: ns-2 usage in MAC/PHY of recently published IEEE/ACM papers.

that have led to redesign of layers 1-2 in the traditional OSI model for these new wireless stacks. In addition, the notion of cross-layer stack optimization has replaced the traditional (i.e. for wired networks) principle of independence of the various layers due to the recognition that optimization of wireless networks will require exchange of key information across traditional stack boundaries (typically from link/data link layers upwards in the stack) due to the inherent broadcast nature of wireless. An example is the upsurge of current interest in new link-aware routing metrics that capture the co-channel interference due to channel reuse along a path, an issue that does not occur in routing for traditional wired networks. In summary, there is a demonstrated need for new ns-2 modules for wireless as well as new software engineering practice to allow flexible cross-layer interactions. While some module patches available from individual researchers on an individual basis (we provide a sample listing below), the correctness of those patches and their compliance with the core standard must be verified1 prior to integration with ns-2. A cornerstone premise of ns-2’s success to date (notably, with regard to widespread use of TCP implementations) has been the community’s belief in the correctness of the relevant protocol stack, and we plan to develop and integrate wireless models worthy of similar reputation. Currently, ns-2 has support, via either direct implementation or contributed modules, for wireless personal area networking (WPAN) in the form of IEEE 802.15.4 and Bluetooth support, for wireless local area networking (WLAN) (revised 802.11 model in work by INRIA, including Enhanced Distributed Channel Access (EDCA) 802.11e support), and sensor network stacks, including NRL’s sensor network, SMAC, and SensorSim. No support exists for wireless wide area networks, such as the emerging IEEE 802.16. Not all of the above models have been validated, and some are known to have bugs. Clearly, there is already a backlog of tasks (for ns-3 developers) for verifying the above modules and developing new ones to fill in gaps (such as for 802.16 as well as new wireless multi-hop or MESH networks based on .11 or .15). Validation of Wireless Network Models While availability of new ns-2 models for layers 1-2 in a wireless stack will be welcomed by the larger research community, the problem of model validation to corroborate their utility is an ongoing challenge that must be addressed, since any simulation model will typically fail to capture the inherent variability of RF propagation in unstructured environments, compounded by the heterogeneity due to imperfectly known traffic patterns and interference from other networks, and variations in radio implementations. As a classic example of design based on a hypothetical physical layer model (i.e. unverified by any supporting measurement data), consider IEEE 802.11b that adopted the exponential power-delay profile for the channel model that rarely matches a typical indoor environment. Similarly, commonly used simple inverse path loss models for the long-term mean 1 In fact, our experience with the 802.15.4 code that is already included in the current distribution shows many bugs related to the protocol implementation; we expect this to be typical of other cases.

10

received signal power must be supplemented by short-term (e.g. Rayleigh/Rician) and long-term (e.g. log normal) envelop fade distributions for a more accurate representation of the true instantaneous received signal power. In summary, models that more accurately represent a wireless scenario allow for optimization of the protocol stack that is particularly important for wireless networking where design challenges are manifold and the designer must use all available degrees of freedom to meet target specifications. Clearly, such validation is infeasible for all the wireless stacks mentioned earlier. However, this will be possible for 802.11 WLANs that are now available as commodity hardware and for which we have implemented a small-scale testbed at the University of Washington. The prototype is composed of 15 PCs equipped with PCI network adapters with both Prism 2.5 802.11b and Atheros 802.11a/b/g NICs that run Linux 2.4.26. The testbed (Figure 5) is located on a single floor of the EE/CSE building that has its own wireless network for departmental use, providing the usual setting of unstructured networks that interfer with the testbed. Such commodity .11 wireless devices currently provide considerable flexibility to measure physical and MAC layer parameters by utilities based on open-source (Linux) device drivers (or by suitable modifications of them) - e.g. packet loss rate on a link, received signal strength as a function of range, etc. Some preliminary measurements with our testbed exhibit the well-known real-world characteristics such as reFigure 5: UW 802.11 testbed ceived signal strengths that are not a simple monotonic decreasing function of distance (e.g. bimodal distributions of received signal strength have been observed for links), are strongly asymmetric (i.e. not the same in both directions on a link), and that vary widely over time due to fading. There is thus a demonstrated need for ns-3 models of layers 1-2 that are validated by actual measurement data; we propose to provide just that for present-day .11a/b hardware (and any next generation WLANs as they become available). Multi-hop Wireless Network (MESH) Architecture A concrete example of the evolving wireless protocol stack and associated network architecture is the significant interest in defining a multi-hop (or MESH) standard for .11 nodes, as is being currently undertaken by the IEEE 802.11s Task Group.2 The success of .11 systems has largely been in deployments in the home and small enterprize segments where coverage is limited and few users are served simultaneously, i.e. the network size is small. Due to its commodity level pricing, there is now considerable interest in expanding the use of these technologies into so-called “dense networking” scenarios such as large enterprises and public hotspots to serve more users over a wider area. In other words, next-generation .11 designs must overcome the limitations of the current architecture, which (it is useful to recall) was designed as an outgrowth or extension to the wired Internet, i.e. for providing last hop connectivity to the mobile end user, and without intending to provide expanded coverage and become intermediate access networks on their own. Consequently, the interest in defining new multi-hop .11-based network architecture along with suitable protocol stack modifications necessary for network formation, i.e. the need for inter-node communications to support important layer-2 and layer-3 functions. We propose to make an ns-3 MESH implementation based on .11 available as part of supporting an emerging research area; a quick scan of the leading networking conferences will validate the flurry of activity in germane topics such as MAC, channel allocation and routing for wireless multi-hop networks. Currently, nearly all such studies are analytical without the benefit of any experimental corroboration, or use custom code that is not validated by wider shared use. This component of the wireless development effort will thus be extremely timely and have a significant impact in enabling new research. 2.3.4 Education While ns-2 has developed some useful educational tools, most notably o The Network Animator (nam) and the nam graphical editor, which helps to create and visualize simulations, and 2 This

also directly relates to the issue of network scalability, an issue whose importance cannot be overemphasized for future network designs.

11

o the ns-2 educational script repository, intended to track chapters in textbooks such as “Computer Networks: A Systems Approach” by Peterson and Davie [PD00], it has not been exploited in networking education, and the ns-edu mailing list is largely dormant. However, the need for integrating simulator use in networking courses is more compelling today than ever before. A casual survey of ns-2 use in courseware shows very limited use for projects or a few assignments. As a typical example of this, the popular networking course offered at UW to senior level students in Electrical Engineering & Computer Science (EE 461) uses three ns-2 modules (one each on data link protocols, routing and TCP) as softwarebased homework assignments developed by the PI (Tom Henderson). Personal experience in using the existing ns-2 for education has highlighted the challenges in using ns-2 in the classroom. As instructors, we feel that greater use and better integration of ns-2 is hampered by insufficient or outdated documentation, lack of access to fundamental simulation objects without requiring that students write code in OTcl, divergence between simulation objects and actual implementations, arcane syntax of example scripts and the trace file format, and the lack of enough template or example scripts with similar input/outputs to assist students. These problems are solvable, and we intend to draw on our experience with using ns-2 in the classroom to guide our development priorities, followed by testing the use of ns-3 code in future classes. Thus the educational goals of this project will be to achieve more ns-2 usage in courseware via the following: o through refactoring, make ns-3 easier for building educational and tutorial scripts, o create more sample scripts that correspond to the outline of content in popular networking texts, o revise and extend the network animator nam, o create new modules specially emphasizing new wireless links, and o maintain a repository of scripts and animations, which mostly comes from instructors who are using ns-2 in the classroom. 2.3.5 Maintenance Some activities planned for this task include: o develop functional and technical specifications for the new software design, o establish a source code control system, coding styles, and software development model, including tinderboxes for daily builds on different platforms, o ns-2 has a validation facility for ensuring that simulation output in one module is not changed by a code change in an unrelated module. Create new validation test suites for the new simulator and models. Port validation scripts that do not work in backward compatibility mode, o update the documentation and create tutorials, o establish a web presence for collaborative software development, Wikis, mailing lists, and dissemination of the software, and o attend and participate in annual program review meetings, at sites to be determined. Once ns-3 is established, we intend to get a broader community involved in ongoing maintenance activities, by encouraging contributors and power users to take up portions of the maintenance activities, as in other open-source projects.

2.4 Management Plan 2.4.1 Project Organization The offerors propose a distributed project management team that integrates the expertise and research interests of Principal Investigators (PIs) from different institutions. Such an arrangement has been used by for ns before on the DARPA VINT project, which funded ns-2 development from 1997-2000.

12

Georgia Tech - George Riley (co-PI) * scalable architecture * parallel/distributed simulation

- staff programmer - student research associate

Univ. of Washington - Tom Henderson (PI) * modularity and integration * support of implementation code * layer-3 forwarding/routing * documentation - Sumit Roy (co-PI) * wireless models * educational use

ICIR - Sally Floyd (co-PI) * transport protocols * validation/test suites * middleboxes

- staff programmer - student research associate

Figure 6: Management structure The management structure for the project is shown in Figure 6. Structurally, the overall responsibility for project execution will rest with the University of Washington, with the other institutions participating as collaborators. The Principal Investigator on this project will be Tom Henderson (Affiliate Assistant Professor, University of Washington). He will be responsible for overall project management, and will focus technically on the integration task described above. George Riley (co-PI, Assistant Professor, Georgia Tech University) will focus on core refactoring of the simulator. Sumit Roy (co-PI, Professor, University of Washington) will focus on wireless models. Sally Floyd (co-PI, Researcher, ICSI Center for Internet Research) will continue to focus on transport protocol models and simulation validation. All of these PI responsibilities draw on the special qualifications that each individual has in this area; combined, the PIs have over fifty years experience with developing software for discrete-event network simulators. Staff programmers and student research associates will work directly for the hiring PI. We have budgeted for one programmer and one full-time student at both University of Washington and Georgia Tech University. The bulk of our requested budget therefore goes directly towards funding the programming labor necessary to develop the infrastructure, under the guidance of the PIs. The project will be managed as follows: o Collaboration. Following the VINT model, the team will have regular weekly telecons. In addition, we have budgeted for annual face-to-face program reviews and working meetings. The PIs have extensive experience in collaborative, network-based software development tools such as cvs and bugzilla, and in software project management. o Managed development. The PIs shall set the overall software architecture and establish coding standards, flowed down to all developers. o Outside contributions. We will establish a process whereby outside developers are allowed to participate, either by providing an existing developer with software patches, or by allowing commit privileges to selected participants. Our collaboration already extends beyond our proposal team. Tom Henderson is presently transitioning the ns-2 project to Sourceforge, a leading open-source development repository, already hosting development efforts for the TclCL and OTcl components of ns-2. The project is enlisting new volunteer developers. We also have invited the Planete team from INRIA to collaborate with us on wireless modules (see the letter–of–support in the Supplementary Documentation of this proposal). Presently, an INRIA developer is rewriting the 802.11 implementation, also with a target of 802.11e support, and INRIA also is interested in pursuing, with their separate funding, physical layer models for 802.11, multicast for multimedia, 802.11n, and WIMAX. o Support. Work to support the user community (primarily responding to bugs and queries on the mailing list) will be delegated and rotated among the developers. As this is a software project for use on general purpose PCs and clusters, the participating institutions will provide all necessary material for the project.

13

2.4.2 Dissemination Plan As a collaborative, open-source and open licensed software project, the main payoff is not centered on the proposing institutions but instead on the broader impact that it offers the networking research and educational community at large. Specifically, we plan the following: o Website. We will build and maintain a new website for the project, hosting project documentation and Wikis. o Mailing lists. Continuation of existing ns-2 mailing lists, and addition of new mailing lists for users and developers. o Workshops. Held in conjunction with major networking research conferences (Sigcomm, Mobicom, Infocom). o Educational script repository. Linked off main website. 2.4.3 Licensing The project will develop and post a clear licensing policy. Presently, the existing ns-2 simulator is migrating to GNU GPL-compatible licensing, with special exceptions for Apache 2.0 and original BSD-licensed software. We intend to use GNU GPL-compatibility as the basis for accepting contributed code to ns-3. Such a licensing policy will provide no restriction on commercial or non-commercial reuse of the software, subject to the GPL license rules requiring open redistribution of derivative works. We believe that such a licensing policy is the most attractive to soliciting and integrating software from the wider community. Contributors from outside the project shall attest to the origin of their software and that any licensing considerations are handled correctly. The project shall avoid incorporating software that creates a licensing constraint or conflict for the project. 2.4.4 PI Qualifications The team assembled to lead this project is especially well-qualified, with a diverse, complementary background. The PI, Tom Henderson, has been a user, developer, and maintainer of ns-2 since 1997. He ported the TCP code from ns-1 to ns-2, developed and implemented the simulated applications API and HTTP traffic generator with another student, and developed satellite extensions to the simulator. He currently administers the ns-users and ns-developers mailing lists, and has recently led the conversion of approximately 25% of the disparate software licenses in the code base to GNU GPL-compatible software licenses, in preparation of the move of the project to the Sourceforge open-source site. He has also developed three ns-2 educational modules/assignments for undergraduate education, which he used while teaching Introduction to Computer Communication Networks at the University of Washington. He has extensive experience on several discrete event network simulation platforms since 1992, including Simscript, QualNet, and GTNetS, and his research at Boeing involves Linux and BSD network and kernel programming. He also has significant research project management experience, including serving as co-PI and technical lead for three active ONR research contracts and one current DARPA subcontract. George Riley is a member of a network simulation team at Georgia Tech that has developed some of the largest and fastest network simulations reported to date. He has over 20 years of simulation experience, and has contributed Nix-Vector routing to ns-2 [RAZ01], developed the PDNS prototype (a federated, distributed version of ns-2) [RFA00b], and the Georgia Tech Network Simulator, another C++based packet-level simulation environment [Ril03a]. Sally Floyd has been the key ns-2 developer for TCP models, router mechanisms, and explicit congestion notification (ECN). She also has led the development of the large ns-2 validation test suite. The ns-1 and ns-2 simulators evolved from the simulator that she used in the early 90’s; that simulator was based on Keshav’s REAL simulator [Kes88], and maintained by Steve McCanne. Sumit Roy’s long record of research contributions to wireless (CDMA for 2.5 systems previously and .11/.15 currently) is the basis for his inclusion in the project team. However, what is worth emphasizing in this context is the fact that his current research spans layers 1-3 having evolved from a strong and diverse base of layer-1 contributions in the past. His recent work in joint PHY/MAC optimization of .11 networks as well as link-aware routing uniquely positions him to contribute to the ns-3 research goals. Further, the presence of a .11 testbed at the University of Washington will allow integration of measurement-based link and MAC layer models into ns-3, an area that has been largely neglected to-date. This is of critical importance as wireless networks will operate in only partially known environments and the ability to adapt design parameters in such unstructured environments (as in software defined or smart/cognitive radios) will be fundamental to their success.

14

Simulators Usage Simulators Usage

ns-2 332(51.4%) NCTUns 1(0.2%)

OPNET 227(35.1%) SSFNet 6(0.9%)

QualNet/GloMoSim 45(7%) JiST 23(3.6%)

OMNET++ 10(1.5%) GTNetS 2(0.3%)

Table 5: Percentage of published IEEE simulation papers citing use of various simulators.

Simulators Usage Simulators Usage

ns-2 423(53.2%) NCTUns 0(0%)

OPNET 174(21.9%) SSFNet 30(3.8%)

QualNet/GloMoSim 97(12.2%) JiST 46(5.8%)

OMNET++ 16(2%) GTNetS 9(1.1%)

Table 6: Percentage of published ACM simulation papers citing use of various simulators.

Year INFOCOM SIGCOMM MOBICOM

2001 2 6 5

2002 4 5 6

2003 5 2 9

2004 6 3 4

Table 7: ns-2 usage citations in three major networking conferences.

3 Projects 3.1 Research Impact We intend for ns-3 to continue to be the simulator of choice for research and education for data networking. Above, we have outlined a plan whereby, with a revised architecture, commitment to maintenance and documentation, and community-driven open-source development model, the simulator can be extended well beyond the capabilities of commercial simulation tools, and can be leveraged by other projects such as Utah’s Netbed. The scope of research enabled by ns-3 will be broad, including not only IPv4- and IPv6-based networks, but also emerging network architectures based on overlays, next-generation Internet initiatives, and the proliferation of wireless-enabled devices. The impact of ns-2 on networking research has been considerable. Brief surveys of the literature turn up large numbers of papers that cite usage of ns-2. For instance, tables 5 and 6 show the number of papers citing the use of various discrete-event network simulators found in the IEEE and ACM Digital Libraries, respectively. Use of ns-2 is common among the elite conferences in networking. Table 7 shows the number of papers citing ns-2 usage in the past four years of IEEE INFOCOM and the main tracks of the ACM MOBICOM and SIGCOMM conferences. We expect that our proposed ns-3 simulator can even improve on these statistics. While we cannot anticipate the many directions the research community will take this tool, we can list a few projects that we as PIs are eager to pursue with a new ns-3: Autoconfiguration of large mobile ad hoc networks Mobile ad hoc networks have been well studied and simulated for the past few years, but mostly for small network sizes (tens of nodes). Now that smaller networks are well understood, there is a need to scale the size of the network under study (to hundreds of nodes) and address the different issues that arise in such scenarios, including how to dynamically create and manage hierarchy in such networks, the autoconfiguration (and duplicate detection) of network addresses, managing partitioning and merging of portions of the networks, and the use of such mobile networks as transit networks in larger autonomous systems running BGP and legacy IGPs such as OSPF. The new features of ns-3 can help in providing simulation resources for these problems in two ways: i) scalability improvements will allow simulations of the sizes required, beyond the capabilities of ns-2, and ii) externally-developed implementations of BGP and OSPF (themselves many tens of thousands of lines of code) can be integrated into the simulator.

15

Multi-hop mesh wireless networks As already stated, a topic of significant interest is the design of multi-hop (MESH) wireless networks based on commodity hardware such as current or future 802.11 protocols (as well as 802.16 in the near future). As wireless networks scale (relative to a typical short-range single-hop link) for new applications in enterprize and other high-density hot-spots, new network architectures and commensurate protocol stack definitions are evolving (notably by the IEEE 802.11s task group dedicated to defining an extended service set MESH). The core innovations needed lie in cross-layer design of layers 1-3 of the protocol stack for optimized end2end performance. Currently, there does not exist any verified simulation tool to assist researchers in exploring the many design space trade-offs, and nearly all work is either (semi) analytical or requires custom coding of ns-2 modules for this purpose. A particular shortcoming is the lack of suitable hooks across layers in the stack, which prevents much needed performance analysis into, for example, link-aware routing protocols (that are significantly different from their standard wired counterparts that are simply unsuitable for a multi-hop wireless environment). The proposed ns-3 wireless enhancements would directly address this critical need (among several others) for the general benefit of the community at large. Scenarios for the Evaluation of Congestion Control Mechanisms The research community is in need of better models for use in simulations and experiments for the evaluation of congestion control mechanisms [FK02]; these congestion control mechanisms include transport protocols, Active Queue Management mechanisms, and new forms of explicit feedback from routers to end-nodes. Along with the newly-formed Transport Modeling Research Group (TMRG) of the Internet Research Task Force (IRTF) [TMR], we plan to create a Best Current Practice set of scenarios for researchers to use in simulations and testbeds for the evaluation of congestion control mechanisms. These will include scenarios of typical congested links, high-bandwidth environments, and wireless networks and other difficult environments. This work will require improving our understanding of which characteristics of networks (including topology, traffic mix, router configuration, and link-level characteristics) critically affect the evaluation of congestion control mechanisms. This work will be enabled by ns-3 with the ability to run faster simulations that include a complex traffic mix; interactions with IP tunnels, NATs and firewalls; realistic router buffer architectures; and the like.

3.2 Educational Impact As we described in Section 2.3, ns-2 has not yet achieved the level of impact on educational use as it has in the research community. Although at a graduate level it is used in course projects (the output of which can be seen in the research results cited above), we feel that ns-3 can play a major role in undergraduate networking education and become the preferred simulator for performance evaluation of various components of the network stack; our specific goals in this regard are outlined in Section 2.3 above. Wider adoption of ns-3 in courseware will provide the additional benefit of getting students involved in testing the ns-3 scripts. Further, a specific impact that we anticipate via the inclusion of new wireless modules in ns-3 is an implicit push on authors of leading networking textbooks to upgrade their chapters on the newer topics such as wireless by providing exercises and projects that underscore the new principles in design of layers 1-2 that distinguish it from wireline protocols.3

4 Results from Prior Support The PIs affiliated with this proposal have received substantial prior funding from NSF, including the following relevant projects within the past five years. Professor George Riley has received funding for the following related projects. 1. “COMPASS – Composable and Parallel Simulation of Internetworks”, National Science Foundation Grant Number ANI-9977544 (principal investigators Dr. Mostafa Ammar and Dr. Richard Fujimoto). 1999-2002. While a research scientist at Georgia Tech College of Computing, George Riley was primarily involved in the COMPASS research project. One of the goals of COMPASS is to provide methodologies for simulating very large computer networks using parallel and distributed simulation techniques. The research resulted in the development and release of Parallel/Distributed ns2 (pdns) [RFA99], and in the NIx–Vector routing method for network simulations[RAF00]. Using pdns and the NIx–Vector routing method, we demonstrated a network 3 As instructors, we find that many networking texts today are increasingly becoming a ‘compendium’ as they seek to include obligatory chapters on the current new and ‘hot’ areas. These chapters are often poorly integrated within a curricular framework, and specifically include no simulationbased exercises that allow students to undertake any meaningful performance evaluation.

16

simulation of a topology of more than 250,000 network elements. This work was the basis for Dr. Riley’s Ph.D. thesis and other publications [RFA99, RFA00a, RAZ01, RAF00, XRAF01, RAF+ 01, RJF02, WFR01]. 2. “Large-Scale Computer Network Experimentation Through Simulation” National Science Foundation Grant Number ANI-0136939 (principal investigator Richard Fujimoto, co–PIs George Riley and Mostafa Ammar) 2001 – 2005. The focus of this research effort is methods to enable simulation–based experimentation on ultra– large networks. As part of this research, we have enhanced and improved existing methods for time synchronization in distributed simulations, designed and developed a new simulation environment called GTNetS, and demonstrated a multi–million node simulation using the Pittsburgh Supercomputer Center (PSC) [FRP+ 03]. Further, improvements in the multicast routing table management in the ns2 simulator were designed and implemented, resulting in an order of magnitude improvement in the memory footprint of multicast simulations [XRAF03]. Publications funded all or in part by this grant include [FRP+ 03, DR03, PFMR02, FFRA02, RA02, XRAF03, HARF02, Ril03b, PFPR03]. 3. “ScalableSensorSim - A Simulation Environment for Large–Scale Sensor Networks, National Science Foundation Grant Number ECS-0225417, (principal investigator George Riley, co–PI Douglas Blough). 2002 – 2005. This work involves the development of detailed and efficient simulation models for use by researchers working in sensor networks. To this end, we have developed our Georgia Tech Sensor Network Simulator (GTSNetS) [OAVRH04], and have included detailed models for a number of features important to the study of sensor networks. Publications funded all or in part by this work include [OAVRH04, ZR04]. 4. “Network Security Vulnerability Analysis via Large Scale Simulation”, National Science Foundation Grant Number ANI-0240477, (principal investigator George Riley, co–PIs Henry Owen, and Randy Abler). 2002 – 2005. This work is focused on developing methods for studying Internet security using large–scale simulation. We have developed packet–level detailed models of worm behavior, and have developed methods to simulate the spread of worms and other malicious traffic using our GTNetS simulation environment. Publications funded all or in part by this work include [Ril03b, DR04, SRL04, Ril03c]. 5. “Large-Scale Network Simulation for Security and Survivability Evaluation”, (principal investigator George Riley, co–PIs Henry Owen, and Douglas Blough), 2005 – 2008. This ITR grant is aimed at improving the overall security of existing and proposed Internet protocols, by using large–scale simulation to analyze and observe the effect of deliberate or inadvertent attempts to disrupt service. In particular we are focusing on the Border Gateway Protocol (BGP) and the Domain Name Service (DNS), along with proposed new security enhancements to each. Further, we are analyzing Internet worm behavior and creating packet–level detail accurate models of several existing Internet worms. Publications funded all or in part by this work include [AR05a, AR05b]. Sumit Roy (University of Washington) references two relevant NSF multi-PI ITR projects. 1. “Heterogeneous Systems Integration in Systems-on-Chip”, end date Feb. 2005. Professor Roy was responsible for a research thrust centered around the design of a High Throughput Wireless Transceiver as part of a Universal Transducer Chip. The primary innovations/contributions involved link design based on new space-frequency block codes (SFBC) that improved margins on fading wireless channels by achieving the maximum diversity available. Specifically, our designs for High Rate SFBCs that achieve rate M symbols/channel use and diversity order of MK(N-M+1) (M,N:number of transmit,receive antennas) were the first in this area and were presented to the IEEE 802.11n Task Group on High Throughput Wireless LANs for consideration towards the next generation WLAN standard. 2. “RESCUENET: Embedded In-Building Sensor Network to Assist Disaster Rescue”, ITR/ANI 0325014, 20032007. The second award is an ongoing medium ITR project that seeks to architect an ultrawideband (UWB) wireless sensor network. The use of UWB is both novel and challenging in this context and extensive measurements of UWB signal propagation in various compositions and configurations of compacted building material will be the basis for developing a network stack (MAC, routing) that involves exploitation of precise locationing in a multipath environment for which UWB is uniquely suited. Energy efficiency is critical to maximizing sensor-net lifetimes and will drive new models for fundamental energy/bandwidth/data rate tradeoffs in this scenario. 17

Sally Floyd’s funding currently comes from two NSF grants. 1. “Addressing Fundamental Issues for Robust Internet Performance”, ITR/ANI grant 0205519, 2002-2007. The research for this grant is on techniques to make Internet protocols and mechanisms robust over a wide range of conditions, including robust performance with extreme envirionments, distributed stresses, and new forms of failure. Sally’s research under this grant has included research on HighSpeed TCP; Quick-Start for faster startup for transport protocols; the unreliable transport protocol DCCP (Datagram Congestion Control Protocol); and active measurements of interactions between transport protocols and middleboxes; 2. “Measurements, Models, and Simulation Scenarios for Internet Research”, ANI/STI grant 0230921, 2002-2005. The research in this project is directed towards improving measurements, improving the tools for evaluating measurement results and applying their results to models, and improving simulation scenarios used by researchers based on these models. Sally’s research for this grant has included active measurements of the evolution of transport protocols; research on modeling wireless links for the evaluation of transport protocols, of metrics for the evaluation of congestion control mechanisms, and the establishment of the Transport Modeling Research Group for the creation of Best Current Practices scenaros for simulation and experiment scenarios for the evaluation of congestion control mechanisms. Sally was involved in writing the proposal for NSF grant 0335290 on “Testing and Benchmarking Methodologies for Future Network Security Mechanisms”, but she made the decision to work only 50% time shortly after the proposal was funded, so she has never taken any funding from that proposal. Tom Henderson has no prior or current NSF support.

5 Statement of Work This Statement of Work defines a four-year development effort for the ns-3 project, involving the University of Washington, Georgia Tech University, and ICSI Center for Internet Research (ICIR).

5.1 Deliverables The main deliverable of the project will be the ns-3 simulator. The simulator will be based on the ns-2 software base, with components representing the basic models of the Internet hosts and infrastructure, including the components listed below, plus others as dictated by research priorities of the broader community. The software will be released according to a regular release schedule, and the project will maintain the infrastructure (web site, mailing list, development tools, documentation, etc.) necessary to successfully develop and disseminate the software.

5.2 Tasks 1. Core. Redesign and refactor the core of the ns-2 simulator to achieve better modularity, scalability (both runtime and memory consumption), and extensibility, while preserving backward compatibility with much of the existing ns-2 code base. o Consider scheduler design and event list reduction o Revisit node architecture and packet class design o Design for improved modularity of simulation code and components o Enable running on parallel (multi-core) processors o Enable distributed simulation on clusters o Enabling the porting of implementation code o Address backward compatibility for existing scripts 2. Integration. Build and extend a framework that allows the simulator to incorporate open-source implementation code, produce simulation output that can be analyzed by existing tools, and integrate with other research testbeds.

18

o Develop or port one or more abstraction layers allowing for protocol code to be run in simulations and on actual hardware with minimal change (e.g., recompilation only). o Develop emulation and code-driven interfaces to the simulator to allow driving of simulations with operational network nodes and with direct execution of network protocol code, respectively. o Develop a framework for providing output summary statistics or detailed event tracing for all simulation objects. Convert packet traces to a file format (libpcap) readable by third-party network analyzers. o Extend the existing emulation environment of ns-2 to allow for easy migration between simulation, clusterbased testbeds such as Emulab, and PlanetLab. 3. Protocol models. Build or extend protocol models corresponding to active or emerging IPv4, IPv6, 802.11, and sensor networks. The set of models shall build on the existing ns-2 models to include at least the following additions: o IPv6 protocols o SIP and voice over IP o standards-based unicast routing protocols (OSPF, IS-IS) o standards-based multicast routing (PIM-SSM) o middleboxes (firewall, NAT) o wireless (802.11a,b,e,g,n,s, 802.15.4, 802.16, GSM/GPRS, CDMA) o transport and congestion control (DCCP, others as the need arises) o peer-to-peer (BitTorrent, Gnutella) o Extend mobility models beyond random walk to include correlated mobility (groups of nodes moving together) and other models. o Update traffic generators to correspond to emerging network traffic patterns such as gaming, messaging, and peer-to-peer file sharing traffic. Sally Floyd maintains a list of these newer types of traffic generators (PackMime-HTTP, Harpoon, Surge) on her ICIR web page. 4. Education. Develop courseware for classes on computer networking at both the undergraduate and graduate level. Assemble a repository of scripts designed for educational purposes. o Continue the maintenance of an ns educational script repository, begun under the NSF CONSER project. o Make simulator output compatible with one or more animators such as nam or GTNetS Qt-based animator. o Provide an extensible graphical editor. o Provide simple, instructive (designed for ease of instruction), implementation-oriented models of Internet hosts and infrastructure. 5. Maintenance. Provide simulation components that assist in the design, composition, execution, and analysis of network simulations: o Functional and technical specifications for the new software design o Establish source code control system and development model, including tinderboxes for daily builds on different platforms o Create new validation test suites for the new simulator and models. Port validation scripts that do not work in backward compatibility mode. o Documentation and tutorials o Establish a web presence for collaborative software development, mailing lists, and dissemination of the software. o Attend and participate in annual program review meetings, at sites to be determined. The team shall participate in regular teleconferences. o Submit quarterly technical and financial status reports to the NSF Program Manager. All PIs and Investigators shall submit bi-annual technical summaries describing accomplishments over the past six months and future development plans. 19

5.3 Schedule The detailed schedule will be established upon program onset and updated at six-month intervals (the same time as the proposed release cycle). The schedule is expected to contain much higher granularity for near term milestones and be somewhat driven by the evolving interests and contributed code base of the user community. In the first six months, we anticipate accomplishing the following: o Establishment of website, source code control system, bug tracker, build infrastructure (tinderboxes) and mailing lists. o Functional and technical specs for the simulator. o Working (compiles and executes a few select models) skeleton framework of the new core of the simulator. o Continued maintenance of ns-2 as the project transitions.

6 Summary of Proposed Research The successful completion of the research proposed herein will result in a new public domain and open-source network simulation tool designed for use both by the networking research and educational community. Our tool (ns-3) will be designed and implemented by professional software developers, and managed by persons with significant experience both in networking research and in management of software development efforts. The PIs have extensive experience in network protocols, developing software, and managing software development projects. Our tool will be designed and implemented with rigorous standards, both in the design methodology and implementation. The simulator will be designed in a fashion similar to the design of real networks and real network protocols. This will lead to an easy–to–use and easy–to–extend tool in the hands of experienced networking researchers. Since the ns-3 implementation of some new protocol or networking methodology will be identical or nearly identical to an implementation of actual networks, researchers will automatically have an understanding of how to design and implement the simulation for their method. We will leverage many of the existing simulation models found in ns-2 and other public domain simulators, such as GTNetS and SSFNet, within the constraints of the new design methodology. For example, the Tcl/OTcl interfaces found in the current ns-2 tool will be retained, but in a backwards compatibility mode only. In most cases, most of the actual functionality of ns-2 is in the C++ portions of the implementation, and these will be modified to fit the new design framework wherever possible. We project that all new models will be developed in C++ only. New users to ns-3 will not need to learn or use multiple languages or understand interactions between OTcl and C++. The ns-3 tool will have both a novice and expert mode. Novices can construct simple simulations with an easy– to–use text–based configuration language, and will not need to interface with the C++ programming language at all. For more complicated scenarios or to extend the functionality of the simulator, users will use the C++ programming language as the simulation description language. To summarize, the ns-3 tool will be a professionally designed, full–featured simulation environment, designed by networking researchers and educators for use by the same. We expect that our ns-3 tool will quickly become the de facto standard for simulation–based networking research, much as its predecessor ns-2 has become.

20