aconsideraonon informaoncentricnetworkingicn/wp-content/uploads/2015/04/icn_kickoff_3.pdf · ispld...

A Considera,on on Informa,on Centric Networking

April 7, 2015 Fumio Teraoka

Keio University, Japan [email protected]

2015/04/07 IEICE ICN Kick-‐off Workshop 1

ICN: Informa,on Centric Networking

•  Host-‐centric model to content/informa0on-‐centric model

•  Representa,ve mechanisms: –  Triad [Cheriton00] –  DONA [Kopponen07] –  NDN (CCN) [Jacobson09] <= this talk focuses on this –  PURSUIT [Fo,ou12] –  etc.

•  A lot of proposals for improving NDN mechanism


Overview of NDN (1)

•  Content Chunk layer as narrow waist in protocol stack

•  Interest packet and Data packet

•  Pull model (receiver ini,ated)

•  In NDN router: –  FIB (Forward Informa,on Base) –  PIT (Pending Interest Table) –  CS (Content Store)


content chunks

security

file stream

strategy

IP UDP

copper fiber

browser chat

…

…

…

Overview of NDN (2)


(1) Interest packet reaches router

Content Store (CS)

Pending Internet Table (PIT)

Forwarding Informa,on Base (FIB)

(2) If cache hits, Data packet is returned

(3) If PIT has entry, incoming i/f is added to PIT; Interest is discarded. (4) Interest is forwarded based on FIB.

(4) Interest

(2) Data

(1) Interest

(5) Data packet reaches router

(7) Data is forwarded to i/f’s registered with PIT

(5) Data

(7) Data

(6) Data is cached in CS

NDN router

Two Points of Considera,on

•  What configura0on of func0ons is suitable for ICN? –  Narrow waist configura,on vs. hierarchical configura,on

•  What services is ICN suitable for? (applicability of ICN) –  “one-‐fits-‐all” approach vs. one of services approach

•  This talk argues that: –  Hierarchical configura,on of func,ons is suitable for ICN and –  ICN is suitable for retrieving sta,c and stored content.


Func,ons Necessary for ICN

•  Scalable content finding –  Scalability in terms of FIB size and traffic for rou,ng informa,on announcement

•  Efficient content transfer •  Mobility support –  Client / server mobility –  Fast handover

•  Security (access control) –  Confiden,ality of content data –  Valida,on of user authen,city and privilege


Configura,on of Func,ons: Scalable Content Finding


Name-‐Based Rou,ng in NDN

•  Content name syntax: •  e.g., /parc.com/videos/WidgetA.mpg/_v<,mestamp>/_s3

•  Suppose that /[email protected]/RFC/rfc2460.txt and /[email protected]/RFC/rfc4861.txt are stored on different servers: –  FIB entries for /ieo.org/RFC cannot be aggregated. –  At worst, FIB must have an entry per content name. –  Large traffic for announcement of name-‐based rou,ng


globally-‐routable name

organiza,onal name

conven,onal / automa,c

user-‐app supplied name versioning & segmenta,on

ISP-‐D

ISP-‐A

Example of Name-‐Based Rou,ng in NDN


ISP-‐B ISP-‐C

rt-‐A rt-‐B rt-‐C

rt-‐D

/ieo.org/RFC/rfc2460.txt

if-‐a if-‐b

if-‐c



content name i/f

/ieo.org/RFC/rfc2460.txt if-‐a

/ieo.org/RFC/rfc4861.txt if-‐b

/ieo.org/RFC/rfc4862.txt if-‐c

FIB on rt-‐D

“/ieo.org/RFC” cannot be aggregated

svr-‐A svr-‐B svr-‐C

Locator-‐Based Rou,ng in ICN

•  Suppose that: –  Content name is finally resolved to locator of content server in applica0on layer and

–  Locators are allocated to nodes hierarchically.

•  As a result: –  FIB entries are aggregatable. –  No rou,ng informa,on other than that in network layer is announced => no rou,ng overhead for ICN

– Mapping system is required: content name => locator list of content servers


Example of Locator-‐Based Rou,ng in ICN


