removed ns3 related code
This commit is contained in:
Blake Harnden
parent
0a37a583ab
commit
4aeb16b866
18 changed files with 14 additions and 1574 deletions
|
|
@ -15,7 +15,6 @@ Current development focuses on the Python modules and daemon. Here is a brief de
|
|||
|gui|Tcl/Tk GUI|
|
||||
|man|Template files for creating man pages for various CORE command line utilities|
|
||||
|netns|Python C extension modules for creating CORE containers|
|
||||
|ns3|Experimental python ns3 script support for running CORE|
|
||||
|scripts|Template files used for running CORE as a service|
|
||||
|
||||
## Getting started
|
||||
|
|
|
|||
|
|
@ -1,9 +0,0 @@
|
|||
# Experimental Features
|
||||
|
||||
Below are current features that are considered experimental and will likely have issues.
|
||||
|
||||
# NS3
|
||||
|
||||
Experimental support for scripting CORE nodes with NS3.
|
||||
|
||||
[NS# Overview](ns3.md)
|
||||
|
|
@ -2,12 +2,12 @@
|
|||
|
||||
## Introduction
|
||||
|
||||
CORE (Common Open Research Emulator) is a tool for building virtual networks. As an emulator, CORE builds a
|
||||
representation of a real computer network that runs in real time, as opposed to simulation, where abstract models are
|
||||
used. The live-running emulation can be connected to physical networks and routers. It provides an environment for
|
||||
CORE (Common Open Research Emulator) is a tool for building virtual networks. As an emulator, CORE builds a
|
||||
representation of a real computer network that runs in real time, as opposed to simulation, where abstract models are
|
||||
used. The live-running emulation can be connected to physical networks and routers. It provides an environment for
|
||||
running real applications and protocols, taking advantage of virtualization provided by the Linux operating system.
|
||||
|
||||
CORE is typically used for network and protocol research, demonstrations, application and platform testing, evaluating
|
||||
CORE is typically used for network and protocol research, demonstrations, application and platform testing, evaluating
|
||||
networking scenarios, security studies, and increasing the size of physical test networks.
|
||||
|
||||
### Key Features
|
||||
|
|
@ -21,7 +21,7 @@ networking scenarios, security studies, and increasing the size of physical test
|
|||
| Topic | Description|
|
||||
|-------|------------|
|
||||
|[Architecture](architecture.md)|Overview of the architecture|
|
||||
|[Installation](install.md)|Installing from source, packages, & other dependencies|
|
||||
|[Installation](install.md)|Installing from source, packages, & other dependencies|
|
||||
|[Using the GUI](usage.md)|Details on the different node types and options in the GUI|
|
||||
|[Distributed](distributed.md)|Overview and detals for running CORE across multiple servers|
|
||||
|[Python Scripting](scripting.md)|How to write python scripts for creating a CORE session|
|
||||
|
|
@ -32,18 +32,17 @@ networking scenarios, security studies, and increasing the size of physical test
|
|||
|[EMANE](emane.md)|Overview of EMANE integration and integrating custom EMANE models|
|
||||
|[Performance](performance.md)|Notes on performance when using CORE|
|
||||
|[Developers Guide](devguide.md)|Overview of topics when developing CORE|
|
||||
|[Experimental](experimental.md)|Experimental features for use with or within CORE|
|
||||
|
||||
## Credits
|
||||
|
||||
The CORE project was derived from the open source IMUNES project from the University of Zagreb in 2004. In 2006,
|
||||
changes for CORE were released back to that project, some items of which were adopted. Marko Zec <zec@fer.hr> is the
|
||||
primary developer from the University of Zagreb responsible for the IMUNES (GUI) and VirtNet (kernel) projects. Ana
|
||||
The CORE project was derived from the open source IMUNES project from the University of Zagreb in 2004. In 2006,
|
||||
changes for CORE were released back to that project, some items of which were adopted. Marko Zec <zec@fer.hr> is the
|
||||
primary developer from the University of Zagreb responsible for the IMUNES (GUI) and VirtNet (kernel) projects. Ana
|
||||
Kukec and Miljenko Mikuc are known contributors.
|
||||
|
||||
Jeff Ahrenholz has been the primary Boeing developer of CORE, and has written this manual. Tom Goff designed the
|
||||
Python framework and has made significant contributions. Claudiu Danilov, Rod Santiago, Kevin Larson, Gary Pei,
|
||||
Phil Spagnolo, and Ian Chakeres have contributed code to CORE. Dan Mackley helped develop the CORE API, originally to
|
||||
Jeff Ahrenholz has been the primary Boeing developer of CORE, and has written this manual. Tom Goff designed the
|
||||
Python framework and has made significant contributions. Claudiu Danilov, Rod Santiago, Kevin Larson, Gary Pei,
|
||||
Phil Spagnolo, and Ian Chakeres have contributed code to CORE. Dan Mackley helped develop the CORE API, originally to
|
||||
interface with a simulator. Jae Kim and Tom Henderson have supervised the project and provided direction.
|
||||
|
||||
Copyright (c) 2005-2018, the Boeing Company.
|
||||
|
|
|
|||
171
docs/ns3.md
171
docs/ns3.md
|
|
@ -1,171 +0,0 @@
|
|||
# CORE / NS3
|
||||
|
||||
* Table of Contents
|
||||
{:toc}
|
||||
|
||||
**NOTE: Support for ns-3 is limited and not currently being developed.**
|
||||
|
||||
## What is ns-3?
|
||||
|
||||
[ns-3 network simulator](http://www.nsnam.org) is a discrete-event network simulator for Internet systems, targeted primarily for research and educational use. By default, ns-3 simulates entire networks, from applications down to channels, and it does so in simulated time, instead of real (wall-clock) time.
|
||||
|
||||
CORE can run in conjunction with ns-3 to simulate some types of networks. CORE network namespace virtual nodes can have virtual TAP interfaces installed using the simulator for communication. The simulator needs to run at wall clock time with the real-time scheduler. In this type of configuration, the CORE namespaces are used to provide packets to the ns-3 devices and channels. This allows, for example, wireless models developed for ns-3 to be used in an emulation context.
|
||||
|
||||
Users simulate networks with ns-3 by writing C++ programs or Python scripts that import the ns-3 library. Simulation models are objects instantiated in these scripts. Combining the CORE Python modules with ns-3 Python bindings allow a script to easily set up and manage an emulation + simulation environment.
|
||||
|
||||
## ns-3 Scripting
|
||||
|
||||
Currently, ns-3 is supported by writing Python scripts, but not through drag-and-drop actions within the GUI. If you have a copy of the CORE source, look under *ns3/examples/* for example scripts; a CORE installation package puts these under */usr/share/core/examples/corens3*.
|
||||
|
||||
To run these scripts, install CORE so the CORE Python libraries are accessible, and download and build ns-3. This has been tested using ns-3 releases starting with 3.11 (and through 3.16 as of this writing).
|
||||
|
||||
The first step is to open an ns-3 waf shell. [waf](http://code.google.com/p/waf/) is the build system for ns-3. Opening a waf shell as root will merely set some environment variables useful for finding python modules and ns-3 executables. The following environment variables are extended or set by issuing *waf shell*:
|
||||
|
||||
```shell
|
||||
PATH
|
||||
PYTHONPATH
|
||||
LD_LIBRARY_PATH
|
||||
NS3_MODULE_PATH
|
||||
NS3_EXECUTABLE_PATH
|
||||
```
|
||||
|
||||
Open a waf shell as root, so that network namespaces may be instantiated by the script with root permissions. For an example, run the *ns3wifi.py* program, which simply instantiates 10 nodes (by default) and places them on an ns-3 WiFi channel. That is, the script will instantiate 10 namespace nodes, and create a special tap device that sends packets between the namespace node and a special ns-3 simulation node, where the tap device is bridged to an ns-3 WiFi network device, and attached to an ns-3 WiFi channel.
|
||||
|
||||
```shell
|
||||
cd ns-allinone-3.16/ns-3.16
|
||||
sudo ./waf shell
|
||||
# use '/usr/local' below if installed from source
|
||||
cd /usr/share/core/examples/corens3/
|
||||
```
|
||||
|
||||
```python
|
||||
python -i ns3wifi.py
|
||||
# running ns-3 simulation for 600 seconds
|
||||
print session
|
||||
<corens3.obj.Ns3Session object at 0x1963e50>
|
||||
```
|
||||
|
||||
The interactive Python shell allows some interaction with the Python objects for the emulation.
|
||||
|
||||
In another terminal, nodes can be accessed using *vcmd*:
|
||||
|
||||
```shell
|
||||
vcmd -c /tmp/pycore.10781/n1 -- bash
|
||||
root@n1:/tmp/pycore.10781/n1.conf#
|
||||
root@n1:/tmp/pycore.10781/n1.conf# ping 10.0.0.3
|
||||
PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data.
|
||||
64 bytes from 10.0.0.3: icmp_req=1 ttl=64 time=7.99 ms
|
||||
64 bytes from 10.0.0.3: icmp_req=2 ttl=64 time=3.73 ms
|
||||
64 bytes from 10.0.0.3: icmp_req=3 ttl=64 time=3.60 ms
|
||||
^C
|
||||
--- 10.0.0.3 ping statistics ---
|
||||
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
|
||||
rtt min/avg/max/mdev = 3.603/5.111/7.993/2.038 ms
|
||||
root@n1:/tmp/pycore.10781/n1.conf#
|
||||
```
|
||||
|
||||
The ping packets shown above are traversing an ns-3 ad-hoc Wifi simulated network.
|
||||
|
||||
To clean up the session, use the Session.shutdown() method from the Python terminal.
|
||||
|
||||
```python
|
||||
print session
|
||||
<corens3.obj.Ns3Session object at 0x1963e50>
|
||||
session.shutdown()
|
||||
```
|
||||
|
||||
A CORE/ns-3 Python script will instantiate an Ns3Session, which is a CORE Session having CoreNs3Nodes, an ns-3 MobilityHelper, and a fixed duration. The CoreNs3Node inherits from both the CoreNode and the ns-3 Node classes -- it is a network namespace having an associated simulator object. The CORE TunTap interface is used, represented by a ns-3 TapBridge in *CONFIGURE_LOCAL* mode, where ns-3 creates and configures the tap device. An event is scheduled to install the taps at time 0.
|
||||
|
||||
**NOTE: The GUI can be used to run the *ns3wifi.py* and *ns3wifirandomwalk.py* scripts directly. First, *core-daemon* must be stopped and run within the waf root shell. Then the GUI may be run as a normal user, and the *Execute Python Script...* option may be used from the *File* menu. Dragging nodes around in the *ns3wifi.py* example will cause their ns-3 positions to be updated.**
|
||||
|
||||
Users may find the files *ns3wimax.py* and *ns3lte.py* in that example directory; those files were similarly configured, but the underlying ns-3 support is not present as of ns-3.16, so they will not work. Specifically, the ns-3 has to be extended to support bridging the Tap device to an LTE and a WiMax device.
|
||||
|
||||
## Integration details
|
||||
|
||||
The previous example *ns3wifi.py* used Python API from the special Python objects *Ns3Session* and *Ns3WifiNet*. The example program does not import anything directly from the ns-3 python modules; rather, only the above two objects are used, and the API available to configure the underlying ns-3 objects is constrained. For example, *Ns3WifiNet* instantiates a constant-rate 802.11a-based ad hoc network, using a lot of ns-3 defaults.
|
||||
|
||||
However, programs may be written with a blend of ns-3 API and CORE Python API calls. This section examines some of the fundamental objects in the CORE ns-3 support. Source code can be found in *ns3/corens3/obj.py* and example code in *ns3/corens3/examples/*.
|
||||
|
||||
## Ns3Session
|
||||
|
||||
The *Ns3Session* class is a CORE Session that starts an ns-3 simulation thread. ns-3 actually runs as a separate process on the same host as the CORE daemon, and the control of starting and stopping this process is performed by the *Ns3Session* class.
|
||||
|
||||
Example:
|
||||
|
||||
```python
|
||||
session = Ns3Session(persistent=True, duration=opt.duration)
|
||||
```
|
||||
|
||||
Note the use of the duration attribute to control how long the ns-3 simulation should run. By default, the duration is 600 seconds.
|
||||
|
||||
Typically, the session keeps track of the ns-3 nodes (holding a node container for references to the nodes). This is accomplished via the ```addnode()``` method, e.g.:
|
||||
|
||||
```python
|
||||
for i in xrange(1, opt.numnodes + 1):
|
||||
node = session.addnode(name = "n%d" % i)
|
||||
```
|
||||
|
||||
```addnode()``` creates instances of a *CoreNs3Node*, which we'll cover next.
|
||||
|
||||
## CoreNs3Node
|
||||
|
||||
A *CoreNs3Node* is both a CoreNode and an ns-3 node:
|
||||
|
||||
```python
|
||||
class CoreNs3Node(CoreNode, ns.network.Node):
|
||||
"""
|
||||
The CoreNs3Node is both a CoreNode backed by a network namespace and
|
||||
an ns-3 Node simulator object. When linked to simulated networks, the TunTap
|
||||
device will be used.
|
||||
"""
|
||||
```
|
||||
|
||||
## CoreNs3Net
|
||||
|
||||
A *CoreNs3Net* derives from *PyCoreNet*. This network exists entirely in simulation, using the TunTap device to interact between the emulated and the simulated realm. *Ns3WifiNet* is a specialization of this.
|
||||
|
||||
As an example, this type of code would be typically used to add a WiFi network to a session:
|
||||
|
||||
```python
|
||||
wifi = session.addobj(cls=Ns3WifiNet, name="wlan1", rate="OfdmRate12Mbps")
|
||||
wifi.setposition(30, 30, 0)
|
||||
```
|
||||
|
||||
The above two lines will create a wlan1 object and set its initial canvas position. Later in the code, the newnetif method of the CoreNs3Node can be used to add interfaces on particular nodes to this network; e.g.:
|
||||
|
||||
```python
|
||||
for i in xrange(1, opt.numnodes + 1):
|
||||
node = session.addnode(name = "n%d" % i)
|
||||
node.newnetif(wifi, ["%s/%s" % (prefix.addr(i), prefix.prefixlen)])
|
||||
```
|
||||
|
||||
## Mobility
|
||||
|
||||
Mobility in ns-3 is handled by an object (a MobilityModel) aggregated to an ns-3 node. The MobilityModel is able to report the position of the object in the ns-3 space. This is a slightly different model from, for instance, EMANE, where location is associated with an interface, and the CORE GUI, where mobility is configured by right-clicking on a WiFi cloud.
|
||||
|
||||
The CORE GUI supports the ability to render the underlying ns-3 mobility model, if one is configured, on the CORE canvas. For example, the example program :file:`ns3wifirandomwalk.py` uses five nodes (by default) in a random walk mobility model. This can be executed by starting the core daemon from an ns-3 waf shell:
|
||||
|
||||
```shell
|
||||
sudo bash
|
||||
cd /path/to/ns-3
|
||||
./waf shell
|
||||
core-daemon
|
||||
```
|
||||
|
||||
and in a separate window, starting the CORE GUI (not from a waf shell) and selecting the *Execute Python script...* option from the File menu, selecting the *ns3wifirandomwalk.py* script.
|
||||
|
||||
The program invokes ns-3 mobility through the following statement:
|
||||
|
||||
```python
|
||||
session.setuprandomwalkmobility(bounds=(1000.0, 750.0, 0))
|
||||
```
|
||||
|
||||
This can be replaced by a different mode of mobility, in which nodes are placed according to a constant mobility model, and a special API call to the CoreNs3Net object is made to use the CORE canvas positions.
|
||||
|
||||
```python
|
||||
session.setuprandomwalkmobility(bounds=(1000.0, 750.0, 0))
|
||||
session.setupconstantmobility()
|
||||
wifi.usecorepositions()
|
||||
```
|
||||
|
||||
In this mode, the user dragging around the nodes on the canvas will cause CORE to update the position of the underlying ns-3 nodes.
|
||||
Loading…
Add table
Add a link
Reference in a new issue