MobilityFirst FIA Project: Status Summary & Technical OverviewNSF Visit, Oct 6, 2011
Contact: D. RaychaudhuriWINLAB, Rutgers University
Technology Centre of NJ671 Route 1, North Brunswick,
NJ 08902, [email protected]
WINLAB
MobilityFirst Project: Collaborating Institutions
(LEAD)
+ Also industrial R&D collaborations with AT&T Labs,Bell Labs, NTT DoCoMo,, Toyota ITC, NEC, Ericsson and others
D. Raychaudhuri, M. Gruteser, W. Trappe, R, Martin, Y. Zhang, I. Seskar, K. Nagaraja, S. Nelson
S. Bannerjee W. LehrZ. Morley Mao
B. Ramamurthy
G. ChenX. Yang, R. RoyChowdhury
A. Venkataramani, J. Kurose, D. Towsley
M. Reiter
Project Funded by the US National Science Foundation (NSF)Under the Future Internet Architecture (FIA) Program, CISE
Project Status
WINLAB
MobilityFirst objectives from the NSF FIA project abstract (Aug 2010): This project is aimed at the design and experimental validation of a
comprehensive clean-slate future Internet architecture. The major design goals of the architecture are: mobility as the norm
with dynamic host and network mobility at scale; robustness with respect to intrinsic properties of the wireless medium; trustworthinessin the form of enhanced security and privacy; usability features such as support for context-aware services, evolvability, manageability and economic viability.
The project’s scope includes architectural design, validation of key protocol components, testbed prototyping of the MobilityFirstarchitecture as a whole, and real-world protocol deployment on the GENI experimental infrastructure.
Status Summary: Project Goals
WINLAB
The MobilityFirst project is now past the one-year mark… Year 1 focus was on:
Broad exploration of architectural space Investigation of key concepts/techniques for inclusion Building team consensus on protocol design Initiating phased proof-of-concept prototyping effort
Year 2 focus will be on: Full v1.0 protocol specification with team agreement Algorithms and design details to support protocol spec Development of complete MF network prototype Small and medium scale evaluations on ORBIT, GENI, etc.
Year 3 goals include Large-scale and end-user evaluations v2.0 protocol spec based on feedback from experimental studies, etc. Hardware/software implementation & related optimizations Industry and standards outreach, etc.
Status Summary: Project Phases
WINLAB
The project is organized into several working groups Architecture WG Naming/Addressing/Routing Security & Privacy Context/Content Services Economics & Policy Evaluation & Analysis System-level prototyping
Each WG represents a cluster of activity each involving ~3-5 people. Project structure is based on cooperation among peers rather than hierarchy. The WINLAB prototyping team serves as the central point for specification & development.
Coordination done by weekly teleconferences and ad hoc WG calls; also ~3 team meetings (not including FIA) in year 1 for brainstorming and consensus building.
Status Summary: Project Organization
WINLAB
Status Summary: Project Map (by site)
D. Raychaudhuri, M. Gruteser, W. Trappe, R, Martin, Y. Zhang, I. Seskar, K. Nagaraja, S. Nelson, J. Li
S. Bannerjee
W. Lehr
B. Ramamurthy
G. Chen
X. Yang, R. RoyChowdhury
A. Venkataramani, J. Kurose, D. Towsley, D. Westbrook
M. Reiter
Z. Morley Mao
Optical NetworkInterface, Net Mgmt
Network ManagementSystem Prototyping
Interdomain RoutingArchitecture, Security
Computing LayerDOS ResistanceContext-Aware Apps
Security, Name Resolution & Routing
Architecture, Routing (Intra and Interdomain),Global Name Resolution Service, ContentServices, Context Services, Security, Privacy,Economic Models, Mobile Applications,System Prototyping & GENI Integration
Architecture, Name Resolution Service,Routing (Intra and Interdomain), Evaluation Models, Content Services,Security, System Prototyping
Android Mobile Clientand mobile apps
Economics & PolicyAnalysis
WINLAB
Status Summary: Project Map (by WG topic)
Architecture
Evaluation
Prototyping
Naming/Routing Security/Privacy Network Mgmt Pervasive Mobile Network Economics
MF Click Router
GNRS
Androidclient
InterdomainRouting
NetworkMgmt
GENIIntegration
ComputingLayer
Storage RoutingAnalysis
Content DeliveryModels
MultipathRouting Evaluation
GNRS ScalingEvaluation
SimulationModels
GSTAR/R3Routing
DTN
Net NeutralityStudy
Mobile/PervasiveRequirements Study
Name-AddressSeparation concepts
GUID RoutingEtc. Security
ModelContent- and
Context servicesAPI
GNRS Design BGNRS Design A
Storage RoutingDesign
Hybrid GUID/NARouting
GSTARProtocol
Inter-domainprotocol
Name assignmentservices
Public KeyGUID
Name CertificationServices
Secure GNRS
Secure InterdomainRouting
DOS resistance/Intentional receipt
Security analysis& attack scenarios
Client-assistedmeasurements
Independent NMSRouting scheme
Routing algorithms:Late binding, mcast, .. MF Measurement
Tools & Library
SpectrumCoordination
DOS DetectionTools etc.
Context ServiceModel
Content Delivery& Mobile Cache
Sensor/M2MUse Case
GeographicServices
Context-awareApplications
4G/LTE BB MobileStudy
Large-scaleNetwork models
Network SLA’s& incenstives
Policy Analysisfor MF architecture
Privacy design
Privacy Policy
* Note that the above is only a representative set of projects, not intended to be exhaustive
Cross-cuttingTasks
VerticalTasks
WINLAB
Year 1 progress highlights include Consensus on High-level MF architecture concepts (name-address
separation, public key names, GUID service layer, hybrid GUID/NA routing, storage-aware routing, hop-by-hop TP, content- and context services, etc.)
Design and evaluation of global name resolution service (GNRS) Design and evaluation of storage-aware intra-domain routing
(GSTAR) Concepts and baseline design for context-aware services Baseline security and privacy architecture design
(cont. on next slide)
Status Summary: Year 1 Progress
WINLAB
Year 1 progress highlights (cont.) Prototyping of several key components including GNRS, MF Router
with storage routing, context service, content delivery, Android mobile, etc.
GEC-12 demo of MF protocol stack running over multiple campus routers and wireless BS/APs under development for Nov 2011
Ongoing research on Network management requirements and design Computing layer for optional service plug-ins Analysis models for MF networks including GNRS, multipath, content, .. Inter-domain routing options and related algorithms for mcast, anycast, dual-
homing, etc. Security and privacy mechanism details and attack scenarios Network services for content, context, network trust, etc. Economic models and policy issues Optical network interface
Status Summary: Year 1 Progress
WINLAB
Global Name Resolution Service (GNRS) validation & selection
Consensus on 1-2 Interdomain routing approaches & implementation of corresponding protocols/algorithms
Baseline algorithms for advanced routing services – mobile, mcast, multi-homing, mpath, late binding, etc.
v1.0 MF protocol spec GEC-12 demo system integration and application design Details of baseline security protocols & implementation Service API with content- and context-aware use cases Design for intentional receipt/DoS resistance Initial prototyping of computing layer
Status Summary: Near-term Goals
WINLAB
Large-scale GNRS models with ~10B mobile end-points Conclusive validation of storage routing seamless across
various wired and wireless network scenarios Proving robustness (Byzantine fault tolerance) properties Details of the MF trust model, including support for mobile
nodes, networks, DTN, p2p, virtual nets, … Security against malicious network nodes Privacy preserving mechanisms Understanding context services & future mobile/pervasive
application requirements Technology realization – from IP routers to GUID/storage
routers with optional computing ….
Status Summary: Longer Term Research Goals
Protocol Design Highlights
WINLAB
MobilityFirst Protocol Stack: Overview Core elements of MF protocol stack
GUID services layer, supported by control protocols for bootstrap & updates GUID to network address mapping (GNRS) for dynamic mapping of GUID Generalized storage-aware routing (GSTAR) with supporting control protocols Reliable hop-by-hop block transfer between routers Management plane protocol with its own routing scheme Multiple TP options and plug-in programmable services at GUID layer
Link Layer A(e.g fiber)
Link Layer B(e.g LTE)
Link Layer C(e.g WiFi)
Link Layer D(e.g Ethernet
RoutingControl
Protocols
GUID-to-Net Address Mapping
E2ETransport Protocol B
E2ETransport Protocol B
MgmtApps
APP-2 APP-n
Hop-by-hop Block Transfer Protocol
ManagementPlane
Protocols(incl. routing) Storage-Aware Routing (GSTAR)
GUID Service Layer Computing LayerService Plug-ins
GUIDServicesControl
Protocols
Name CertificationService A
E2ETransport Protocol A
APP-1
……..
RoutingApps
WINLAB
MobilityFirst Protocol Stack: Name-Address Separation Separation of names (ID) from
network addresses (NA) Globally unique name (GUID)
for network attached objects User name, device ID, content, context,
AS name, and so on Multiple competing application specific
name certification services
Global Name Resolution Service for GUID NA mappings
Hybrid GUID/NA approach Both name/address headers in PDU “Fast path” when NA is available GUID resolution, late binding option
Globally Unique Flat Identifier (GUID)
John’s _laptop_1
Sue’s_mobile_2
Server_1234
Sensor@XYZ
Media File_ABC
Host NamingService
Network
SensorNamingService
ContentNamingService
Global Name Resolution Service
Network addressNet1.local_ID
Net2.local_ID
ContextNamingService
Taxis in NB
WINLAB
MobilityFirst Protocol Stack: Service Abstractions
MobilityFirst API proposes a new multipoint/multipath/time delivery abstraction that reflects the intrinsic broadcast & multi-homing nature of the wireless medium along with in-network storage
Replaces the communication link abstraction provided by IP …IP Abstraction: Virtual Link
DestDevice
NetworkInterface IP Addr=X
Name=MAC
Send(IP=X, data)
StaticMAC=Xbinding
DynamicGUID – NAbindings
MF Abstraction: Network Objectwith multipath reachability
NA=X1 NA=X2 NA=X3
GUID=YNetworkAttachedObject
Send(GUID=Y, data, options)..options for mpath & time delivery
MF Abstraction: Network Object Group with broadcast reachability
NA=X2
GUID1 GUID2 GUID3GroupGUID = Z
Send(GUID=Z, data, options)..option for mcast delivery
Broadcast Medium
WINLAB
MobilityFirst Protocol Stack: Packet Headers
Data
Service APIe.g. assign(GUID, handle) &Send (GUID, data), Get (GUID), etc.
GUID(src/dest)
SID
PDU(protocoldata unit)
TP/Seq #
GUID(src/dest)
SID
PDU(protocoldata unit)
TP/Seq #
NA list(optional)
Application
GUID ServiceLayer
PDU(protocoldata unit)
TP/Seq #
TransportLayer
Network RoutingLayer
LL Pkt
MAC/LLheader
Packet headers at various levels of MF protocol stack -GUID is the authoritative header in all packets SID provides service definition such as anycast, delayed delivery, … Optional NA list for fast path in routing layer
WINLAB
MF Protocol Stack: Packet Headers and Forwarding with Hybrid GIUD/NetAddr
Hybrid scheme in which packet headers contain both the object name (GUID) and topological address (NA) routing
NA header used for “fast” path, with fallback to GUID resolution where needed Enables flexibility for multicast, anycast and other late binding services
GUID/ServiceHeader
GID-Address Mapping
Routing Table
GUID NAxz1756.. Net 1194
GUID/ServiceHeader
NA Header
Dest NA PathNet 123 Net11, net2, ..
GUID –based forwarding(slow path)
Network Address Based Routing(fast path)
Name-GID Mapping
Name GUIDserver@winlab xy17519bbd
GID/ServiceHeader
NA Header
Data Object(100B-1GB)
PDU with GUIDHeader only
PDU with GUIDand NA headers
GUID/Public KeyHash
SID(ServiceIdentifier)
GUID Header Components
Optional list of NA’s- Destination NA- Source route - Intermediate NA- Partial source route
WINLAB
Architecture Concepts: Global Name Resolution Service for Dynamic Name <-> Address Binding Fast Global Name Resolution a central feature of architecture
GUID <-> network address (NA) mappings
Distributed service, possibly hosted directly on routers Fast updates ~50-100 ms to support dynamic mobility Service can scale to ~10B names via P2P/DHT techniques, Moore’s law
AP
Global Name-Address Resolution
Service
Data Plane
Host GUID
Network – NA2
Network – NA1
NA1
Registrationupdate
Mobile nodetrajectory
Initialregistration
Host Name, Context_ID or Content_ID Network Address
Host GUID
NA2
Decentralixed name servicesHosted by subset of ~100,000+ Gatway routers in network
WINLAB
10 100 1,00020 500
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
Round Trip Query Latency in milliseconds (log scale)
Cum
ulat
ive
Distribu
tion
Func
tion
(CDF)
K = 1K = 2K = 3K = 4K = 5
K = 5,95th Percentile
at 91 ms
K = 1, 95th Percentile
at 202 ms
Protocol Design: Direct Hash GNRS Fast GNRS implementation based on DHT between routers
GNRS entries (GUID <-> NA) stored at Router Addr = hash(GUID) Results in distributed in-network directory with fast access (~100 ms)
Internet Scale Simulation Results Using DIMES database
WINLAB
Routing protocol should seamlessly support a wide range of usage scenarios, from wired mobile ad hoc DTN Device, content and network mobility Heterogeneous devices and radio access Robustness to varying BW, disconnection Dynamic network formation & flexible boundaries
ConnectivityWired Wireless Mesh / Cellular Mobile Ad‐Hoc DTN
4GCore
Architecture Concepts: MobilityFirstRouting Design Goals
Expands routing options Store and/or replicate as
feasible routing options Enables “late binding” routing
algorithms Hop-by-hop transport
Large blocks reliably transferred at link layer
Entire block can be stored or cached at each router
Take advantage of cheap storage in the network (storage-aware routing)
~100MB, data in transit
~10GB, in‐network storage
~1TB, content caching
Generalized Storage-Aware Routing
• Actively monitor link qualities of network• Router store or forward decision based on:
1. Short and long term link qualities2. Available storage along path3. Connectivity to destination
Architecture Concepts: Exploiting In-Network Storage for Routing
WINLAB
Protocol Design: Storage-Aware Routing (GSTAR)
Storage aware (CNF, generalized DTN) routing exploits in-network storage to deal with varying link quality and disconnection
Routing algorithm adapts seamlessly adapts from switching (good path) to store-and-forward (poor link BW/short disconnection) to DTN (longer disconnections)
Storage has benefits for wired networks as well..
Storage Router
Low BW cellular link
MobileDevicetrajectory
High BW WiFi link
TemporaryStorage atRouter
Initial Routing Path
Re-routed pathFor delivery
Sample CNF routing result
PDU
WINLAB
Protocol Design: Segmented Transport
Segment-by-segment transport between routers with storage, in contrast to end-to-end TCP used today
Unit of transport (PDU) is a content file or max size fragment Hop TP provides improved throughput for time-varying
wireless links, and also helps deal with disconnections Also supports content caching, location services, etc.
Storage Router
Low BW cellular link
Segmented (Hop-by-Hop TP)
Optical Router
(no storage)
PDU
Hop #1 Hop #2
Hop #3
Hop #4TemporarilyStored PDU
BS
GID/Service Hdr
Mux Hdr
Net Address Hdr
Data Frag 1 Data
Frag 2Data Frag n
……
Hop-by-HopTransport
More details ofTP layer fragmentswith addl mux header
WINLAB
Architecture Concepts: MobilityFirstInterdomain Routing
Requirements include: flexible network boundaries, dynamic formation, virtual nets, network mobility, DTN mode, support for path selection, multipath, multi-homing, improved security, etc.
Motivates rethinking of today’s 2-tier IP/BGP architecture (inter-AS, intranet)
MobilityFirst interdomain approach uses GNRS service + enhanced path vector routing to achieve design goals – still evaluating multiple design options….
Core Net 17
Core Net 23
Access Net 200
Access Net 500
Mobile Net 1
Path Vector+Routing protocolProvides reachability& path info betweennetworks
GNRS providesNet name <-> addrmapping
Path Vector+Routing Plane
Global GNRSdirectory
Mobile Net 2
WINLAB
Protocol Design: MobilityFirst InterdomainRouting
One approach under consideration is to enhance BGP-like protocols with summary node/link info (“Vnode graph”) Summary knowledge of access net properties (Mbps, % avail, etc.), ingress/egress
points and alternate paths exchanged between networks/AS’s Network topology information for identifying multiple paths, storage points, etc.
Inspired by “Vnode” concept in “Pathlet” routing (Godfrey, 2008) Support for multicast, anycast, multihoming and multipath
Transit Network
Edge Network
V21V22
V23
V72
V73
V71V74
V11V12
V13
Aggregated Vnodeproperties & path info
Example of dual=homing routeSupported by routing protocol
WINLAB
Protocol Design: MobilityFirst Services
MobilityFirst API (or “socket” interface) provides a new set of services corresponding to the MF protocol stack’s capabilities
Key features are: GUID as the unique identifier right up to application level (no need for port #) Service identifier choice including: basic unicast/mcast, anycast, dual-homing, late
binding mobile delivery, delayed delivery, content query, context delivery, plug-in computing service, etc. (others TBD)
Lightweight transport protocol choices for end-to-end reliability and flow control
Socket interface examples: Open(URL, myGUID, TP=A, TP_options) - identity specification and stack
customization Send(GUID=X, SvcFlags/SID=anycast, data, len) Send(GUID=X, SvcFlags/SID=unicast, TP=B, data, len) Send(GUID=X, SvcFlags/SID=late binding, options, data) Get(GUID=X, SvcFlags/SID=anycast+content query, options, data_buffer, len) ….
WINLAB
Protocol Design: GUID socket interface
GUID-based addressing available at host, service/application, socket, and file level GUIDs can also address groups of entities
Port-less addressing of application end-points Each application end-point can have a separate GUID No port contention, and no assumed well-known ports for services
GUID aggregation and Service Directories Applications may choose to use host-GUID with a demux – appID Demux identifiers advertised at local directory services
APP-1 APP-2 APP-3 APP-4
GUID-4GUID-3GUID-2GUID-1
Host
GUID-0
APP-1 APP-2 APP-3 APP-4
appID-4appID-3appID-2appID-1
Host
GUID-0
Transport Layer Directory Service
Port-less, 1 GUID per endpoint GUID Aggregation and Service Directory
WINLAB
Protocol Design: Content Delivery in MobilityFirst
Content delivery handled efficiently by proposed MF architecture “Content objects” identified by unique GUID Multiple instances of content file identified by GNRS via GUID to NA mapping Routing protocol used for “reverse anycast” to nearest content object
Approach differs from NDN/CCN, where content attributes are carried in packet headers
MF uses content GUID naming service & GNRS to keep things general and avoid interpreting content semantics inside network
Content Store #2
Content cache at mobileOperator’s network – NA99
User mobilityContent Store #1(owner)
GUID=13247..99
GUID=13247..99GUID=13247..99
GUID=13247..99
GNRS queryReturns list:NA99,31,22,43
NA22
NA31NA99
NA29
NA43
Data fetch fromNA99
Data fetch fromNA43
GNRS Query
Get (content_GUID)
Get (content_GUID)
WINLAB
Protocol Design: Context Aware Delivery
Context-aware network services supported by MF architecture Dynamic mapping of structured context or content label by global name service Context attributes include location, time, person/group, network state Context naming service provides multicast GUID – mapped to NA by GNRS Similar to mechanism used to handle named content
MobileDevicetrajectory
Context = geo-coordinates & first_responder
Send (context, data)
Context-basedMulticast delivery
ContextGUID
Global Name Resolution service
ba123341x
ContextNamingService
NA1:P7, NA1:P9, NA2,P21, ..
WINLAB
Protocol Design: Management Plane Separate mgmt plane designed into MF architecture
Provides visibility into key mobile network aspects such as name resolution, disconnected operation, wireless access quality, context-aware services, location, privacy, …
Includes mechanism for network-assisted dynamic spectrum assignment (DSA) as a basic capability
Intended to improve transparency and support add-on mgmt apps
AP
Control & Management
PlaneNet Mgmt Interface
(performance queries,
configuration, faults, security, ..)
Data Plane
Data packets
WINLAB
Protocol Design: Management Plane (cont.) Support for dynamic spectrum assignment (DSA)
Given that the majority of end-user devices are wireless, Internet spectrum should be assigned on demand
Management plane mechanism for exchange of spectrum use data
AP
Mobility First Control & Management Plane
Distributed Spectrum Coordination Algorithm Software (runs on all radio devices)
Aggregate SpectrumUpdates Between Routers
Radio CoverageRegion A
Region B
Region C
Region D
Spectrum Use Update (from Radios)Spectrum Occupancy Map (from Routers)
Geo-cast Spectrum Update Service
WINLAB
Protocol Design: Computing Layer Programmable computing layer provides
service flexibility and evolution/growth path Routers include a virtual computing layer to support new network services Packets carry service tags and are directed to optional services where applicable Programming API for service creation provided as integral part of architecture Computing load can be reasonable with per-file (PDU) operations (vs. per packet)
...... ......
Packet forwarding/routing
Computing layer CPU Storage
Virtual ServiceProvider
ContentCaching
Privacyrouting
anony anony
WINLAB
Public key GUIDs for hosts & networks; forms basis for Ensuring accountability of traffic Ubiquitous access-control infrastructure Secure routing; no address hijacking
Emphasis on achieving robust performance under network stress or failure Byzantine fault tolerance as a goal Transform malicious attacks into benign failure Performance observability (in management plane)
Intentional receipt policies at networks and end-user nodes Every MF node can revert to GUID level to check authenticity, add filters, ..
No globally trusted root for naming or addressing Opens naming to innovation to combat naming-related abuses Removes obstacles to adoption of secure routing protocols
Security Considerations:
WINLAB
Security Considerations: Trust Model
NET NA1
NET NA7
NET NA33
NA 51 NA 99
NA 14
NA 88
NetworkNamingService
A
NetworkNaming Service
B
GNRS
Aggregate NA166:NA14, NA88, NA 33
HostNamingService
X
ContentNamingService
Y
ContextNamingService
Y
OtherNamingServices
TBD
Secure InterNetworkRouting Protocol
SecureHostName
ServiceLookup
SecureGNRSUpdate
SecureNetwork
NameServiceLookup
SecureData PathProtocol
Name assignment& certification services (..canincorporatevarious kinds oftrust including CA, group membership,reputation, etc
GUID = public Key
GUID <-> NAbinding
Public Key object and network names enable us to build secure protocols for each interface shown
WINLAB
Privacy Considerations:
Public key GUIDs provide a basic level of privacy Semantics of GUID in packet header not known to an observer But, GUID’s locator/NA can be tracked through repeated queries to GNRS Solutions such as disposable GUIDs or white-listing in GNRS
Enhanced privacy services possible through plug-ins at computing layer e.g. optional onion routing for designated SID
Architecture supports a range of privacy policy options – to be discussed further
WINLAB
Use Cases: GUID/Address Routing Scenarios – Multicast/Anycast/Geocast Multicast scenario below also uses GUID <-> Network Address resolution (late-
binding) at a router closer to destination (..GUID tunnel)
GUID/SID
DATA
GUID= mcastgroup
NetAddr= NA1
DATA
Send data file to “WINLAB students”
Late GUID <-> addrBinding at NA1
Net 1
Net 7
Intermediate network address NA1provided by GNRS
NetAddr=NA1:PA1,PA2,PA9; NA7,PA22GUID
DATA NetAddr=NA1,PA1
NetAddr=NA1,PA2
NetAddr=NA7,PA22
Port 1
Port 2
Port 22
WINLAB
Use Cases: GUID/Address Routing Scenarios – Dual Homing
The combination of GUID and network address helps to support new mobility related services including multi-homing, anycast, DTN, context, location …
Dual-homing scenario below allows for multiple NA:PA’s per name
Data Plane
GUID & SID
DATA
Send data file to “Alice’s laptop”
Net 1
Net 7
Current network addresses provided by GNRS;NA1:PA22 ; NA7:PA13
GUID/SIDNA1:PA22; NA7:PA13
DATA
GUIDNA1:PA22; NA7:PA13
DATA
Router bifurcates PDU to NA1 & NA7(no GUID resolution needed)
Dual-homed mobile device
GUIDNetAddr= NA7.PA13
DATA
GUID NetAddr= NA1.PA22
DATA
Alice’s laptopGUID = xxx
WINLAB
Use Cases: GUID/Address Routing Scenarios – Handling Disconnection
Intermittent disconnection scenario below uses GUID based redirection (late binding) by router to new point of attachment
Data Plane
GUID/SID
DATA
GUIDNetAddr= NA1.PA7
DATA
Send data file to “Alice’s laptop”
MobilityTrajectory
DisconnectedRegion
Net 1
Net 7
Current network address provided by GNRS;NA1 – network part; PA9 – port address
GUIDNetAddr= NA1.PA9- Delivery failure
DATA
GUID
DATA
PDU Stored in router- GUID resolution for redirection
GUIDNetAddr= NA7.PA3Successful redelivery after connection
DATA
Prototyping & Evaluation
WINLAB
MobilityFirst Prototyping: Phased Approach
Global Name Resolution Service (GNRS)
Storage Aware Routing
Context‐Aware / Late‐bind Routing
Context Addressing Stack
Content Addressing Stack
Host/Device Addressing
Stack
Encoding/Certifying Layer
Locator‐X Routing (e.g., GUID‐based)
Evaluation Platform
Prototyping Status
Simulation/Emulation Emulation/Limited Testbed
StandaloneComponents System Integration
Testbed/‘Live’ Deployment
Deployment ready
WINLAB
MobilityFirst Prototyping: Software Router Linux‐based software router with two‐level implementation
OpenFlow Controller
QuaggaOpenFlow switch host
XORP
User‐Level Control Plane
ClickLinux routing
Commodity Hardware
Forwarding Engine
NetFPGA
42
MF Name Resolution
MF Routing & Mgmt.
Portable user-level implementationMF App Services
WINLAB
OpenFLow BackbonesOpenFlowWiMAXShadowNet
Internet 2National Lambda Rail
Legend
MobilityFirst Prototyping: GENI Deployment Plan (Phase 3)
Domain‐1
Router
Router
Domain‐2
Wireless Egde(4G & WiFI)
Wireless Edge (4G & WiFI) Router
Wireless Edge (4G & WiFI)
Domain‐3
Router
Router
Router
Mapping onto GENI Infrastructure ProtoGENI nodes, OpenFlow switches, GENI Racks, WiMAX/outdoor ORBIT nodes, DieselNet bus, etc.
Inter-domain mobility
Intra-domain mobility
43
Deployment Target:• Large scale, multi‐site • Mobility centric• Realistic, live
Full MF Stackat routers, BS, etc.
Opt-in users
Services
WINLAB
Resources
Project website: http://mobilityfirst.rutgers.edu
GENI website: www.geni.net
ORBIT website: www.orbit-lab.org
