wiki:Internal/SystemPrototyping/Software
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.

MobilityFirst Prototype

1. Overview

2. Components

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. 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.

User-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.

Project Page

2.2. Global Name Resolution Service (GNRS)

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.

Project Page

2.3. Host Stack and Network API

In our clean slate approach to networking, we propose a new socket-like API to interface with services offered by MF. Services include name resolution, message-oriented communication, intentional data receipt, context and location management, and content retrieval. API is available to applications as user-level library, which interacts with the protocol stack passing control and data messages between the two. A few sample applications exist in the code base and more are being worked on.

The 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.

Project Page

Last modified 11 years ago Last modified on Apr 4, 2013, 2:46:33 PM
Note: See TracWiki for help on using the wiki.