| Version 14 (modified by , 13 years ago) ( diff ) |
|---|
Table of Contents
MobilityFirst Prototype
Overview
Components
MF Router
The router prototype is Linux-based, and, as depicted in Figure 1, follows a two-level emulation setup: a fast data path handled by a forwarding engine, and a control path implemented at user-level. The Click Modular router will embody the forwarding engine in our primary prototype and will run on commodity x-86 hardware. Alternately, routing and network support services can be implemented as modules within an OpenFlow-based architecture within a central controller to direct one or more forwarding switches. Performance may also be further boosted by porting forwarding components into programmable network hardware such as the 1Gbit or 10Gbit NetFPGA cards, to achieve line-rate implementations.
In our Click-based implementation, C++ data-path elements will implement the following: 1.) a reliable link-level, hop-by-hop transport manager, 2.) a fast, storage-aware route lookup module, and 3.) a cache manager to support in-network caching of content. Underlying x-86 hardware may support one or more wired/wireless interfaces, and commensurate memory and processing resources to sustain reasonable data rates across each interface.
User-level processes either within a framework such as the extensible open source routing platform (XORP), or as standalone processes, will implement routing and management services, and network-support services such as the name resolution service. Messages exchanged by these user-level services with other routers are forwarded through the Click engine through host receive and transmit queues. Updates to the routing information base computed by the control plane, is pushed down promptly to the forwarding engine for up-to-date next-hop lookups.
MF Host
In our clean slate approach to networking, we propose a new socket API for applications. This API along with the stack implementation of MF protocols will support name resolution, send/receive of messages, specification for intentional data receipt, context and location management, content retrieval, as also querying of network state to determine link and path quality information. This API is implemented as user-level libraries that applications can link to. As part of the prototyping and evaluation, we plan on programming both novel and traditional applications to use this new API and protocol stack.
Releases
ORBIT Evaluation
An early version of the prototype MobilityFirst (MF) network consisting of: (1.) Click-based routers, (2.) a distributed name resolution service, and (3.) client network API and stack (with sample applications written to this API), can be deployed on the ORBIT testbed and evaluated using OMF. The deployment can be done in one of the following ways:
- Baseline ORBIT image and MF release tarball, or
- MF disk image with pre-installed MF components
The following sections detail these two methods and provide sample omf scripts for simple evaluations of the MF prototype.
MF Disk Images for ORBIT
An MF disk image contains all of router, gnrs, and client api/stack (sources + precompiled binaries) and can be installed on ORBIT nodes using OMF tools. Once the image is loaded, experiment details such as node specialization (whether router, gnrs server, client), process control, interface configuration and topology can be managed directly through OMF execution scripts. Further, prototype components on these images have been instrumented to enable monitors to capture and report liveness and relevant stats to a central repository using ORBIT Measurement Library (OML) framework for offline (or even during the experiment) analysis.
All images listed below are stored at repository1.orbit-lab.rutgers.edu:/export/omf/omf-images-5.2, and can be loaded onto a set of orbit nodes from the console as:
> omf load <node-set> <image-name> e.g., > omf load [[1,1], [1,2], [1,3]] mf-proto-1.0.ndz
Images Currently In Use
| Image Name | Created on | MF Release | Description |
| mf-proto-gec12.ndz | 11-1-2011 | unnamed | End-to-end integrated layer 2 with MF Network API, MF host stack and an MF Router with GSTAR. Router partially integrated with locally running GNRS server |
| mf-proto-trial3.ndz | 9-22-2011 | unnamed | MF node with router, gnrs and client modules - OMF script configures node function. GUID assignment and topology choice from OMF script |
Details Common Across Images
MF Codebase
The image holds the 'latest release' of MF prototype code base in /usr/local/mobilityfirst. It has the following top-level directories:
- code - sources for the following sub-projects:
- android - C implementations of client API and stack that compile for Linux and Android platforms. Also has sample sender and receiver applications using the API
- click - Router elements implementing storage-aware routing and hop-by-hop reliable link-level data transport. Also has elements that implement Click-based sender and receiver clients.
- gnrsd - C++ implementation of a GNRS server, and an interactive GNRS client.
- bin - compiled binaries go here
- conf - config files from across sub projects, incl. click and gnrs configurations
- scripts - e.g., to control Click execution
- topology - definition files used within Click router to enforce connectivity among nodes
Also installed on this image are the dependencies for the router, gnrs, and client components. A complete list of installed dependencies can be found in the README accompanying the code base.
Binaries and Source Updates
The image comes with pre-compiled MF binaries installed in /usr/local/mobilityfirst/bin. The one exception to the location is the Click-based MF router. Click's compilation set up requires MF elements to be installed under it's source root to be made available to the Click run-time. Therefore source for MF's router elements have been copied to appropriate Click directory (/usr/local/src/click) and the resulting Click binary is available under /usr/local/bin/click
The installed source can be updated, however, to a later MF release and compiled using the Makefile set-up under /usr/local/mobiltyfirst (TODO). Similarly, one can update dependencies such the version of Click, and generate new binaries. The resulting installation can be stored using OMF as a new custom MF image to be used in following evaluations.
Boot Script
The image also contains a boot script (/etc/init.d/mf-proto) that can be used to automate the update/compile functions. It updates the local codebase to the latest release from MF SVN, (TODO - auto updating is currently disabled, pending the creation of an anonymous account access to MF SVN), and then compiles and installs Click and other MF component binaries as described above. Excerpt below from the boot script shows the update and compilation of the click router:
... MF_DIR=/usr/local/mobilityfirst MF_CLICK_ELEMENTS_DIR=$MF_DIR/code/click/elements CLICK_DIR=/usr/local/src/click #update mobilityfirst prototype code base cd $MF_DIR/code #auto-update disabled pending anonymous account #svn update #Compile user-level click after copying MF's click elements into click codebase rsync -vt $MF_CLICK_ELEMENTS_DIR/gstar/* $CLICK_DIR/elements/local cd $CLICK_DIR ./configure --disable-linuxmodule --enable-local make elemlist make install ...
The output of the boot script is appended to /var/log/mf-proto-boot.log.
Sample OMF Scripts for ORBIT
Test 1: Storage-Aware Routing with Sender-Router-Receiver
Below is the simple topology:
S ---- MFR ---- R S-Sender, MFR - MobilityFirst Router, R - Receiver
The topology in these experiments is enforced within the Click implementations by a GUID-based connectivity graph specified by a topology file passed to click. The following lines in the topology file define the above graph:
#syntax: <node-GUID> <neighbor-count> <neighbor-GUID1> [<neighbor-GUID2>] ... 1 1 2 2 2 1 3 3 1 2
Files: OMF script | topology file
Test 2: Storage-Aware Routing with Multiple Senders and Receivers
Below is the topology:
S2
|
|
S1 ---- MFR1 ----- MFR2 ---- MFR3 ---- R1
|
|
R2
S-Sender, MFR - MobilityFirst Router, R - Receiver
Files: OMF script | topology file
Test 3: Use of GNRS in Internet Routing
Current testing topology
S1 ---- MFR1 ----- MFR2 ---- MFR3 ---- R1
S-Sender, MFR - MobilityFirst Router, R - Receiver
Targeted demo scenario:
|----------------------| |----------------------|
| | | |
S1 ----|- MFR1 ----- MFR2 ----|---- MFR0 -------|- MFR1 ----- MFR2 ----|-----R
| \ / | | \ / |
| \ / | | \ / |
| MFR3<--------|----DTNNode -----|--------> MFR3 |
| | | |
| NA1 | | NA2 |
|----------------------| |----------------------|
S-Sender, MFR - MobilityFirst Router, R - Receiver
Evaluation on GENI
GENI, an NSF-funded proposal for a global environment for network innovation, is a multi-group collaborative effort to realize an at-scale experimental network infrastructure that is rich (i.e., with wired and wireless resources, commercial and experimental platforms) and allows for deep programmability.
ProtoGENI is the prototype implementation and deployment of GENI. ProtoGENI is also the control framework for a number of GENI resources currently deployed on the national backbone and at several participating campuses. It is worth noting, however, that there are several GENI deployments that use other control frameworks and experimentation across ProtoGENI and these deployments is currently set up via personnel coordination/manual configuration.
The following links provide the basic information to learn about ProtoGENI and to get started with experimentation:
- ProtoGENI Tutorial with basics on
- Creating an account with one of the Clearing houses (e.g., Utah Emulab or BBN)
- Setting up certificate (with managers) and key-based (with individual hosts) authentication and authorization
- Steps and test scripts for finding and reserving resources on ProtoGENI
- Quering and Reserving Resources can be done using either of following:
- Flack: a graphical map interface. Flack Manual
- Omni: a command line tool for reserving resources across control frameworks
- ProtoGENI Test Scripts that can be used as starting point to get familiar with ProtoGENI interfaces and to ensure account is set up right
