Mobility First

8/3/2019 Mobility First

1/44

MobilityFirst FIA Project:Status Summary & Technical

Overview

NSF Visit, Oct 6, 2011

Contact: D. Raychaudhuri

WINLAB, Rutgers UniversityTechnology Centre of NJ

671 Route 1, North Brunswick,

NJ 08902, USA

[email protected]


2/44

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 Nat ional Scienc e Foundat ion (NSF)Under the Future Int ernet Arc hi tec ture (FIA) Program, CISE


3/44

Project Status


4/44

WINLAB

MobilityFirst objectives from the NSF FIAproject 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 normwith dynamic host and network mobility at scale; robustnesswith

respect to intrinsic properties of the wireless medium; trustworthinessin the form of enhanced security and privacy; usabilityfeatures suchas support for context-aware services, evolvability, manageabilityand economic viability.

The projects scope includes architectural design, validation of keyprotocol components, testbed prototyping of the MobilityFirstarchitecture as a whole, and real-world protocol deployment on theGENI experimental infrastructure.

Status Summary: Project Goals


5/44

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


6/44

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 thanhierarchy. The WINLAB prototyping team serves as the central point forspecification & development.

Coordination done by weekly teleconferences and ad hoc WG calls; also~3 team meetings (not including FIA) in year 1 for brainstorming andconsensus building.

Status Summary: Project Organization


7/44

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 Management

System Prototyping

Interdomain RoutingArchitecture, Security

Computing Layer

DOS Resistance

Context-Aware Apps

Security, Name

Resolution & Routing

Architecture, Routing (Intra and Interdomain),Global Name Resolution Service, Content

Services, 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 & Policy

Analysis


8/44


9/44

WINLAB

Year 1 progress highlights include Consensus on High-level MF architecture concepts (name-address

separation, public key names, GUID service layer, hybrid GUID/NArouting, storage-aware routing, hop-by-hop TP, content- and contextservices, 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


10/44

WINLAB

Year 1 progress highlights (cont.) Prototyping of several key components including GNRS, MF Router

with storage routing, context service, content delivery, Androidmobile, etc.

GEC-12 demo of MF protocol stack running over multiple campusrouters 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


11/44

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


12/44

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 mobilenodes, 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/storagerouters with optional computing

.

Status Summary: Longer Term Research

Goals


13/44

Protocol DesignHighlights


14/44

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

E2ETransportProtocol B

E2ETransportProtocol B

MgmtApps

APP-2 APP-n

Hop-by-hop Block Transfer Protocol

ManagementPlane

Protocols(incl. routing)

Storage-Aware Routing (GSTAR)

GUID Service Layer Computing Layer

Service Plug-ins

GUIDServicesControl

Protocols

Name CertificationService A

E2ETransportProtocol A

APP-1

..

RoutingApps


15/44

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 specificname certification services

Global Name Resolution Servicefor 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)

Johns _laptop_1

Sues_mobile_2

Server_1234

Sensor@XYZ

Media File_ABC

HostNamingService

Network

SensorNamingService

ContentNamingService

Global Name Resolution Service

Network addressNet1.local_ID

Net2.local_ID

ContextNamingService

Taxis in NB


16/44

WINLAB

MobilityFirst Protocol Stack: Service Abstractions

MobilityFirst API proposes a new multipoint/multipath/time deliveryabstraction that reflects the intrinsic broadcast & multi-homingnature 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=YNetworkAttached

Object

Send(GUID=Y, data, options)

..options for mpath & time delivery

MF Abstraction: Network Object Group withbroadcast reachability

NA=X2

GUID1 GUID2GUID3Group

GUID = Z

Send(GUID=Z, data, options)

..option for mcast delivery

Broadcast Medium


17/44

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


TP/Seq #

NA list(optional)

Application

GUID ServiceLayer


TP/Seq #

TransportLayer

Network RoutingLayer

LL Pkt

MAC/LL

header

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


18/44

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/Service

Header

GID-Address Mapping

Routing Table

