Towards Software Defined ICN based Edge Cloud Services

www.huawei.com

Security Level:

HUAWEI TECHNOLOGIES CO., LTD.

Towards Software Defined ICN based Edge Cloud Services

Version: V1.0(20131109)

IEEE, CloudNet, 2013Ravi Ravindran, Xuan Liu, Asit

Chakraborti, Xinwen Zhang, Guo-Qiang Wang

(Huawei Research Lab, Santa Clara)

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

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

SDN

Control Plane

Forwarding Plane

NFV

Software (Network Functions)

Hardware

ICN

Applications

Transport

Services/ApplicationsLong Term

(Adhoc/ Infrastructure)

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential

Top right corner for field-mark, customer or partner logotypes.

----------------

The following nine groups of colors are an example of how our design colors can be used, please take note that you should only use one design color group per slide. For specific usage details, refer to the “Typesetting Standard”.

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.

Creates a win-win model for both Operators and ASPs.

NFV: Service Virtualization

ICNConsumers Services

SDN : Service-centric Network Programmability



----------------


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



----------------


ICN Edge Cloud Service

• Targets natural Information-centric Applications: IoT (V2V, Home Networks, Sensor Networks, ..) Enterprise (Conferencing, WAN Optimization Solutions..) Web ( Video Distribution..) …

Page 6

NFV Cloud

NFV Cloud

NFV Cloud

NFV Cloud

NFV Cloud

NFV Cloud

ICN Service Router

ICN UNI-APIV2VICN D2D

High Speed Optical

First Responder Services

Software Defined: Service Driven Virtualiztion

ICN Service Router

ICN Service Router

Home Networks

Enterprise

Home Networks

Enterprise



----------------


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.

Page 7

Exploit these with Service

Virtualization and Network

Programmability



----------------


Comparing Service-Centric Protocols

Page 8

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

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

Online Resolution. No

Caching Consideration

Adaptation at OpenADN Level

(SDN)

IP Based.


Session Level (Segmented)

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)

IP Based

HTTP (“http as a narrow Waist”,

Prof. Ion Stoica)

(Deployed) URI/URL

DNS / Reverse/Forward

Proxy. Caching Enabled

Application Specific/IP Based

Get()/Put()/SGet()/Session based

(TCP/UDP)

Connection level security (HTTPS,

SSL/TLS)

SoA Based or Other Protocols

IP Based

Incremental* : Changes affects the client stack, and introduces new network functions

ICN-Edge Cloud Service: High Level View

NFV Platform

NFV Platform

NFV PlatformICN Service Router

ICN

Ser

vice

G

atew

ay

ICN

Ser

vice

Pr

ofile

M

anag

er

ICN

Ser

vice

s

ICN

Ser

vice

G

atew

ay

ICN

Ser

vice

ICN

Ser

vice

ICN

Ser

vice

G

atew

ay

ICN

Ser

vice

ICN

Ser

vice

ICN Network

Controller

ICN Controller

ICN Network Controller

Network Core

ICN Cloud Orchestrat

or

ICN Cloud Orchestrat

orICN

App. SAL.

A-UNI

Origin Service-1

Origin Service-2 Origin

Service-3

ICN Cloud Orchestrator

ICN Cloud Ochestrator

ICN Service Controller

S-UNIICN Service Controller -2

ICN Service Router

ICN Service Router

SDN Components



----------------


Interfaces and Functions :

Page 10

VFSR-1 VFSR-2 VFSR-3 VFSR-4

ICN Network ControllerICN Service

Controller -1

ICN Cloud Orchestrator

ICN Service Controller -2

ICN Service OwnerICN Service Customer

ICN Service API

ICN Network Control API

ICN Service Control API

UsersA-UNI

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)

S-UNI



----------------


Page 11

Service Contextualization: ICN-UNI API (SAL-SAP)

App-1

Layer-3/Layer-2

ICN

Service Access Layer (SAL)

Content

Service Context Management

Service Publish

Service Boot-strapping

Mobility

Location

Social

Device

App-2

App-N

Context Mgmt.

ICN APP-SAL API

Home RouterSmart TV

Smart Phone

ICN Service Router

Layer-3/Layer-2

Service Resource Management

Service Monitoring

Service Publish

ICN SAP-Service API

Service-1

Service-2

…

Service-N

Service Access Point (SAP)

A-UNI API ICN Service RouterL3/L2

…ICN Service Gateway

ICNService-1

ICNService-2

UEICN Service Gateway

Service Request Management

Service Boot-strapping

Service Request Management

(Context Processing)

Service Adaptation through Contextualization and Service Orchestration

Scenario -1: Device Context Adaptation

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

ICN Service Router

Video ServiceService Gateway ICN Controller

Video Service Controller App.

Origin Video Service

(Core)

NFV Cloud (Edge)

ICN

Video Client

SAL

Interest<service discovery, Attachment>

Interest<service name-space, {service attributes}>

Interest(/video-service/content/segment-x)

Data(/video-service/content/segment-x)

ICN Platform

Transcoding Service

Storage Service

