Towards Software Defined ICN based Edge Cloud Services

1. Towards Software Defined ICN based Edge Cloud Services IEEE, CloudNet, 2013 Ravi Ravindran, Xuan Liu, Asit Chakraborti, Xinwen Zhang, Guo-Qiang Wang (Huawei Research Lab, Santa Clara) • Version: V1.0(20131109)

2. ICN Motivation • About a ~2 years back, ICN-RG (IRTF Working Group) was formed, which made the term ICN official. • Umbrella of many protocols CCN/NDN, MobilityFirst, NetInf, PSIRP etc. • ICN aims at making information as the waist rather than connectivity as in IP. • ICN is a unified platform which addresses several IP issues with Multicast, Multi-homing, Security, and Mobility. • But why Deploy it ? • New “Things”, Applications/Services • Connectivity: Adhoc + Infrastructure interactions, Multi-Cloud • Do things in an efficient and scalable manner than existing applications. • This paper focuses on a way Operators can gain from ICN.

3. Industry Trends and Opportunities Services/Applications Long Term • De-coupling increases flexibility, encourages innovation and faster evolution. • Services/Applications will drive new technologies, same is the case for ICN too. • The SDN/NFV allows ICN introduction atleast in an experimental manner. Software (Network Functions) Control Plane Applications SDN NFV (Adhoc/ Infrastructure) ICN Forwarding Plane Hardware Transport

4. New Opportunity : NFV + SDN + ICN NFV: Service Virtualization • NFV enables a platform to virtualize network functions. • Edge clouds are Closer to the users. • Service Virtualization, applications are tightly bound to service locators. • SDN drives service-centric network programmability. • Today realized as overlaid service engineering or at the edge (Data centers) • ICN inter-connects Consumers with Services at the information level, in a receiver-centric model.  NFV enabled service virtualization, with SDN’s service-centric network programmability, and Information-Centric Service Connectivity can realize rich services. Consumers Services ICN SDN : Service-centric Network Programmability Creates a win-win model for both Operators and ASPs.

5. ICN Edge Cloud Service : ICN Service Router Platform • A NFV-based ICN Platform to host several ICN Services • Envision a high performance ICN based router, with Virtualized Service Plugins • Software defined in the sense that service connectivity is managed by specific service controllers. • Supports both real-time and non-real time services, and multiple ICN protocols • Overlaid model, ICN service layer components extends to the User Entity. • Contextualized service delivery.

6. ICN Service Router ICN Edge Cloud Service V2V ICN UNI-API ICN Service Router ICN Service Router ICN D2D Software Defined: Service Driven Virtualiztion Enterprise • Targets natural Information-centric Applications: • IoT (V2V, Home Networks, Sensor Networks, ..) • Enterprise (Conferencing, WAN Optimization Solutions..) • Web ( Video Distribution..) • … NFV Cloud NFV Cloud First Responder Services NFV Cloud High Speed Optical NFV Cloud Home Networks NFV Cloud NFV Cloud Home Networks Enterprise

7. What are Information-Centric Applications ? Has Characteristics of : • Being Shareable • Versus Host-centric : ‘I can only trust information from a specific host/device/user’ • Location Independent • Transport Independent • Benefits from Name based routing • Mobility (Producer)/Multi-homing/Anycast • Leverage Network Caching • Multicast/Mobility (Consumer) • Content level Security • Rather than session level. Exploit these with Service Virtualization and Network Programmability

8. Comparing Service-Centric Protocols Incremental* : Changes affects the client stack, and introduces new network functions

9. ICN Cloud Ochestrator ICN-Edge Cloud Service: High Level View ICN Cloud Orchestrator ICN Controller ICN Cloud Orchestrator ICN Service Controller -2 S-UNI ICN Network Controller Origin Service-1 Origin Service-2 Origin Service-3 ICN Service Gateway SDN Components ICN Service ICN Service ICN Service Profile Manager ICN Service Gateway ICN Services ICN Service Router ICN Service Controller ICN Service Router NFV Platform A-UNI Network Core ICN Network Controller NFV Platform App. SAL. ICN Cloud Orchestrator ICN Service Gateway ICN ICN Service ICN Service NFV Platform ICN Service Router

