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( )

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

4. 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.

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

6. 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

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

8. 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

9. 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

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

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

12. 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.

13. 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]

14. 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)

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

16. 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.

17. Digest Tree & Log ExampleC 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 P2
Current Digest @P2
dr2,4 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>: 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 : U2
Current
Digest @ U2
<dr5>, fp2,1
dr5: fp2,1
dr4: fp2,1
dr3: fp3,1
dr2: fp1,1
dr1: fp1,1
dr0 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 ,:

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

19. Simulation Evaluation
Page 19

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

21. Convergence time Single Update Convergence1 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

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

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

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

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