ICN

Video Client SAL

Service Gateway

Controller App.

Interest(service_gateway/migrate<{service attributes>/<migration_attributes>) Service Composition :

Interest(/video/content/{session_state}) Interest ( /video/content/{session_state}, {storage + transcoding})

Interest(/video-service/content/segment-x)

Scenario-2: BYOD Enterprise Conferencing

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

Push Notifications/Heartbeat/Recovery

Content Interest/Data

ICN Platform

Conference Proxy

ICN Service Gateway

ICN Platform

Conference Proxy

ICN Service Gateway

ICN Platform

Conference Proxy

ICN Service Gateway

ICN Platform

Conference Proxy

Conference Controller

Conf Client

SAL

ICN

SAL

ICN

Conf Client

Conf Client

SAL

ICN

Conf Client

SAL

ICN

Heterogeneous Devices

Realizing Conferencing Service over ISR.

InternetISR

ISR

Sync Service proxy

SC

Sync Service

Controller

Gateway

Gateway

Legacy Router Legacy Router

Legacy Router

Sync Service proxy

PULL

con

tent

Push

Noti

ficati

on

Step 2: Push Notification

Step1: PUB/SUB Content

Step 3: Retrieve Content (Interest/Data Flow)

UE1

UE2

UE3

ISR ICN Service Router

CacheCache

Conference Design – User Equipment

Service API to Applications

L2/L3

Sync Service Client

Chat VWB Other App

…

S-UNI (Control) S-UNI (Data)

Cache

Internet

ISR

ISR

SC

ISR

L2/L3 Access

L2/l3 Access

Push notification msgs


Internal flow

Digest log

Cache

Fingerprint Processor

Heartbeat Signal Processor

Heartbeat signaling App-based Control Info

ICN Layer

Service layer

Other service management

blocks

Other Service-related flows

L2/L3ICN Layer

Sycn Service Client

Service Layer

Application layer

ICN-Enabled UE

Service API to App

ICN layer

L2/L3

Sync Service Proxy

Cache

S-UNI S-NNI

Internet

L2 Access L2 Access

SRN

SRN

SC

SRN

Interest/Data


Internal flow

Push notification msgs

Digest log

Cache

Fingerprint Processor

Heartbeat Signal

Processor

Heartbeat signaling

Other service management

blocks

Service API to Applications

Application Pool

Service layer

Hypervisor

Service Access Proxy

Service 1 Access Proxy (VM1)

Service n Access Proxy (VMn)

…

L2/L3ICN Layer

Sycn Service Client

Service Layer

Application layer

ICN-Enabled UE

Service API to App

App-based Control Info

Conference Design – Conference Proxy/Controller

• The controller design is similar to the conference proxy, except in the details of the digest tree it maintains.

C

P1 P2 P3

U1 U2 U3 U4U5

Logic connectivity at t3 (steady state)

New join at t4

New join at t5

Log @ U2Current Digest @ U2

<dr5>, fp2,1

dr5: fp2,1

dr4: fp2,1

dr3: fp3,1

dr2: fp1,1

dr1: fp1,1

dr0

Digest Tree & Log Example

dc3

dp1,2 dp2,1

fp1,1 fp2,1 fp3,1

dc3

dp1,2 dp2,1

fp1,1 fp2,1 fp3,1

dc2

dp1,1 dp2,1

fp1,0 fp3,0

dc1

dp1,1

fp1,1

dc0Digest Tree Log

Current Digest Tree


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


<dr2,4>, fp2,1

dr2,4: fp2,0 dr2,3: fp3,0 dr2,2 :fp3,0 dr2,1 :fp1,0 dr2,0 ,:

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

dc3

Log @ P2Current 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>:

dr1,k

dcwdp1,j

fp1,fp1(t) fpm,fp2(t)… )()()(

)()()(

)()(

21

1

11

tdptdptdcw

tdptdctdrk

tfptdpj

n

jj

m

ii

C

P1 P2 Pn

U1 Um+1Um…

…

Um+k

Remote update state

Local update state

Tracking the number of updates

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

Hierarchical View of Connectivity

The digest tree at time t at P1

• The network load (for n updates) scales linearly with number of proxy nodes rather than O(n2 ) in a peer-to-peer mode



----------------

The following nine groups of colors are an example of how our design colors can be used, please take note that you should only use one design color group per slide. For specific usage details, refer to the “Typesetting Standard”.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



----------------


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

Convergence time12

3



----------------


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.

Page 23

• The convergence time improves as long as the capacity of the network link is planned correctly.



----------------


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

Copyright©2011 Huawei Technologies Co., Ltd. All Rights Reserved.The information in this document may contain predictive statements including, without limitation, statements regarding the future financial and operating results, future product portfolio, new technology, etc. There are a number of factors that could cause actual results and developments to differ materially from those expressed or implied in the predictive statements. Therefore, such information is provided for reference purpose only and constitutes neither an offer nor an acceptance. Huawei may change the information at any time without notice.

Thank youwww.huawei.com

Documents

Towards Software Defined ICN based Edge Cloud Services