GUID NA

xz1756.. Net 1194

GUID/Service

Header

NA Header

Dest NA Path

Net 123 Net11, net2, ..

GUID based forwarding

(slow path)

Network Address Based Routing(fast path)

Name-GID Mapping

Name GUID

server@winlab xy17519bbdGID/ServiceHeader

NA Header

Data Object(100B-1GB)

PDU with GUID

Header only

PDU with GUIDand NA headers

GUID/Public KeyHash

SID

(Service

Identifier)

GUID Header Components

Optional list of NAs- Destination NA

- Source route- Intermediate NA

- Partial source route


19/44

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, Moores 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


20/44

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)

CumulativeDistributionFunction(CDF)

K = 1

K = 2

K = 3

K = 4

K = 5

K = 5,

95th Percentileat 91 ms

K = 1,

95th Percentileat 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 ResultsUsing DIMES database


21/44

WINLAB

Routing protocol should seamlessly support a wide range ofusage 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

Connectivity

Wired Wireless

Mesh

/

Cellular Mobile

Ad

Hoc DTN

4GCore

Architecture Concepts: MobilityFirst

Routing Design Goals


22/44

Expands routing options

Storeand/or replicateasfeasible routing options

Enables late binding routing

algorithms

Hop-by-hop transport

Large blocksreliablytransferred at link layer

Entire block can be stored orcached at each router

Take advantage of cheap

storage in the network(storage-aware routing)

~100MB,dataintransit

~10GB,

in

network

storage~1TB,contentcaching

Generalized Storage-Aware Routing

Actively monitor link qualities of network Router store or forward decision based on:

1. Short and long term link qualities

2. Available storage along path3. Connectivity to destination

Architecture Concepts: Exploiting In-

Network Storage for Routing


23/44

WINLAB

Protocol Design: Storage-Aware Routing(GSTAR)

Storage aware (CNF, generalized DTN) routing exploits in-networkstorage 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) toDTN (longer disconnections)

Storage has benefits for wired networks as well..

Storage

Router

Low BWcellular link

MobileDevicetrajectory

High BWWiFi link

TemporaryStorage at

Router

Initial Routing Path

Re-routed pathFor delivery

Sample CNF routing result

PDU


24/44

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-varyingwireless links, and also helps deal with disconnections

Also supports content caching, location services, etc.

Storage

Router

Low BWcellular link

Segmented (Hop-by-Hop TP)

Optical

Router(no storage)

PDU

Hop #1 Hop #2

Hop #3

Hop #4

TemporarilyStored PDU

BS

GID/Service Hdr

Mux Hdr

Net Address Hdr

DataFrag 1

DataFrag 2

DataFrag n

Hop-by-HopTransport

More details ofTP layer fragments

with addl mux header


25/44

WINLAB

Architecture Concepts: MobilityFirstInterdomain Routing

Requirements include: flexible network boundaries, dynamicformation, virtual nets, network mobility, DTN mode, support forpath selection, multipath, multi-homing, improved security, etc.

Motivates rethinking of todays 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 protocol

Provides reachability& path info betweennetworks

GNRS providesNet name addr

mapping

Path Vector+Routing Plane

Global GNRS

directory

Mobile

Net 2


26/44

WINLAB

Protocol Design: MobilityFirst InterdomainRouting

One approach under consideration is to enhance BGP-likeprotocols 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/ASs 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

V23V72

V73

V71 V74

V11V12

V13

Aggregated Vnodeproperties & path info

Example of dual=homing routeSupported by routing protocol


27/44

WINLAB

Protocol Design: MobilityFirst Services

MobilityFirst API (or socket interface) provides a new set ofservices corresponding to the MF protocol stacks 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-incomputing 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)

.


28/44

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


29/44


30/44

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 NameResolution service

ba123

341x

Context

NamingService

NA1:P7, NA1:P9, NA2,P21, ..


31/44

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

(performancequeries,

configuration, faults,

security, ..)

Data Plane

Data packets