ISP-‐D

ISP-‐A ISP-‐B ISP-‐C

rt-‐A rt-‐B rt-‐C

rt-‐D


if-‐a if-‐b

if-‐c



svr-‐A svr-‐B svr-‐C

ieo.org

content name server

RFC/rfc2460.txt srv-‐a

RFC/rfc4861.txt srv-‐b

RFC/rfc4862.txt srv-‐c

mapping table

name resolu,on request for /ieo.org/*

Configura,on of Func,ons: Efficient Content Transfer


Content Transfer in NDN

•  Basically, 1 Data packet per Interest packet –  It yields large traffic of Interest packets although there are several proposals for reducing Interest packets

•  Conges,on control is necessary in content chunk layer. –  It makes content chunk layer more complicated.

•  Mul,path cannot be used. –  Data packet is forwarded on reverse path of Interest packet


Content Transfer in Hierarchical Approach

•  Transport layer is responsible for efficient content transfer. – Well-‐tuned conges,on control, e.g., AIMD in TCP – Mul,path can be used by, e.g., MPTCP or SCTP.



conges,on control is applied

mul,path connec,on

Configura,on of Func,ons: Mobility Support


Client Mobility Support in NDN

•  Easy to support client mobility –  Auer client moves, it sends Interest packet at new loca,on. => Data packet reaches client.

–  Some Data packets might be forwarded to old loca,on. –  Redundant Data packets might be forwarded to old loca,on.

•  Difficult to support server mobility –  Server must announce name-‐based rou,ng informa,on. => large traffic

–  Rou,ng convergence takes long ,me.


Example of Mobility Support in NDN


. . .

. . .

(1)  Interest packets

(2) move

(4) Interest packets

(5) Data packets reach new loca,on

(3) Data packets reach old loca,on

. . .

content server

content server

(1) move

(2) announce a lot of rou,ng entries

client mobility server mobility

. . .

(3) long ,me for convergence

(4) Interest might be forwarded to wrong direc,on or get lost

ICN in ID/Locator Split Approach

•  Content name is resolved to ID (instead of locator) of content server. –  ID is loca,on-‐independent.

•  ID is mapped to locator in network layer. – Mapping system is required.

•  Client / server mobility is efficiently supported. – When client / server moves, 1 RTT is required to no,fy correspondent node of new locator.

–  Some packet might be forwarded to old loca,on.


Overview of Mobility Support by ID/Loc Split


iden,fier

locator

iden,fier

iden,fier

locator

Applica,on layer

Transport layer

Network layer

Iden,fica,on sublayer

Rou,ng sublayer

mapping

specifies dst node by iden,fier

recognizes dst node by iden,fier

locator

locator

mapping

iden,fier

iden,fier

iden,fier

source node des,na,on node

recognizes src node by iden,fier

recognizes src node by iden,fier

Fast Handover

•  Mobile node (client / server) must send control packet as soon as it moves. –  NDN: Interest packet –  ID/Loc split: loca,on update message

•  Some cross-‐layer collabora0on is required. –  In NDN, content chunk layer must be able to detect node movement.

–  In ID/Loc split, link layer must be able to no,fy network layer of node movement.


Issues of Fast Handover: in IPv6


channel scan (order of sec)

channel switch (order of msec)

L2 handover finish

comm. quality degrade

L2

L3 wait for RA (order of sec or msec)

DAD (order of sec)

L3 signaling (order of 10msec)

L3 handover finish

total disrup,on ,me (more than a few sec)

Previous Access Router (PAR)

New Access Router (NAR)

MN

RA

,me

Example of Cross-‐Layer Collabora,on: L3 Driven Fast Handover


background scan during communica,on signal level

going down

L2-‐LinkStatusChanged.ind

L2-‐PoAList.req/conf

DAD Request

DAD Reply

L2-‐LinkConnect.req/conf

L2-‐LinkUp.ind

signaling

NAR MA/HA

total disrup,on ,me

(1)  channel scan is done in background

(2)  DAD is done before handover

L3

L2

(3)  L2 handover comple,on is no,fied immediately

,me

Configura,on of Func,ons: Access Control


Access Control in NDN

•  Security is provided by “security layer” just above content chunk layer.

•  NDN takes into account: –  Data authen,city by PKI and –  Data confiden,ality by encryp,on.

•  NDN does not take into account: –  confiden0ality of existence of named content and –  retrieval of encrypted Data packet.


Access Control in Hierarchical Approach

•  Authen,ca,on and authoriza,on of user are required in applica0on layer when: –  User tries to resolve content name to ID list of content servers, –  User tries to get avributes of content, and –  User tries to retrieve content data.


Summary of Func,on Configura,on


name resolu,on

mul,path transfer

conges,on control

ID-‐Loc mapping

Loc-‐based rou,ng

ICN control -‐ bandwidth aggrega,on -‐ fault tolerance

-‐ fairness

-‐ mobility support -‐ mul,homing support

-‐ scalable rou,ng

-‐ in-‐network caching

-‐ scalable/authen,c content name to node ID mapping

Applica,on Layer

Transport Layer

Network Layer

Apps. content name

Node IDs of content servers

Node Locators of content servers

Func,ons Name

Resolu,on Features

Auth & Authz

cross-‐layer collabora,on

Applicability of ICN


Stored Content (Sta,c Content)

•  ICN is suitable for retrieving stored content. –  e.g., web browsing, file retrieval, etc.

•  In-‐network caching is effec,ve.

•  Content name must be changed if content is modified. –  In NDN, content name has “versioning & segmenta,on” part.


Dynamically Generated Content

•  Is ICN suitable for retrieving dynamically generated content? –  e.g., VoIP, live streaming, answer to database query.

•  “Host-‐centric” and push model are suitable for VoIP and live streaming.

•  Mul0cast in network layer is more suitable for delivering VoIP conference data. –  Caching is not effec,ve.

•  How is answer to database query named?


Case Study: VoIP (Person-‐to-‐Person)

•  Interac,ve applica,on with 2 users •  In NDN, both users send Interest packet for each VoIP data chunk. –  Size of VoIP data chunk is small => large # of Interest packets –  VoIP data is dynamically generated => in-‐network cache is useless.

–  Every Interest packet reaches the other user.

•  No benefit for VoIP on NDN •  Host-‐centric & push model are suitable.


Case Study: VoIP (Conference Mode)

•  Interac,ve applica,on with a few users •  Mul,cast from a user to others is suitable. –  In-‐network caching is not necessary.

•  In NDN, each user sends Interest packet to other users for each VoIP data chunk. –  A single Interest packet reaches each sender although most Interest packets are discarded on intersec,on router.

•  Large # of Interest packets •  Push model & mul,cast in network layer are suitable.


Case Study: Live Streaming

•  Non-‐interac,ve applica,on for a single sender and a lot of receivers –  In-‐network caching is effec,ve.

•  In NDN, each receiver sends Interest packet to sender for each data chunk. –  Receiver can control data flow similar to YouTube

•  In-‐network caching is effec,ve. •  Pull model is suitable for live streaming.


Summary of Applicability of ICN

•  ICN is not “one-‐fits-‐all” mechanism.

•  ICN is suitable for retrieving stored and sta,c content.

•  Dynamically generated content should be delivered based on host-‐centric model.

•  Mul,cast in network layer (push model) is suitable for interac,ve applica,ons.

•  NDN might be suitable for live streaming. 2015/04/07 IEICE ICN Kick-‐off Workshop 33

Our Ongoing Research:

ZINK: ICN on ZNA (ZNA: New Genera,on Network Architecture)


Research Trends in Network Architecture

•  Layered structure or non-‐layered structure ? –  RBA [Braden03]: protocol stack to protocol heap –  SILO [Duva07]: just in-‐,me protocol stack –  RNA [Touch08]: Recursive Network Architecture –  CCN (NDN) [Jacobson09]: Named Data Networking

•  We concluded that layered structure is appropriate in terms of physical structure of network, ease of understanding, ease of implementa,on, etc.

•  ZNA (Z Network Architecture) [Teraoka09]: 6-‐layer model –  Configuring exis0ng and new func,ons in a layered structure.


Features of ZNA

1.  Session layer provides more sophis,cated communica,on paths.

2.  ID/Locator split supports mobility, mul,homing, and security

3.  Network layer (L3) protocol heterogeneity allows coexistence of new and old L3 protocols

4.  Cross-‐layer collabora,on makes processing in a layer more efficient by using informa,on in other layers

5.  Control/data-‐plane split realizes reliable signaling 6.  Support of datagram, CoS, and QoS communica,on


Features of ZNA







Valida,on of session layer [Ide12]

Session Layer Func,on (1): Bundled Path

•  L5-‐path = a set of two or more L4-‐paths –  All L4-‐paths are used simultaneously → bandwidth aggrega,on –  One is used as primary and others are used as secondary → fault tolerance

•  A model of mul,-‐path communica,on (SCTP, MPTCP)


!"!

!#!

!$!

!%!&!

!"!

!#!

!$!

!%!&!

!#'()*+,-+'./01!

!$23/01!

!$23/01!

"!

Session Layer Func,on (2): Spa,ally-‐Spliced Path

•  L5-‐path = spliced L4-‐paths divided spa,ally –  splicer: a node that splices L4-‐paths –  L5 can apply local policy

•  A model of middle boxes such as NAT and TCP accelerator •  The ID of an end node is known to the peer node.


!"!

!#!

!$!%!

!&!

!"!

!#!

!$!%!

!&!

!"!

!#!

!$!%!

!"'()*+*,,-.(),/012'3*45!

!#.)*45! !#.)*45!

!".61,*-'76'8),/016!

"!

Features of ZNA







ZNP (Z Network Protocol) [kanemaru11]

Features of ZNA







CLINEX [Yonemura13]

Example of Cross-‐Layer Collabora,ons in the Current Internet

•  Fast Handover –  Collabora,ons between L2 and L3 –  IEEE 802.11a + LIN6 –  L3 handover ,me: 10-‐15 msec (IEEE802.11a + LIN6)

•  Fast failover / Fast Handover in L4 (SCTP) [Han08] –  Collabora,ons among L2, L3, and L4 –  Ethernet + IPv6 + SCTP –  L4 failover ,me: RTT + 120-‐140 μsec –  L4 handover ,me: 100 msec

•  L2 handover ,me: 10 msec


ZINK Architecture

IEICE ICN Kick-‐off Workshop 43

Apps.

Name Resolu,on System

AAA Infrastructure Applica,on Layer (L6)

Func,ons Features

-‐ scalable/authen,c content name to node ID mapping

-‐ authen,ca,on and authoriza,on of clients

ZINK control

bundled path

spa,ally-‐spliced path

in-‐network caching Session Layer (L5)

TCP UDP -‐ end-‐to-‐end transfer (w/ or wo/ reliability and conges,on control)

Transport Layer (L4)

-‐ bandwidth aggrega,on -‐ fault tolerance

-‐ ZINK overlay network

ZNP -‐ ID/Loc split -‐ mobility/mul,homing support -‐ locator based rou,ng

Network Layer (L3)

Link and Phy. Layers (L1-‐2) Ethernet WiFi . . .

intra/inter-‐node cross-‐layer coopera,on

2015/04/07

Current Status of ZINK

•  Proof-‐of concept prototype was implemented on Linux. –  On IPv6 stack instead of ZNA stack

•  We are implemen,ng some applica,ons on ZINK. –  Live streaming

•  We are evalua,ng mobility performance in comparison with NDN (NFD implementa,on).


Summary of this Talk

•  This talk argued that: –  Hierarchical approach is more suitable for ICN than narrow waist approach and

–  ICN is suitable for retrieving sta,c and stored content.

•  This talk introduced our recent research, ZINK: ICN on layered network architecture, ZNA.


Thank You! Ques,ons?

aconsideraonon informaoncentricnetworkingicn/wp-content/uploads/2015/04/icn_kickoff_3.pdf · ispld...

Documents