10. Interfaces and Functions : S-UNI A-UNI Users A-UNI : Service Discovery/Service Management /Service Contextualization/ Application Delivery (Interest/Data) S-UNI: Service Virtualization (Provisioning, Scaling)/ Service Monitoring ICN Service Control API: Service Event Processing (Context, Migration, ICN Flow handling.) – Per ICN Service ICN Network Control API: Programming ICN Service Forwarding Policies/Transport Routing (e.g. configuring CCN FIBs)

11. Service Contextualization: ICN-UNI API (SAL-SAP) Service Adaptation through Contextualization and Service Orchestration

12. Service Gateway Controller App. Video Service Controller App. Scenario -1: Device Context Adaptation Video Client SAL Interest(/video-service/content/segment-x) Origin Video Service ICN Controller Service Gateway Video Service ICN (Core) ICN Service Router • In this example user changes the device from the smart phone to a smart TV. • The device simulataneosly signals the action to the service gateway and the peer device, the gateways forwards the control message to the Video Service Controller Application. • The controller orchestrates a new service composing the fetching of video and real-time transcoding service. • Here the service is virtualized among device applications. Interest<service name-space, {service attributes}> Interest<service discovery, Attachment> Interest(service_gateway/migrate<{service attributes>/<migration_attributes>) NFV Cloud (Edge) Video Client SAL Service Composition : Interest(/video/content/{session_state}) Interest ( /video/content/{session_state}, {storage + transcoding}) ICN Data(/video-service/content/segment-x) ICN Platform Interest(/video-service/content/segment-x) Storage Service Transcoding Service

13. Scenario-2: BYOD Enterprise Conferencing Conf Client SAL Conference Proxy Push Notifications/Heartbeat/Recovery Conference Controller Content Interest/Data ICN ICN Platform Conf Client SAL ICN Service Gateway ICN • Here we realize instance of conference proxy’s per Enterprise site and one Conference Controller. • We implement Notification/Heartbeat/Recovery using “Push” model compared to “Pull” of ChronoSync [NDN, Tech Report] Conf Client SAL Conference Proxy ICN Conference Proxy ICN Platform Conf Client SAL ICN Platform ICN Service Gateway ICN Conference Proxy Heterogeneous Devices ICN Platform ICN Service Gateway

14. Realizing Conferencing Service over ISR. ICN Service Router ISR Sync Service Controller Sync Service proxy Sync Service proxy SC Internet Legacy Router Cache ISR ISR Cache Push Notification PULL content Legacy Router Legacy Router UE3 UE1 Gateway Gateway UE2 Step1: PUB/SUB Content Step 2: Push Notification Step 3: Retrieve Content (Interest/Data Flow)

15. Conference Design – User Equipment Content Interest/Data Chat VWB … Other App Push notification msgs Internal flow Service API to Applications Heartbeat signaling App-based Control Info Fingerprint Processor Heartbeat Signal Processor Other Service-related flows Other service management blocks Digest log Cache Sync Service Client Service layer Cache ICN Layer L2/L3 S-UNI (Data) S-UNI (Control) L2/l3 Access L2/L3 Access Internet ISR Application layer SC Service API to App Sycn Service Client ISR Service Layer ISR ICN Layer L2/L3 ICN-Enabled UE

16. Conference Design – Conference Proxy/Controller Application Pool Service API to Applications App-based Control Info Fingerprint Processor Heartbeat Signal Processor Other service management blocks Digest log Cache Sync Service Proxy Service layer Service Access Proxy Service 1 Access Proxy (VM1) Service n Access Proxy (VMn) ICN layer Cache … L2/L3 Interest/Data Hypervisor S-UNI S-NNI L2 Access L2 Access Internet SRN Heartbeat signaling SC Application layer Service API to App Push notification msgs SRN SRN Sycn Service Client Content Interest/Data Service Layer • The controller design is similar to the conference proxy, except in the details of the digest tree it maintains. ICN Layer Internal flow L2/L3 ICN-Enabled UE

17. Digest Tree & Log Example Current Digest Tree dc3 C Current Digest @P1 dp1,2 dp2,1 Log @ P1 dr1,5 P1 P2 P3 <dr5> : <dp1,2, dc3>: fp2,1 <dr4> : <dp1,2, dc2>: fp2,1 <dr3> : <dp1,1, dc2>: fp3,1 <dr2> : <dp1,1, dc1>: fp1,1 <dr1> : <dp1,1, dc0>: fp1,1 <dr0> : <dp1,0, dc0> fp1,1 fp2,1 fp3,1 dp1,2 dc3 U1 U2 U3 U5 U4 Digest Tree Log dc3 dc2 dc1 dc0 fp1,1 fp2,1 Logic connectivity at t3 (steady state) dp1,2 dp2,1 dp1,1 dp2,1 dp1,1 Current Digest @P2 New join at t4 Log @ P2 dr2,4 Current Digest @ U1 Current Digest @ U2 Current Digest @ U3 Log @ U1 Log @ U2 Log @ U3 <dr4> : <dp2,1, dc3>: fp2,1 <dr3> : <dp2,1, dc2>: fp3,1 <dr2> : <dp2,1, dc1>: fp3,1 <dr1> : <dp2,0, dc1>: fp1,1 <dr0> : <dp2,0, dc0>: dr1,5: fp2,1 dr1,4 : fp2,1 dr1,3 : fp3,1 dr1,2 : fp1,1 dr1,1 : fp1,1 dr1,0 : dr2,4: fp2,0 dr2,3: fp3,0 dr2,2:fp3,0 dr2,1:fp1,0 dr2,0 ,: dr5: fp2,1 dr4: fp2,1 dr3: fp3,1 dr2: fp1,1 dr1: fp1,1 dr0 fp1,1 fp2,1 fp3,1 fp3,0 fp1,0 fp1,1 New join at t5 dp2,1 dc3 <dr1,5>,fp2,1 <dr2,4>, fp2,1 <dr5>, fp2,1 fp3,1

18. Tracking the number of updates Hierarchical View of Connectivity • Generic form of digest tree at a Sync Service Proxy (P1) at time t– Steady State • The digest tree at the Sync Service Proxy has to track updates from both Sync Service Clients and the Sync Service Controller • Digest values at different levels of the digest tree are updated at different time • We use the subscripts to track the number of updates occurred. C … P1 P2 Pn … U1 Um Um+1 Um+k The digest tree at time t at P1 dr1,k dp1,j dcw … fp1,fp1(t) fpm,fp2(t) • The network load (for n updates) scales linearly with number of proxy nodes rather than O(n2) in a peer-to-peer mode Local update state Remote update state

19. Simulation Evaluation

20. Simulation • Objective: To study the convergence time as we scale with number of participants and compare with peer-to-peer case. • Core Topology : Abilene and 3x3 Grid • Access Topology : 2 Level Tree Topology • Parameters • # of participants : 60-300 • Poisson Content Generation (0.5-10)contents/sec • Core link Capacity : 1-5 Gbps • Core Link propagation delay : 10ms • P2P Case: Simple 3 User Case.

21. 1 Convergence time 2 Single Update Convergence • Fig. 1. & 2 corresponds to two topologies, shows convergence among all participant. • Fig. 3, shows multiple update convergence. Notifications and content convergence is deterministic. • Participants in the same cluster synchronize faster than remote clusters 3

22. Scaling Number of Participants • The scenarios with 50 and 100 participants are invariant to Content Generation rate. • In the 300 case, the access link capacity begins to get congested, hence the convergence time increases.

23. Varying Content Generation Rate and Network Conditions • Here the Link capacity is set to 0.1Gpbs. • The content rate causes proportional increase in data traffic, hence the convergence time increases. • The convergence time improves as long as the capacity of the network link is planned correctly.

24. Peer-to-Peer Conferencing Case: • Here the Participants synchronize through pulling information over a name space. • In-determinants : Multiple Updates, Exclusion of multiple contents to same name, Rate of Interest expression, • High control overhead to improve convergence time, but doesn’t require a control infrastructure.

25. Conclusions • ICN based Service Layer a possible way to introduce ICN into Operator’s domain. • Can Leverage all ICN features : Name based Routing, Multicasting, Security, Mobility Handling. • Combined with NFV and SDN allows to achieve the goal of true Service Centric Networking. • Platform suitable for ICN applications: Conferencing, IoT/M2M, Video Multicasting. • Conferencing can be enabled as a VNF over the platform. • Showed through simulation analysis the scalability of the conferencing framework. • We are prototyping this platform, hope to share our experience on this in the future..!