32/44

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 CoordinationAlgorithm 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 SpectrumUpdate Service


33/44

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)

...... ......

Packetforwarding/routing

Computinglayer CPU Storage

Virtual

Service

Provider

Content

Caching

Privacy

routing

anony anony


34/44

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 networkstress 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:


35/44

WINLAB

Security Considerations: Trust Model

NET NA1

NET NA7

NET NA33

NA 51 NA 99

NA 14

NA 88

NetworkNamingService

A

NetworkNamingService

B

GNRS

Aggregate NA166:NA14, NA88, NA 33

HostNamingService

X

ContentNamingService

Y

ContextNamingService

Y

OtherNamingServices

TBD

Secure InterNetworkRouting Protocol

Secure

HostNameServiceLookup

Secure

GNRSUpdate

SecureNetwork

Name

ServiceLookup

SecureData Path

Protocol

Name assignment& certificationservices(..canincorporatevarious kinds oftrust including

CA, groupmembership,reputation, etc

GUID = public Key

GUID NAbinding

Public Key object and network names enable us to build secure protocols for each interface shown


36/44

WINLAB

Privacy Considerations:

Public key GUIDs provide a basic level of privacy Semantics of GUID in packet header not known to an observer

But, GUIDs 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 atcomputing layer e.g. optional onion routing for designated SID

Architecture supports a range of privacy policy options tobe discussed further


37/44

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,PA22

GUID

DATA NetAddr=NA1,PA1

NetAddr=NA1,PA2

NetAddr=NA7,PA22

Port 1

Port 2

Port 22


38/44

WINLAB


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:PAs per name

Data Plane

GUID & SID

DATA

Send data file to Alices 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-homedmobile device

GUIDNetAddr= NA7.PA13

DATA


DATA

Alices laptopGUID = xxx


39/44

WINLAB


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


DATA

Send data file to Alices 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

DAT

A

PDU Stored in router- GUID resolution for redirection

GUIDNetAddr= NA7.PA3Successful redelivery after connection

DATA


40/44

Prototyping & Evaluation


41/44

WINLAB

MobilityFirst Prototyping: Phased Approach

GlobalNameResolutionService(GNRS)

StorageAware

Routing

ContextAware/

LatebindRouting

Context

Addressi

ngStack

Content

Addressi

ngStack

Host/Device

Addressing

Stack

Encoding/CertifyingLayer

LocatorXRouting

(e.g.,GUIDbased)

EvaluationPlatform

PrototypingStatus

Simulation/Emulation Emulation/LimitedTestbed

StandaloneComponents

SystemIntegration

Testbed/LiveDeployment

Deploymentready

M bilit Fi t P t t i g S ft


42/44

WINLAB

MobilityFirst Prototyping: Software

Router Linuxbasedsoftwarerouterwithtwolevelimplementation

OpenFlowController

QuaggaOpenFlow

switchhost

XORP

UserLevelControl

Plane

ClickLinuxrouting

CommodityHardware

ForwardingEngine

NetFPGA

42

MFNameResolution

MFRouting&Mgmt.

Portable user-level implementationMFAppServices

MobilityFirst Prototyping: GENI Deployment


43/44

WINLAB

OpenFLow Backbones

OpenFlow

WiMAX

ShadowNet

Internet 2National Lambda Rail

Legend

MobilityFirst Prototyping: GENI Deployment

Plan (Phase 3)Domain1

Router

Router

Domain2

Wireless Egde(4G & WiFI)

Wireless Edge(4G & WiFI) Router

Wireless Edge

(4G & WiFI)

Domain3

Router

Router

Router

MappingontoGENI

Infrastructure

ProtoGENI nodes,

OpenFlowswitches,

GENIRacks,

WiMAX/outdoorORBIT

nodes,DieselNet bus,

etc.

Inter-domain mobility

Intra-domain mobility

43

DeploymentTarget:

Largescale,multisite Mobilitycentric Realistic,live

Full MF Stackat routers, BS, etc.

Opt-in users

Services


44/44

Documents

Mobility First