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)

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.

Industry Trends and Opportunities Services/Applications Long Term Software (Network Functions) Control Plane Applications SDN NFV (Adhoc/ Infrastructure) ICN Forwarding Plane Hardware Transport 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.

New Opportunity : NFV + SDN + ICN 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. NFV: Service Virtualization ICN Consumers Services SDN : Service-centric Network Programmability Creates a win-win model for both Operators and ASPs.

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. Page 5

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

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 Page 7

Comparing Service-Centric Protocols Service Layer Protocols Naming Name Resolution Heterogenous (Anycast, Routing, L2 ) Application API Security Context/Service Orchestration Mobility ICN (CCN/NDN/MobilityFirst/NetInf etc.) (Cleanslate) Flexible (Flat, Hierarchical) Coupled/de-coupled. Caching/Multicasting Transport Agnostic, highly adaptable (Ad hoc) (inherent features) Get ()/Put()/Interest/Data (Receiver Oriented) Content Level Context-centric/Service Composability/Natural Extension Best-effort/Late binding (control plane) SERVAL (Princeton, Prof. Rexford) (Incremental*) Flat Service ID Online Resolution. No Caching Consideration Adaptation at SERVAL level Session based (TCP/UDP) Session Level (Segmented) No specific Consideration, but Locator/ID Split / IP Based OpenADN (Washington State. Univ. Prof. Raj Jain) (Incremental*) Application tag/Application Level Switching Adaptation at OpenADN Level (SDN) IP Based. Application Meta-tags IP Based SoA (Web Services) (Deployed) URI/URL Service Broker/UDDI. Caching can be enabled Not Inter-networking technology Connection level security (HTTPS, SSL/TLS) SOAP/Web Service Description Language (WSDL) HTTP (“http as a narrow Waist”, Prof. Ion Stoica) DNS / Reverse/Forward Proxy. Caching Enabled Application Specific/ Get()/Put()/SGet()/ SoA Based or Other Protocols Incremental* : Changes affects the client stack, and introduces new network functions Page 8

ICN-Edge Cloud Service: High Level View ICN Cloud Ochestrator 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 Use ICN to connect user to ICN Services, and Services among themselves Realization on NFV based Platform Use SDN for service control, both at edge and global level. Services themselves could be anything. App. SAL. ICN Cloud Orchestrator ICN ICN Service Gateway ICN Service ICN Service NFV Platform ICN Service Router

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) Page 10

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

Scenario -1: Device Context Adaptation Service Gateway Controller App. Video Service Controller App. Video Client SAL Interest(/video-service/content/segment-x) ICN Controller Origin Video Service Service Gateway Video Service ICN ICN Service Router (Core) 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 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.

Scenario-2: BYOD Enterprise Conferencing Conf Client SAL Push Notifications/Heartbeat/Recovery Conference Proxy Content Interest/Data Conference Controller ICN Conf Client SAL ICN Platform ICN Service Gateway ICN 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 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]

Realizing Conferencing Service over ISR. ICN Service Router ISR Sync Service Controller Sync Service proxy Sync Service proxy SC Internet Legacy Router ISR Cache 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)

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 ICN Layer Sycn Service Client Service Layer Application layer ICN-Enabled UE Service API to App L2/L3 S-UNI (Data) S-UNI (Control) L2/l3 Access L2/L3 Access Internet ISR SC ISR ISR

Conference Design – Conference Proxy/Controller Hypervisor Service Access Proxy Service 1 Access Proxy (VM1) Service n Access Proxy (VMn) … 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 L2/L3 ICN Layer Sycn Service Client Service Layer Application layer ICN-Enabled UE Service API to App ICN layer Cache L2/L3 Interest/Data S-UNI S-NNI L2 Access L2 Access Internet SRN Heartbeat signaling SC Push notification msgs SRN SRN Content Interest/Data Internal flow The controller design is similar to the conference proxy, except in the details of the digest tree it maintains.

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

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+1 Um … 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

Simulation Evaluation Page 19

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. Page 20

Convergence time Single Update Convergence 1 2 3 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 Page 21

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. Page 22

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. Page 23

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. Page 24

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..! Page 25