FLIPS Flexible IP Services over ICN Updates from
FLIPS: Flexible IP Services (over ICN) Updates from European efforts POINT & RIFE Dirk Trossen, Inter. Digital Europe July, 2016 © 2016 Inter. Digital, Inc. All Rights Reserved. 1
Pitch & Objectives © 2016 Inter. Digital, Inc. All Rights Reserved. 2
A Practical SDN Approach to Flexible Routing Bandwidth costs Our Solution will Drive Down Bandwidth Costs HBO NETFLIX AMAZON YOUTUBE HTTP Unicast Proliferation IP Unicast Legacy IP Gateway SDN controller SDN Switch NFV COTS CPE Emerging Network # of User Connections Unicast explosion simply not an option in 5 G • Single client-single host communication is well recognized as an inefficient approach • Subject of many workarounds through the years, mostly “caching & redirection” • POINT implicitly supports native multicast © 2016 Inter. Digital, Inc. All Rights Reserved. 3
A Practical SDN Approach to Flexible Routing Bandwidth costs Our Solution will Drive Down Bandwidth Costs HBO NETFLIX AMAZON YOUTUBE Benefit #1: True Multicast Implicit Multicast ICN Gateway Layer ICN Intelligence SDN controller Single Operator: FLIPS ICN Approach # of User Connections Innovative ICN technology approach for competitive 5 G (or before) operator networks • Aligns introduction of ICN concepts with SDN/NFV proliferation and growing trend to programmable infrastructure models • Combines seamlessly and complements emerging fog/edge computing thinking App (e. g. HTTP) ICN Gateway Layer IP ICN IP L 1/L 2 CPE © 2016 Inter. Digital, Inc. All Rights Reserved. 4
A Practical SDN Approach to Flexible Routing Bandwidth costs Our Solution will Drive Down Bandwidth Costs HBO NETFLIX Surrogate Mgmt. AMAZON YOUTUBE Benefit #2: Deep Surrogates Implicit Multicast ICN Gateway Layer ICN Intelligence SDN controller Single Operator: FLIPS ICN Approach # of User Connections The next logical step up for deep content caching is dynamic surrogates • Surrogates are softwarized servers that bring content Surrogate & services closer to mobile end users AND create new Surrogate-as-a-Service possibilities for operators App (e. g. HTTP) ICN Gateway Layer IP ICN IP L 1/L 2 CPE • Surrogate instances are controlled by SDN/ICN core functions which utilize ICN knowledge about what information is requested where by how many users © 2016 Inter. Digital, Inc. All Rights Reserved. 5
Our Ultimate Goal A surrogate service, integrated with NFV, to flexibly and predictively place/utilize surrogate servers within in-network computing resources under dynamically changing constraints… …while basing the viability of this proposition on the assumption of a nearto-zero second integration of surrogates into the routing fabric …while building a routing fabric as an ICN-based Routing-as-a-Service (Raa. S) solution directly on top of SDN-like switching networks © 2016 Inter. Digital, Inc. All Rights Reserved. 6
Architecture & Use Cases* * See HTTP-level multicast use case in BIER WG use cases draft © 2016 Inter. Digital, Inc. All Rights Reserved. 7
A Gateway-based System Architecture ICN NAP IP-only Receiver UE IP IP L 2 PCE : Path computation element (Rendezvous & Topology Management) FN: Forwarding Node NAP: Network Attachment Pont ICNSR FN L 2 Network Overlay PCE FN Network Underlay IP ICN Border GW IP NAP OF L 2 IP ICNTP ICNPR Note: the network overlay is assumed single-domain but can be provided across several operator domains IP IP-only Sender UE IP (BGP) L 2 ICN NAP © 2016 Inter. Digital, Inc. All Rights Reserved. IP-only Sender & Receiver UE 8
SDN Instantiation ICN NAP IP-only Receiver UE IP IP L 2 PCE : Path computation element OF: Open. Flow NAP: Network Attachment Pont ICNSR SDN Switch PCE ICNTP ICNPR OF SDN Controller IP IP-only Sender UE IP (BGP) L 2 IP ICN Border GW IP NAP OF OF L 2 SDN Switch L 2 ICN NAP © 2016 Inter. Digital, Inc. All Rights Reserved. IP Note: for now we assume a single operator due to the lack of inter-domain SDN solutions IP-only Sender & Receiver UE 9
BIER Instantiation ICN NAP IP-only Receiver UE IP IP L 2 PCE : Path computation element BF(I)R: Bit Forwarding Ingress Router BF(E)R: Bit Forwarding Egress Router NAP: Network Attachment Pont ICNSR PCE Routing underlay (e. g. , MPLS) IP ICN Border GW IP NAP IP ICNTP ICNPR Note: BIER is fully compliant with the multiple-operator underlay vs. single overlay operator model of FLIPS IP IP-only Sender UE IP (BGP) L 2 Multicast Flow Overlay BF(I)R L 2 BF(E)R L 2 ICN NAP © 2016 Inter. Digital, Inc. All Rights Reserved. IP-only Sender & Receiver UE 10
Multi-Site Enterprise IP ICN NAP IP Site A L 2 PCE : Path computation element BF(I)R: Bit Forwarding Ingress Router BF(E)R: Bit Forwarding Egress Router ICNSR PCE Routing underlay (e. g. , MPLS) ICN Border GW IP Peering for extranet access ICNTP ICNPR Site B IP (BGP) L 2 Multicast Flow Overlay BF(I)R L 2 BF(E)R L 2 The enterprise serves here as a BIER operator with dedicated peering for extranet access IP ICN NAP © 2016 Inter. Digital, Inc. All Rights Reserved. 11
Multi-Site Enterprise: Expected Benefits • HTTP-level synchronization could benefit from HTTP multicast capability • Service surrogacy for intranet services could easily be supported • Combined with (improved) surrogate synchronization • No need for dedicated replication infrastructure © 2016 Inter. Digital, Inc. All Rights Reserved. 12
5 G & MEC: Trial at Bristol is Open (planned for 08/2016) • NAPs collocated at each SDNconnected Wi. Fi AP http: //upload. game. flips • Surrogate located at each AP! 1 • Web-based mobile game 2 3 http: //game. flips SDN-enabled Bistrol-Is-Open city scale network http: //game. flips • Solve tourism riddle through uploading AV content to unlock parts of the riddle • Upload to central site (step 1) • Regularly replicated to game. flips (step 2) • User interaction (game and content consumption) with game. flips (step 3) • Benefits • multicast usage for replication (step 2) • Reduction of game latency (step 3) © 2016 Inter. Digital, Inc. All Rights Reserved. 13
5 G & MEC: Expected Benefits • Service surrogacy for latency reduction and traffic localization • Dynamic placement of surrogates close to (mobile) endpoints • Important for 5 G interactive use cases, e. g. , immersive experiences • Direct path mobility • Needs evaluation on path management update scalability • Regionalisation possible for improved scalability • HTTP multicast • Hugely important for high density viewing scenarios (stadium, …) • Driving replacement of RTP solutions © 2016 Inter. Digital, Inc. All Rights Reserved. 14
Solution Overview HTTP-over-ICN © 2016 Inter. Digital, Inc. All Rights Reserved. 15
Protocol Mapping - Basic Idea Interpret IP-based communication as Named Object Exchange Send HTTP GET to facebook. com Publish (HTTP GET) to “facebook. com” Register as facebook. com IP Network Receive HTTP GET Subscribe to “facebook. com” ICN Network © 2016 Inter. Digital, Inc. All Rights Reserved. Receive HTTP GET 16
A Naïve Realization Utilizing an Existing ICN Architecture Client c. NAP RVZ TM s. NAP ICNPR. Subscribe “facebook. com” HTTP GET facebook. com ICNPR. Publish “facebook. com” Server DNS Reg facebook. com ICNRT. Publish (client, server) ICNTP. Publish (FIDReq) ICNF. Publish (FIDReq, encap(HTTP GET)) HTTP GET facebook. com ICNPR. Subscribe “URL from HTTP GET” HTTP RESPONSE ICNPR. Publish “URL from HTTP GET” ICNRT. Publish (server, client) ICNTP. Publish (FIDRes) HTTP RESPONSE ICNF. Publish (FIDRes, encap(HTTP RESPONSE)) © 2016 Inter. Digital, Inc. All Rights Reserved. 17
More Refined Improving an Existing ICN Architecture Client c. NAP Only required for first request/response akin to domain-local DNS PCE s. NAP ICNPR. Subscribe “facebook. com” HTTP GET facebook. com Server DNS Reg facebook. com ICNPR. Publish “facebook. com” ICNTP. Publish (FIDReq) ICNF. Pub_i. Sub(FIDReq, NIDc, encap(HTTP GET)) HTTP GET facebook. com HTTP RESPONSE ICNRT. Publish(server, NIDc) ICNTP. Publish (FIDRes) HTTP RESPONSE ICNF. Publish (FIDRes, encap(HTTP RESPONSE)) © 2016 Inter. Digital, Inc. All Rights Reserved. 18
Opportunities Re-introduce multicast for increased network utilization Client Scenario: Client 2, . . , N c. NAP 2, …, N • c. NAP PCE s. NAP Multicast Gain vs. sync interval Server 150 Live video. HTTP transmission with ICN. Subscribe “facebook. com” GET facebook. com ICN 3000}. Publish “facebook. com” {500, 750, 1000, 1500, 2000, viewers 100 Quasi-synchronization within interval of 10 s, 5 s or 1 s ICN. Publish (FID ) 50 with uniform distribution of video chunk requests , encap(HTTP GET)) • This amounts to 250, 125 or 25 possible multicast ICN. Publish (FID 0 500 750 groups being formed for each chunk request Several pending Multicast gain ranges from 2 ICNto. Subscribe 120 “URL from HTTP GET” subscriptions for the ICN. Subscribe “URL from HTTP GET” same RESPONSE ICN. Subscribe “URL from HTTP GET” ICN. Publish “URL from HTTP GET” DNS Reg facebook. com PR PR • TP Req F • Req HTTP GET facebook. com 1500 2000 3000 10 5 1 PR PR HTTP RESPONSE PR ICNTP. Publish (FIDRes) HTTP RESPONSE ICNF. Publish (FIDRes, encap(HTTP RESPONSE)) Sent through inherent ICN multicast capabilities! © 2016 Inter. Digital, Inc. All Rights Reserved. 19
Opportunities Utilize deep and flexible service surrogacy for low latency delivery Client 2 Client Scenario: c. NAP PCE Activate surrogate server due to server load, congestion, path constraints, … s. NAP Server s. NAP 2 Server 2 Several surrogate server locations can be selected to optimize delivery DNS Reg facebook. com ICN. Subscribe “facebook. com” Picks the only • Surrogates. ICNcan be running (but not live) or need to be spun up. Publish “facebook. com” available server! • Initially, client requests are satisfied by a single server (FID ) • Then, additional server. ICNis. Publish activated, based on some constraints such as delay, congestion etc ICN. Publish (FID , encap(HTTP GET)) Now picks the HTTP GET facebook. com Performance estimation for activation of surrogate server: ICN. Publish “facebook. com” surrogate server due • Decision making: order of 100 ms (incl. gathering, e. g. , link state, information) to shorter path! ICN. Publish (FID ) • Activation: order of 10 ms ICN. Publish dependent (FID , encap(HTTP on, GET)) e. g. , NFV technologies) • Spinning up surrogate: order of minutes (entirely HTTP GET facebook. com -> surrogate can go. ICNlive within <1 s. Subscribe “URL from HTTP GET” • HTTP GET facebook. com PR PR TP Req F Req PR TP Req PR HTTP RESPONSE ICNPR. Publish “URL from HTTP GET” ICNTP. Publish (FIDRes) HTTP RESPONSE ICNF. Publish (FIDRes, encap(HTTP RESPONSE)) © 2016 Inter. Digital, Inc. All Rights Reserved. 20
Project Traction Partners (15) Project Duration Jan 2015 – Dec 2017 Platform provider Vendors Operators 6. 5 mio Euro Funding SMEs Academia POINT & RIFE are EUH 2020 Research & Innovation Programme Funded Projects under grant Nos. 643990 & 644663 (http: //www. point-h 2020. eu & http: //rife-project. eu) © 2016 Inter. Digital, Inc. All Rights Reserved.
Next Steps • Technology development • SDN integration (Open. Day. Light) • Mobility, HTTPS, resilience, Co. AP support for Io. T, … • Proof-of-concepts • 2 nd & 3 rd ETSI MEC Po. C event in Aug/Sep 2016 • Planned as ITU-T IMT 2020 ICN Po. C • Migration story for ICN • Suggested draft in ICNRG • BIER WG use case • ICN-based multicast overlay • Edge based protocol mapping © 2016 Inter. Digital, Inc. All rights reserved.
Demo Shown at MWC Barcelona, 5 G Summit London © 2016 Inter. Digital, Inc. All rights reserved.
Demo Setup Improvement: Multicast Gain ratio ofquality incoming vs. to outgoing bytes Improved local =playout (scale HD quality) (1. 0 foremulated IP solutions, expected >>10 in due POINTfrom solution) (while users will continue todemo receive SDto quality Bristol) Local visitors using IDC-provided demo tablets or their own devices Remote Video Feed 30+ emulated users in data center From our POINT/RIFE European Network Local Video Feed © 2016 Inter. Digital, Inc. All Rights Reserved. …To Our Booth in Barcelona
Schematic Setup Control traffic L 2 link IP-only Receiver UE NAP SDN Switch RV IP-only Sender UE NAP SDN Switch NAP HLS Video Server TM SDN Controller Mininet setup with ~30 emulated users in server cluster Local Playout Backhaul network © 2016 Inter. Digital, Inc. All Rights Reserved.
Demo Aspect 1: Multicast Gain Sending around 5 HLS streams via multicast IP-only Receiver UE NAP IP-only Sender UE SDN Switch NAP Aspect 1 demonstrates the multicast gain as well as the reduced server load through multicast delivery of HTTP responses in HLS video streaming scenario NAP RV HLS Video Server TM SDN Controller Sending 1 HLS stream via multicast Mininet setup with ~30 emulated users in server cluster © 2016 Inter. Digital, Inc. All Rights Reserved. Video traffic Control traffic L 2 link
Demo Aspect 2: Surrogate Server for Latency Reduction Surrogate Video Server IP-only Receiver UE Sending around 5 HLS streams via multicast NAP IP-only Sender UE SDN Switch NAP Aspect 2 demonstrates the latency reduction and video quality improvement through surrogate server at MWC NAP RV HLS Video Server TM SDN Controller Sending 1 HLS stream via multicast Mininet setup with ~30 emulated users in server cluster © 2016 Inter. Digital, Inc. All Rights Reserved. Video traffic Control traffic L 2 link
- Slides: 27