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

Timestamp:

Jun 4, 2012, 6:31:42 PM (12 years ago)

Author:

nkiran

Comment:

--

Internal/SystemPrototyping/Software

@@ -8 +8 @@
 
 === 2.1. Router === 
-Our Linux-based prototype router, as shown 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. Alternate, OpenFlow-based implementations where routing and network support services may be implemented as modules in a central controller, are being considered separately. Performance may further improve by pushing the forwarding engine down into a programmable network hardware such as the 1Gbit or 10Gbit NetFPGA card, to achieve a line-rate implementation.  
+Our Linux-based prototype router, as shown 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. An alternate !OpenFlow-based implementation, where routing and network support services may be implemented as modules in a central controller, is also under consideration. Performance may further be pushed by implementing the forwarding engine on a programmable network hardware platform such as the Stanford NetFPGA card (available as 1 or 10 Gbit port versions), to achieve line-rate implementation and evaluations of the !MobilityFirst protocols.  
 
 In our Click-based implementation, C++ data-path elements implement the following base components: 1.) a link-level reliable, hop-by-hop data transport,  2.) a fast store/forward-aware forwarding table lookup, and 3.) a store manager to temporarily hold packets that cannot be forwarded at this time. The Click-based router supports one or more logical interfaces which can be either wired or wireless. It also attempts to allocate and isolate memory and processing resources to sustain reasonable data rates across each interface.
@@ -20 +20 @@
 Name resolution is a targeted to be a globally distributed service with GNRS servers imagined to be co-located with routing elements. They are required to provide low-latency ''lookup'' (and ''update'') of id to locator bindings, and service is expected to scale to GUID space which identify network objects in MF. 
 
-In 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.
+In 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.
 
 [wiki:SystemPrototyping/Software/RutgersGNRS Component Details]
@@ -48 +48 @@
  1. Imaging ORBIT nodes with a pre-established MF disk image 
 
-==== 4.2 MF Disk Images for ORBIT ====
+=== 4.2 MF Disk Images for ORBIT ===
 
 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. 
@@ -74 +74 @@
 
 
-==== 4.3. Inside a !MobilityFirst Image ====
-
-===== 4.3.1. Code Base =====
+=== 4.3. Inside a !MobilityFirst Image ===
+
+==== 4.3.1. Code Base ====
 
 The image holds the prototype code base under ''/usr/local/mobilityfirst/code''. It has the following top-level directories:
@@ -85 +85 @@
  * eval  
 
-===== 4.3.2. Binaries, Configuration Files =====
+==== 4.3.2. Binaries, Configuration Files ====
 
  1. bin - compiled binaries go here
@@ -94 +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.
 
-===== 4.3.3. Boot Script =====
+==== 4.3.3. 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:
@@ -236 +236 @@
 
 }}}
- 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.
+ 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.
 
 
@@ -251 +251 @@
 
 No releases yet.
-
-
-==== 6.2 GENI-based ====
 
 == 5. GENI Evaluation ==