= System Prototyping Projects = The following are the main !MobilityFirst system prototyping projects: == 1. Click-based Software Router == This a proof-of-concept prototyping effort to implement and validate the workings of the control protocols and, to a limited extent, explore the system design of the data plane. The [http://read.cs.ucla.edu/click/ Click Modular Router] offers a flexible platform at both user-level and kernel-level to implement protocols and data plane handling in a intuitive pipeline design. The initial effort is in user-space. [https://mobilityfirst.orbit-lab.org/wiki/SystemPrototyping/Projects/ClickRouter Project Page] == 2. SDN Implementation of !MobilityFirst Protocols using !OpenFlow == SDNs offer a different perspective to control plane management where control logic is centralized and direct simple forwarding elements with flow rules. While the software router project explores control functionality as distributed protocols, here we explore the control-plane performance, scalability and multi-domain coordination aspects when implementing !MobilityFirst routing and name-resolution functions as central services. [https://www.opennetworking.org/standards/intro-to-openflow OpenFlow], the prevailing 'forwarding-instruction-set' standard, will be used as the SDN language with a suitable controller (e.g., !FloodLight, NOX) and !OpenFlow-enabled switches. The limited definition of the standard is expected to present challenges for implementing clean slate protocols, in particular forwarding on large, flat identifiers. Exploring efficient storage/compute functions on the forwarding plane will be novel on this platform. [https://mobilityfirst.orbit-lab.org/wiki/SystemPrototyping/Projects/SDNOpenFlow Project Page] == 3. NetFPGA Implementation of !MobilityFirst Forwarding Plane == With the [http://netfpga.org/ NetFPGA] line-rate (1G and 10G) research platform, we can explore close-to-hardware challenges such as fast lookups and packet buffering to achieve line-rate forwarding for !MobilityFirst. The availability of a choice of on-chip (logic slices, block RAMs) and off-chip (SRAM and DRAM, and over-PCI host DMA access) resources, presents an interesting design space for implementing lookup, buffering and any other packet handling ops. Our focus here is on designing a forwarding plane that handles a multi-class workload (e.g., L2 label switching, L3 GUID routing, L3 NA routing) that differ significantly in lookup complexity. A hierarchical cache-type handling of the large GUID lookup table (LUT) is also being considered. [https://mobilityfirst.orbit-lab.org/wiki/SystemPrototyping/Projects/NetFPGARouter Project Page] == 4. DMap: In-Network Global Name Resolution Service == The GUID to network address (NA) mapping(s) for network objects need sub-100msec access latencies for both update and lookup operations, if we are to support real-time, CBR or interactive communication. In this service design, we propose all entities in the network namespace (e.g., an autonomous system (AS), or ISP) coordinate to host a global GNRS service plane. Servers are co-located with the routing fabric, and GUID-NA mappings are distributed by partitioning the GUID space among the ASs. Replication and caching mechanisms are built-in for higher performance (i.e., lower latency), reliability and trust. A reference design for the GNRS server is being developed in Java. [https://bitbucket.org/romoore/gnrs/wiki/Home Project Page] == 5. !MobiStack: Linux & Android !MobilityFirst Host Protocol Stack and Service API == We are building a proof-of-concept protocol stack to include a basic transport layer (message chunking, e-2-e acks, flow control), GUID service layer, storage aware routing, and hop-by-hop link data transport. The clean slate implementation will export a GUID-centered API with message-based communication primitives, and rich delivery service options (e.g., DTN, real-time, multicast, etc). We will also explore a 'network interface manager' functionality to enable policy driven multi-homing that could flexibly address user/application stated goals of performance, reliability, battery lifetime, network svc. payments, etc. The protocol stack will be implemented in C/C++ and will be standalone user-level process, while apps will link to the service API library to use the new stack. [https://mobilityfirst.orbit-lab.org/wiki/SystemPrototyping/Projects/MobilityStack Project Page] == 6. Applications == The service API targets a simpler and unifying interface to applications whose networking demands could span host-mobility, simplified and direct content addressing, infrastructure-less or disconnected operation, group multicast or anycast delivery, and location and/or contextual addressing. In this project we will look to develop new generation apps that are location/context aware, as well as port some pre-existing to demonstrate usefulness of the new API and network services. [https://mobilityfirst.orbit-lab.org/wiki/SystemPrototyping/Projects/MFApps Project Page] == 7. Router Evaluation Workload == [https://mobilityfirst.orbit-lab.org/wiki/SystemPrototyping/Projects/RouterWorkload Project Page] == 8. Mobility First M2M == [https://mobilityfirst.orbit-lab.org/wiki/SystemPrototyping/Projects/MFMtM Project Page]