close Warning: Can't synchronize with repository "(default)" ("(default)" is not readable or not a Git repository.). Look in the Trac log for more information.

Changes between Version 23 and Version 24 of Internal/SystemPrototyping/Software


Ignore:
Timestamp:
Apr 4, 2013, 2:46:33 PM (11 years ago)
Author:
nkiran
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Internal/SystemPrototyping/Software

    v23 v24  
    1414User-level processes either within a framework such as the extensible open source routing platform (XORP), or as standalone processes, will implement inter and intra-domain routing protocols, management services, and network-support services such as name resolution. 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 forwarding tables computed by the control plane are pushed down to the forwarding engine through exported interfaces.
    1515
    16 [wiki:SystemPrototyping/Software/ClickRouter Component Details]
     16[wiki:SystemPrototyping/Software/Projects/ClickRouter Project Page]
    1717
    1818=== 2.2. Global Name Resolution Service (GNRS) ===
     
    2222In present implementation, GNRS is a user-level process that is run on each router node to handle queries from the router or host protocol stack. The id-locator mappings for a GUID is 'hosted' on a node determined by a hash function with the GUID as a param. Therefore mappings are distributed among the address space of the nodes that participate in this hosting. One implemented scheme places mappings at the AS whose number is derived by hashing the GUID to the participating ASes in the network. Mappings hosted at each server are persistent, while being served out of in-memory caches for low latency. The implementation also allows the use of multiple hash functions to place a mapping a multiple hosts - providing reliability under partial failures, and improved lookup times by going to the nearest replica among the set.
    2323
    24 [wiki:SystemPrototyping/Software/RutgersGNRS Component Details]
     24[https://bitbucket.org/romoore/gnrs/wiki/Home Project Page]
    2525
    2626
     
    3131The host protocol stack implements a thin transport layer (handling message chunking, message ordering), network layer (GUID services, temp. storage, ad-hoc routing), and a upper link-layer (reliable, hop-by-hop data transport). It also implements an interface manager that can take as input user policy and network conditions to implement smart use of interfaces for performance, energy or other cost-metric optimization. The stack implementation and the network API allow for extensibility and customization of stack functions.
    3232
    33 [wiki:SystemPrototyping/Software/HostStack Component Details]
    34 
    35 == 3. Releases ==
    36 
    37 No public releases yet.
    38 
    39 == 4. ORBIT Evaluation ==
    40 
    41 Early versions of the prototype !MobilityFirst (MF) network consisting of: (1.) Click-based router, (2.) a distributed name resolution service, and (3.) client network API and host protocol stack are available for evaluation on the ORBIT testbed. The steps involved in evaluating sample configurations are listed below. Before you begin, it is suggested that your familiarize yourself with the [http://mytestbed.net/projects/omf/wiki/OMF_Main_Page OMF] framework, which is used to setup and orchestrate these experiments.
    42 
    43 === 4.1. Deploying !MobilityFirst on ORBIT nodes ===
    44 
    45 The deployment can be done in one of the following ways:
    46 
    47  1. Installing an MF release (tarball or SVN revision) and dependencies on a base ORBIT image
    48  1. Imaging ORBIT nodes with a pre-established MF disk image
    49 
    50 === 4.2 MF Disk Images for ORBIT ===
    51 
    52 An MF disk image contains all components (router, gnrs, and client stack and network API library - sources and precompiled binaries) and can be installed on nodes using [http://mytestbed.net/projects/omf/wiki/OMF_Main_Page OMF] tools.
    53 
    54 All images listed below are stored at repository1.orbit-lab.rutgers.edu:/export/omf/omf-images-5.2:
    55 '''Images Currently In Use'''
    56 
    57 ||'''Image Name'''||'''Created on'''||'''MF Release'''||'''Description'''||
    58 ||''mf-proto-rc1_0.ndz''|| 4-18-2012 || rc1.0 || End-to-end integrated layer 2 with MF Network API, MF host stack and an MF Router with GSTAR, and GNRS interface, distributed 'in-network' GNRS ||
    59 ||''mf-proto-gec12.ndz''|| 11-1-2011 || - || 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 ||
    60 ||''mf-proto-trial3.ndz''|| 9-22-2011 || - || MF node with router, gnrs and client modules - OMF script configures node function. GUID assignment and topology choice from OMF script||
    61 
    62 Loading a particular image is done using the 'load' command:
    63 
    64 {{{
    65 > omf load <node-set> <image-name>
    66 
    67 e.g.,
    68 
    69 > omf-5.X load [[1,1], [1,2], [1,3]] mf-proto-1.0.ndz
    70 
    71 }}}
    72 
    73 'X' in the command above refers to the version of OML control framework. Presently, 5.2 and 5.3 are most used.
     33[wiki:SystemPrototyping/Software/Projects/MobilityStack Project Page]
    7434
    7535
    76 === 4.3. Inside a !MobilityFirst Image ===
    77 
    78 ==== 4.3.1. Code Base ====
    79 
    80 The image holds the prototype code base under ''/usr/local/mobilityfirst/code''. It has the following top-level directories:
    81  * click - Router elements implementing storage-aware routing, hop-by-hop reliable link-level data transport, and interface to GNRS service. This also has elements that implement Click-based sender and receiver applications.
    82  * gnrsd - C++ implementation of a GNRS server, and an interactive GNRS client.
    83 
    84  * client - C implementations of client API and stack that compile for Linux and Android platforms. Also has sample sender and receiver applications using the API
    85  * eval 
    86 
    87 ==== 4.3.2. Binaries, Configuration Files ====
    88 
    89  1. bin - compiled binaries go here
    90  1. conf - config files from across sub projects, incl. click and gnrs configurations
    91  1. scripts - e.g., to initialize Click execution
    92  1. topology - definition files used within the MF router to enforce connectivity among nodes
    93 
    94 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.
    95 
    96 ==== 4.3.3. Boot Script ====
    97 
    98 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:
    99 
    100 
    101 {{{
    102 ...
    103 
    104 MF_DIR=/usr/local/mobilityfirst
    105 MF_CLICK_ELEMENTS_DIR=$MF_DIR/code/click/elements
    106 CLICK_DIR=/usr/local/src/click
    107 
    108 #update mobilityfirst prototype code base
    109 cd $MF_DIR/code
    110 
    111 #auto-update disabled pending anonymous account
    112 #svn update
    113 
    114 #Compile user-level click after copying MF's click elements into click codebase
    115 rsync -vt $MF_CLICK_ELEMENTS_DIR/gstar/* $CLICK_DIR/elements/local
    116 
    117 cd $CLICK_DIR
    118 ./configure --disable-linuxmodule --enable-local
    119 make elemlist
    120 make install
    121 
    122 ...
    123 
    124 }}}
    125 
    126 The output of the boot script is appended to ''/var/log/mf-proto-boot.log''.
    127 
    128 === 4.4. Updating or Customizing an Existing MF Image ===
    129 
    130 The installed MF source can be updated to a latest release either from the SVN or using a release tar ball. If updating to latest SVN version, you simply run the update command from under the ''/usr/local/mobilityfirst/code'' dir. If customizing to a particular MF version from SVN or using a newer tar ball, first delete contents under the ''code'' dir before installing. Similarly, one can also update 3rd party components like Click while creating an updated MF image.
    131 
    132 For compiling an updated code base, we currently have a simple 'make' bash script (''/usr/local/mobilityfirst/code/boot/mf-proto'') that combines several steps. Usually, the compiled MF binaries are installed under ''/usr/local/mobilityfirst/bin''. However, the 3rd party components we use are in various locations. For example the source for Click modular router is under ''/usr/local/src/click'', and it's compiled binary ends up under ''/usr/local/bin''. Therefore, before building the Click-based router, the MF-Click elements that implement the protocol stack are to be installed under Click's designated source dir (''/usr/local/src/click/elements/local'' to be specific). So, the bash compilation script does all such steps for the router, gnrs, host protocol stack and network API library components, placing the compiled binaries in proper locations.
    133 
    134 Once the source has been updated, the following compiles and installs binaries. Alternately, one can also update just individual components and run the local make and copy binaries to proper locations.
    135 
    136 {{{
    137 
    138 > /usr/local/mobilityfirst/code/boot/mf-proto #compilation script
    139 
    140 }}}
    141 
    142 Once ready with all upgrades and want to create a new MF image, you have to run an ORBIT 'prepare' script to among other things ensures the package manager caches are cleaned, and interfaces are configured appropriately when creating a general disk image that can be booted on a variety of hardware nodes.
    143 
    144 {{{
    145 
    146 > cd /root
    147 
    148 > ./prepare.sh #common ORBIT script to prepare file systems for creating an image
    149 
    150 }}}
    151 
    152 The ''prepare.sh'' script above will also log you out and turn the node off, following which you can save the newly created image by using the OMF save command:
    153 
    154 {{{
    155 
    156 > omf-5.X save [1,1]
    157 
    158 }}}
    159 
    160 The resulting image can be found at ''repository1:/export/omf/omf-5.X/'' and can be used to image nodes for subsequent experiments.
    161 
    162    
    163 === 4.5. Configuring and Running !MobilityFirst Experiments ===
    164 
    165 While custom scripting can be used to execute an experiment, OMF has all necessary functionality to reliably configure and repeat experiments on the ORBIT testbed. Both the configuration details (what nodes run what applications with what parameters) and the experiment execution control (when to run what) can be specified within a ruby script using omf syntax. Refer to [http://mytestbed.net/projects/omf/wiki/OMF_User_Guide OMF User Guide] to get familiar with writing OMF scripts. In the next section, we present several sample scripts to get you started with MF network experimentation.
    166 
    167 Once you define an experiment script, and have loaded the MF image on the nodes that will run MF components, you run the experiment using the 'exec' command:
    168 
    169 {{{
    170 
    171 > omf-5.X exec my-mf-expt.rb
    172 
    173 }}}
    174 
    175 The omf runtime reports any failure to bring up components. For more detailed information, refer to the logs created by MF components - all located under ''/var/log''. Additionally, MF components (only Click-based router presently) are instrumented to report key statistics which are then logged to relational tables hosted on an OML server co-located with the testbed. Section on 'OML-based Monitoring' has more details.
    176 
    177 === 4.6. Sample OMF Scripts for ORBIT ===
    178 
    179 ==== 4.6.1 Test Config 1: Sender-Router-Receiver ====
    180 
    181 Below is the simple topology:
    182 {{{
    183          S ---- MFR ---- R
    184 
    185 S-Sender Host, MFR - MobilityFirst Router, R - Receiver Host
    186 }}}
    187 
    188 
    189 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:
    190 
    191 {{{
    192 #syntax: <node-GUID> <neighbor-count> <neighbor-GUID1> [<neighbor-GUID2>] ...
    193 1 1 2
    194 2 2 1 3
    195 3 1 2
    196 }}}
    197 
    198 __Files__:
    199 [https://mobilityfirst.orbit-lab.org/browser/trunk/code/prototype/eval/scripts/omf/testcfg_1-gstar_3node.rb OMF script] |  [https://mobilityfirst.orbit-lab.org/browser/trunk/code/prototype/eval/topology/testcfg_1-gstar_3node.tp topology file]
    200 
    201 
    202 ==== 4.6.2. Test Config 2: Multiple Senders and Receivers ====
    203 
    204 Below is the topology:
    205 {{{
    206                  S2
    207                  |
    208                  |
    209          S1 ---- MFR1 ----- MFR2 ---- MFR3 ---- R1
    210                                        |
    211                                        |
    212                                        R2
    213 
    214 S-Sender Host, MFR - MobilityFirst Router, R - Receiver Host
    215 }}}
    216 
    217 __Files__:
    218 [https://mobilityfirst.orbit-lab.org/browser/trunk/code/prototype/eval/scripts/omf/testcfg_2-gstar_7node_multiflow.rb OMF script] |  [https://mobilityfirst.orbit-lab.org/browser/trunk/code/prototype/eval/topology/testcfg_2-gstar_7node_multiflow.tp topology file]
    219 
    220 
    221 === 4.7. Steps to run experiment ===
    222 
    223  1. Choose and reserve a testbed with OMF support and required number of nodes. ORBIT has a 400 node grid, but also has 9 sandboxed testbeds sb1-sb9 more suitable for smaller experiments.
    224  1. Image the nodes with an established (and compatible, see compatibility notes below) MF image from list of available  OR image the nodes with a baseline ORBIT image followed by install of MF release from SVN or tarball
    225  1. Determine the node set you will use for the experiment and ensure they are available, imaged and working.
    226  1. Modify OMF ruby script provided to use the chosen nodes. For example, if you choose nodes node1-1, node1-3, node1-4 (ORBIT hostnames, domain part depends on chosen testbed), then modify the statically defined node set in the ruby script as shown below:
    227 {{{
    228 ...
    229 
    230 #static topo with available nodes
    231 #defTopology('static_universe', [[1,1],[1,2],[1,3]]) - original
    232 defTopology('static_universe', [[1,1],[1,3],[1,4]])
    233 baseTopo = Topology['static_universe']
    234 
    235 ...
    236 
    237 }}}
    238  1. Execute the script using appropriate version of omf tools. For example, the node naming conventions used above (as points in a grid: ![1,1]) is valid for OMF version 5.2, but invalid for versions 5.3 and above which use FQDN to identify hosts.
    239 
    240 
    241 === 4.8. Test Script to MF Image Compatibility ===
    242 
    243 Owing to feature additions and/or interface modifications, older OMF scripts may be incompatible - despite our best efforts - when used against newer MF versions and images . Here is what we understand at present:
    244 
    245 ||             ||mf-proto-trial3.ndz||mf-proto-gec12.ndz||mf-proto-rc1_0.ndz||
    246 ||Test Config 1|| No || No || Yes ||
    247 ||Test Config 2|| No || No || Yes ||
    248 
    249 
    250 === 4.9. Test Script to MF Release Compatibility ===
    251 
    252 No releases yet.
    253 
    254 == 5. GENI Evaluation ==
    255 
    256 [http://www.geni.net/ 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.
    257 
    258 [http://www.protogeni.net/trac/protogeni/ 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.
    259 
    260 The following links provide the basic information to learn about ProtoGENI and to get started with experimentation:
    261 
    262  * [http://www.protogeni.net/trac/protogeni/wiki/Tutorial ProtoGENI Tutorial] with basics on
    263    * Creating an account with one of the Clearing houses (e.g., Utah Emulab or BBN)
    264    * Setting up certificate (with managers) and key-based (with individual hosts) authentication and authorization
    265    * Steps and test scripts for finding and reserving resources on ProtoGENI
    266 
    267  * Quering and Reserving Resources can be done using either of following:
    268    * [http://www.protogeni.net/trac/protogeni/wiki/Flack Flack]: a graphical map interface. [http://www.protogeni.net/trac/protogeni/wiki/FlackManual Flack Manual]
    269    * [http://trac.gpolab.bbn.com/gcf/wiki/Omni Omni]:  a command line tool for reserving resources across control frameworks
    270    * [http://www.protogeni.net/trac/protogeni/wiki/TestScripts ProtoGENI Test Scripts] that can be used as starting point to get familiar with ProtoGENI interfaces and to ensure account is set up right
    271 
    272 
    273 == 6. !MobilityFirst Prototype Demonstrations ==
    274 
    275  1. [wiki:SystemPrototyping/Software/Demonstrations Generalized Storage-Aware Routing] - GEC-12, Kansas City, MI, Nov 2, 2012
    276  1. [wiki:SystemPrototyping/Software/Demonstrations Receiver-Controlled Multi-Homing] - !HotMobile'12, San Diego, CA, Feb 28, 2012
    277  1. [wiki:SystemPrototyping/Software/Demonstrations Robust Content Delivery to Multi-homed Mobile] - GEC-13, Los Angeles, CA, Mar 13, 2012
    278  1. [wiki:SystemPrototyping/Software/Demonstrations Openflow-controlled Routing ByPass] - WINLAB Industrial Advisory Board Meeting (IAB), WINLAB, May 14, 2012