1 / 36

MobilityFirst Project Update FIA PI Meeting, March 18-19, 2013 Part-II – Protocol Details, Use Cases & Prototyping

MobilityFirst Project Update FIA PI Meeting, March 18-19, 2013 Part-II – Protocol Details, Use Cases & Prototyping. D. Raychaudhuri & Arun Venkataramani WINLAB, Rutgers University CS Dept , Umass - Amherst ray@winlab.rutgers.edu arun@cs.umass.edu. MobilityFirst Protocol.

nami
Télécharger la présentation

MobilityFirst Project Update FIA PI Meeting, March 18-19, 2013 Part-II – Protocol Details, Use Cases & Prototyping

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. MobilityFirst Project UpdateFIA PI Meeting, March 18-19, 2013Part-II – Protocol Details, Use Cases & Prototyping D. Raychaudhuri & ArunVenkataramani WINLAB, Rutgers University CS Dept, Umass - Amherst ray@winlab.rutgers.eduarun@cs.umass.edu

  2. MobilityFirstProtocol

  3. MobilityFirst Protocol: Feature Summary Named devices, content, and context Strong authentication, privacy 11001101011100100…0011 Public Key Based Global Identifier (GUID) Human-readable name Service API with unicast, multi-homing, mcast, anycast, content query, etc. Routers with Integrated Storage & Computing Heterogeneous Wireless Access End-Point mobility with multi-homing In-network content cache Storage-aware Intra-domain routing Hop-by-hop file transport Edge-aware Inter-domain routing • MobilityFirst Protocol Design Goals: • 10B+ mobile/wireless devices • Mobility as a basic service • BW variation & disconnection tolerance • Ad-hoc edge networks & network mobility • Multihoming, multipath, multicast • Content & context-aware services • Strong security/trust and privacy model Connectionless Packet Switched Network with hybrid name/address routing Network Mobility & Disconnected Mode Ad-hoc p2p mode

  4. MobilityFirst Protocol: Technology Solution Name Certification Service (NCS) Flexible name-based network service layer Name-Based Services (mobility, mcast, content, context, M2M) Optional Compute Layer Plug-Ins (cache, privacy, etc.) Global Name Resolution Service (GNRS) Meta-level Network Services Hop-by-Hop Transport (w/bypass option) Hybrid GUID/NA Global Routing (Edge-aware, mobile, Late binding, etc.) Storage-Aware & DTN Routing (GSTAR) in Edge Networks Core Transport Services Pure connectionless packet switching with in-network storage

  5. MobilityFirst Protocol: The Protocol Stack App 1 App 2 App 3 App 4 Socket API Name Certification & Assignment Service NCS E2E TP1 E2E TP2 E2E TP3 E2E TP4 Optional Compute Layer Plug-In A Global Name Resolution Service GNRS GUID Service Layer Narrow Waist MF Routing Control Protocol GSTAR Routing MF Inter-Domain IP Switching Option Hop-by-Hop Block Transfer Link Layer 1 (802.11) Link Layer 2 (LTE) Link Layer 3 (Ethernet) Link Layer 4 (SONET) Link Layer 5 (etc.) Control Plane Data Plane

  6. MF Protocol: Name-Address Separation  GUIDs Sue’s_mobile_2 Server_1234 Media File_ABC Taxis in NB Sensor@XYZ John’s _laptop_1 Host Naming Service Sensor Naming Service Context Naming Service Content Naming Service Globally Unique Flat Identifier (GUID) Global Name Resolution Service Network • 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 domain-specific naming 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 Net2.local_ID Network address Net1.local_ID

  7. MF Protocol: Hybrid GUID/NA Storage Router in MobilityFirst • Hybrid name-address based routing in MobilityFirst requires a new router design with in-network storage and two lookup tables: • “Virtual DHT” table for GUID-to-NA lookup as needed • Conventional NA-to-port # forwarding table for “fast path” • Also, enhanced routing algorithm for store/forward decisions GUID –based forwarding (slow path) GUID-Address Mapping – virtual DHT table DATA GUID NA Look up GUID-NA table when: - no NAs in pkt header - encapsulated GUID - delivery failure or expired NA entry 11001..11 NA99,32 To NA11 • Store when: • Poor short-term path quality • Delivery failure, no NA entry • GNRS query failure • etc. Router Storage DATA To NA51 SID GUID= 11001…11 NA Forwarding Table – stored physically at router NA99,NA32 Dest NA Port #, Next Hop NA99 Port 5, NA11 NA62 Port 5, NA11 Look up NA-next hop table when: - pkt header includes NAs - valid NA to next hop entry DATA Port 7, NA51 NA32 Network Address Based Forwarding (fast path)

  8. MF Protocol: Service Abstractions (1) • MobilityFirst offers a named-object service API that supports mobility, disconnection, multi-homing, multicast in a natural way • Replaces the point-to-point virtual link abstraction of IP … • Example: Sending to a mobile device with multiple interfaces MF Abstraction: Multi-homed Network Object IP Abstraction: Virtual Link Send(IP=X, data) Send(GUID=Y, data, options) ..options for multi-homing & late binding NA=X1 NA=X2 NA=X3 Network Interface IP Addr=X Dynamic GUID – NA bindings GUID=Y Static MAC=X binding Network Attached Object Name= MAC Dest Device e.g., Y may be a mobile device with 3 interfaces (WiFi & 2 cellular)

  9. MF Protocol: Service Abstractions (2) • Use of MF Service API for content retrieval and dynamic group multicast (..membership may be specified by context) MF Abstraction: Get Replicated Content Object MF Abstraction: Send to Group Object with Multicast reachability Get (Content_GUID=A, options) ..option for shortest path Send (GUID=Z, data, options) ..option for mcast delivery NA=X2 NA=X1 NA=X2 NA=X3 Broadcast Medium Group GUID = Z GUID3 GUID2 GUID1 Content Object With GUID=A GUID=A GUID=A e.g., Z may be a context group of M2M devices or a cloud service e.g., A is a replicated content object at multiple network locations

  10. MobilityFirst Protocol Stack: GUID addressing • 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 Port-less, 1 GUID per endpoint GUID Aggregation and Service Directory APP-3 APP-4 APP-2 APP-2 APP-1 APP-3 APP-4 APP-1 appID-2 appID-3 appID-4 appID-1 Host Transport Layer Directory Service Host GUID-4 GUID-0 GUID-1 GUID-2 GUID-3 GUID-0

  11. MobilityFirst Protocol Stack: Service API • 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) • Unicast vs multicast determined • 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) • Send(GUID=X, SvcFlags/SID=anycast+, data) • Recv(data_buffer, len, GUID_allow={X, Y, X}) • Get(GUID=X, SvcFlags/SID=anycast+content query, options, data_buffer, len) • ….

  12. MobilityFirst Protocol Stack: Network Service API • open (profile-URL, src-GUID, [profile-options]) • A profile declares the customization of the stack such as choice of transport and security features for the duration of a session. Profile option parameterize a profile • Optional source GUID identifies the initiating end-point and results in an update of attachment point to the GNRS. • send (message, dst-GUID, [service-option]) • GUID based endpoint addressing • Options include: MULTICAST, ANYCAST, GET (content), CACHE (a directive to allow content caching), MULTI-PATH, MULTI-HOME, DTN (delay-tolerant), REALTIME (with delay constraints), COMPUTE (with GUID of compute service) … • recv(buffer, [GUID-set]) • Intentional data receipt - GUID-set defined white list • Synchronous and asynchronous implementations • get (content-GUID, buffer, [service-options]) • Content-centric apps: native network support for direct (GUID-based) content discovery and retrieval of content • ANYCAST service: retrieval attempted from the closest among replicas listed in GNRS

  13. MobilityFirst Protocol Stack: Network Service API (Contd.) • attach (GUID-set) • Publishes network reachability for the specified GUID(s) • GUID services layer initiates an association request for each GUID • Network cooperation (co-sign) to publish attachment point locator to GNRS • Periodic association exchanged keeps locator bindings ‘fresh’ at GNRS • close () • Terminates a session by clearing stack stateand performing a clean disassociation from network • Locator bindings from GNRS can be removed or allowed to expire

  14. Wireless/Mobile Use Case

  15. Wireless/Mobile Use Case Current Mobile Networks • Planned Deployment • Licensed Spectrum • Fine-grained Managed QoS • Centralized Mobility Support • Homogeneous Topology • Network-wide Authentication MF Network-of-Networks • Ad-hoc Deployment • Unlicensed Spectrum • Coarse-grained Managed • In-network Mobility Support • Heterogeneous topology • Authentication at APs MobilityFirst enables a stitched-together architecture for mobile networks

  16. Wireless/Mobile Use Case: Service Capability Examples BS1 • MF provides several useful capabilities for mobile networks, e.g. mobility, multi-homing, multi-network access, late binding, multicast, .. Wireless Access Net #3 INTERNET Wireless Access Network #2 BS2 User/Device Mobility (1) Mobile Device with Seamless Service BS-1 Wireless Access Net #1 LTE BS BS-2 Wireless Access Network Wireless Access Net #3 Wireless Access Net #3 INTERNET INTERNET BS-3 Multiple Potential Paths Wireless Edge Network Wireless Access Network #2 WiFi AP AP1 Mobile device With dual-radio NICs (2) Mobile device with dual-homing (3) Mobile device with Multi-network access

  17. Protocol Example: Mobility Service via Name Resolution at Device End-Points Service API capabilities: - send (GUID, options, data) Options = anycast, mcast, time, .. - get (content_GUID, options) Options = nearest, all, .. Register “John Smith22’s devices” with NCS Name Certification Services (NCS) GUID assigned GUID lookup from directory GNRS update (after link-layer association) NA99 MobilityFirst Network (Data Plane) Send (GUID = 11011..011, SID=01, data) NA32 GNRS GUID <-> NA lookup GUID = 11011..011 Represents network object with 2 devices GNRS query Send (GUID = 11011..011, SID=01, NA99, NA32, data) DATA SID GUID NAs Packet sent out by host

  18. Protocol Example: Dual Homing Service via Named-Object / GNRS Multihoming service example DATA DATA Router bifurcates PDU to NA99 & NA32 (no GUID resolution needed) GUID NetAddr= NA99 NA99 Data Plane NA32 DATA DATA GUID NetAddr= NA32 SID GUID= 11001…11 NA99,NA32 DATA SID GUID Send data file to “John Smith22’s laptop”, SID= 129 (multihoming– all interfaces)

  19. Protocol Example: Handling Disconnection via Late Binding Store-and-forward mobility service example DATA GUID NA99  rebind to NA75 Delivery failure at NA99 due to device mobility Router stores & periodically checks GNRS binding Deliver to new network NA75 when GNRS updates NA99 Disconnection interval Device mobility Data Plane NA75 DATA GUID DATA NA75 SID GUID NA99 DATA SID GUID Send data file to “John Smith22’s laptop”, SID= 11 (unicast, mobile delivery)

  20. Sample Results: MF vs TCP/IP for WiFi Roaming • NS3 Simulation with full 802.11 stack, different vehicular speeds & offered load • Comparing TCP/IP with MF • Transmission of stored packets  Throughput Jumps Quantifying the benefits of in-network mobility management & storage aware routing

  21. Sample Results: MF vs. TCP/IP for LTE/WiFi Switching • TCP takes more time to re-start session (DHCP + Application reset) • Throughput boost due to transmission of stored packets • MF provides several benefits in a heterogeneous wireless environment: • Mobility Mgmt. is not specific to each network • Automatic storage of packets in transition • Simultaneous use of multiple networks

  22. Content & Context/M2M Use Cases

  23. Content Delivery Use Case: Content Retrieval via GUID Name • Network support for content addressability and caching  service primitives such as get(content-ID, ..) • Optional computing layer plug-in for enhanced services GUID=12379…78 Content Cache In-network cache NA94 In-network cache GUID=12379…78 NA22 Alternative paths for retrieval or delivery Content Cache GUID=12379…78 Content Owner’s Server Send(“content_GUID”, dest_GUID) Get (“content_GUID”) GNRS query with CGUID returns NA94, NA22

  24. Content Delivery Use Case: Enhanced CDN Service Enhanced service example – content delivery with in-network caching & transcoding Content cache at mobile Operator’s network – NA99 MF Compute Layer with Content Cache Service plug-in NA43 GUID=13247..99 NA31 Filter on SID=128 GUID=13247..99 GUID=13247..99 NA99 GNRS query Returns list: NA99,31,22,43 GNRS Query NA29 Data fetch from NA99 GUID=13247..99 Content file NA22 Mobile’s GUID Data fetch from NA43 Get (content_GUID, SID=128 - cache service) Content Owner’s Server Get (content_GUID) Query User mobility SID=128 (enhanced service) GUID=13247..99

  25. M2M Use Case: Supporting Context-Aware Services Context = geo-coordinates & taxi group Send (context, data) Context Naming Service Global Name Resolution service NA1:P7, NA1:P9, NA2,P21, .. Context GUID ba123 341x Context-based Multicast delivery Mobile Device trajectory • Context-aware delivery often associated with M2M services • Examples of context are group membership, location, network state, … • Requires framework for defining and addressing context (e.g. “taxis in New Brunswick”) • Anycast and multicast services for message delivery to dynamic group

  26. M2M Use Case: Protocol Example • M2M: S1 data is picked up by Mobile GW and sent to MF for A1 that subscribes it • Context: T1, conf@WINLAB, is subscribed by P1 …P4;A2 sends a file to T1 reaches P1..P4 via MF • M2M/Context server updates MF-GNRS for mappings: S1 A1 and T1  P1…P4 M2M / Context (Naming) Server, GUID Assign & Publish (S1, S2, C1, T1) Lookup S1, C1, subscribe S1 Context T1 Conf @WINLAB Application A2 Lookup S2, T1 & Subscribe T1 Lookup Context T1 Subscriber P1 P2 Lookup S1 P3 NA2 P4 Presentation DATA NA3 DATA Sensor S2 (location) Application A1 Internet (MobilityFirst) UPDATE NA4 UPDATE M2M GateWay GNRS: Global Name Resolution Service Sensor S1 (temperature) SmartGrid App NA1 GNRS Entries: S2T1, T1P1..P4 P1 -> NA2, P2->NA2 P3 -> NA2, P4->NA3 S1 -> A1 C1 -> NA1 Actuator C1 (air conditioning) A1 -> NA4 MobilityFirst Review Meeting

  27. Mobility First Prototyping & Deployment Status

  28. MF Software Router and Host Protocol Stack • Click-based MF Router • Storage-aware routing (GSTAR) • Name resolution server (GNRS) • Reliable hop-by-hop link transport (Hop) Android/Linux MF Protocol Stack - Network API - Hop - Dual homing (WiFi/WiMAX) Native, user-level implementation on Android runtime WiFi AP WiMAX BTS MF Router MF Router MF Router

  29. MF Android Mobile Client App 2 App ... App 1 MF JAVA Client API • JAVA (Android) and C (Linux) API prototype • Usable with ARM based Android devices • Multihoming capabilities for WiMAX enabled devices • Distributed as a system library and jar library for easiness of deployment in Android SDK based applications E2E Transport Protocol A E2E Transport Protocol B GUID Service Layer Storage-Aware Routing (GSTAR) Hop-by-Hop Block Transport Protocol Link Layer A (e.g. WIFI) Link Layer B (e.g. WIMAX)

  30. MF GNRS Implementation 2. ORBIT lab with net. emulation 3. Commercial cloud platform 1. GENI Wide Area Deployment Network Emulation • Two alternate designs: • network-level one-hop map service; co-located with routing (Dmap) • Locality-aware, cloud-hosted service (Auspice) • Three alternate evaluation platforms:

  31. MF Click Software Router • Lightweight, scalable multicast • GNRS for maintenance of multicast memberships • Heuristic approaches to reduce network load, limit duplicated buffering, and improve aggregate delivery delays • Click prototype, with SID for multicast flows • Evaluating hail a cab application as a example multipoint delivery scenario Multicast Inter-Domain (EIR)

  32. OpenFlow/SDN Implementation of MF • Protocol stack embedded within controller • Label switching, NA or GUID-based routing (incl. GNRS lookup) • Controllers interact with other controllers and network support services such as GNRS • Flow rule is set up for the remaining packets in the chunk based on Hop ID (which is inserted as a VLAN tag in all packets)E.g., SRC MAC = 04:5e:3f:76:84:4a, VLAN = 101 => OUT PORT = 16 MF Protocol Stack

  33. Physical Topology MF Routers at 7 campuses across US on ProtoGENI hosts Layer2 links: Internet2 & NLRbackbones, OpenFlow switches Edge networks: WiFi and WiMAX access at BBN & Rutgers MF Prototype Deployment on GENI(GEC-12 Recap) • Robust Content Delivery • Dual-homed mobile subscriber with WiFi + WiMAX • Adapt to disconnection and variable link quality (GSTAR) • Dual-homed delivery

  34. MF Multi-Site Deployment (GEC-16) NLR Cambridge, MA Madison, WI Ann Arbor, MI Lincoln, NE Palo Alto, CA N. Brunswick, NJ Salt Lake, UT Tokyo, Japan I2 Los Angeles, CA Clemson, SC Atlanta, GA Long-term (non-GENI) MobilityFirst Routing and Name Resolution Service Sites Short-term Wide Area ProtoGENI MobilityFirst Access Net ProtoGENI

  35. MF/GENI Connectivity: VLAN Stitching Cambridge, MA Madison, WI Ann Arbor, MI VLAN Y Lincoln, NE Salt Lake, UT VLAN 912 VLAN 192 Palo Alto, CA New Brunswick, NJ VLAN 1750 VLAN 3134/3135 Tokyo, Japan Los Angeles, CA Clemson, SC Atlanta, GA Long-term (non-GENI) Wide Area ProtoGENI nodes connect on VLAN 3716 at:Internet2 PoP ORNLR PoP MobilityFirst Routing and Name Resolution Service Sites Short-term Wide Area ProtoGENI MobilityFirst Access Net ProtoGENI

  36. MF/GENI Setup: Emulated Topology Cambridge, MA Madison, WI Ann Arbor, MI Lincoln, NE Salt Lake, UT Palo Alto, CA New Brunswick, NJ Tokyo, Japan Los Angeles, CA Clemson, SC Atlanta, GA Long-term (non-GENI) MobilityFirst Routing and Name Resolution Service Sites Short-term Wide Area ProtoGENI MobilityFirst Access Net ProtoGENI

More Related