Scalable Point-to-multipoint Communication Information

Scalable Point-to-multipoint
Communication Information-centric
Networking
January, 2015
Börje Ohlman
Ericsson Research
Anders Eriksson, Karl-Åke Persson, Adeel Mohammad Malik, Marcus Ihlar and Linus Sunde
Why SPIN?
Scalable Point-to-Multipoint Mechanism for Information-centric
Networks (SPIN)
› Most existing ICN approaches require a new global ICN routing
mechanism to route based on the names of information objects.
– A new global name-based routing system raises concerns regarding
migration and scalability.
› In contrast SPIN:
– avoids name-based routing or IP multicast routing by making use of legacy
IP unicast routing combined with DNS
– supports two types of service models
› publish-subscribe
› request aggregation
– support client and server mobility
› DNS interacts with an additional Name Resolution System (NRS) which
resolves the name of an information object to a current locator of a
representation of the information object.
NetInf| Ericsson Internal | 2014-05-26 | Page 2
Point-to-multipoint as a
Network Service
WHAT
Server
› Scalable point-to-multipoint distribution
of pre-recorded content or real-time data
ICN
for e.g. IoT or live video
IP Network
› Application-independent
ICN
ICN
› Scales to very large numbers of clients
HOW
Client
Client
Client
Client
› Based on legacy IP routing
› New name resolution system as a complement to DNS
local
peer-to-peer
› Small modifications of CoAP, or a new NetInf protocol
› Introduction of packet interception, pub-sub, and cache functions in
edge routers
WHY
› Allows operators to add value, since the service is integrated in
edge routers and cannot be built as an OTT service
NetInf| Ericsson Internal | 2014-05-26 | Page 3
Publish-Subscribe
Subscriber
Client
Publisher
Server
Request Subscribe
Response Notification 1
Response Notification N
Cancel
Subscription State
NetInf| Ericsson Internal | 2014-05-26 | Page 4
Pub-Sub & Event Notification Service
Resolve:
FQDN / label ->
IP address
Sub
Sub
Sub
Sub
DNS
›
NRS
NER 1
SMNDO
SMNDO
›
›
global IP network
Publish binding:
FQDN / label ->
IP address
›
›
NER 3
RSMNDO
Name format:
FQDN / label
NER NetInf Edge Router
event notification
NER 2
Pub
subscribe request
publication
subscribe request acknowledgement
NetInf| Ericsson Internal | 2014-05-26 | Page 5
›
Point-to-multipoint distribution of
notifications to subscribers in near
real-time
Application-independent
Can be used for video distribution or
IoT
Scales to millions of subscribers
Allows operators to add value, since
this is not an OTT service
Can be built with small modifications
of existing protocols (HTTP and
Coap) and with legacy IP routing
Use of Tokens to Match Responses to
Intercepted Requests With Original Request
Client
6: Resp
(A1 , AC, t1)
Address AC
NetInf| Ericsson Internal | 2014-05-26 | Page 6
3: Req
(A2 , AS, t3)
2: Req
(A1 , AS, t2)
1: Req
(AC , AS, t1)
Int-1
Address A1
5: Resp
(A2 , A1, t2)
Int-2
Address A2
4: Resp
(AS , A2, t3)
Server
Address AS
Signalling sequence for set-up of a
point-to-multi-point tree
IOx
S1
AS
3: Req
(A11 , AS, t4)
4: Resp
(AS , A11, t4)
A11
R1
2: Req
(A21 , AS, t3)
1: Req
(AC1 , AS, t1)
A12
5: Resp
(A12 , A21, t3)
A21
R2
A22 A23
AC1
6a: Resp
C1 (A22 , AC1, t1)
NetInf| Ericsson Internal | 2014-05-26 | Page 7
1: Req
(AC2 , AS, t2)
AC2
6b: Resp
(A23 , AC2, t2) C2
An
C
IOx
R
S
IP address
Client
Information Object x
Information-centric Router
Server
Request
Response
Combining connectionless and Connection
Oriented Signalling
Client 1
Client 2
ICN Router
Subscription Request 1
Publishing
Server
Subscription Request 2
Subscription Request 3
Notification Response 2
Notification Response 3
Notification Response 1
HTTP GET Request 1
HTTP GET Request 2
HTTP GET Request 3
HTTP Response 2
HTTP Response 3
NetInf| Ericsson Internal | 2014-05-26 | Page 8
HTTP Response 1
Token Matching
a
Receive and store
1: Req(AC , AS , t1)
b Construct, store,
bind to 1, and send
2: Req(A1 , AS , t2)
1: Req(AC , AS, t1)
R
S
Construct
request
Match
1
T
c
d
Match
Construct
response
Receive
5: Resp(A2 , A1 , t2)
S
2
Address &
token
6: Resp(A1 , AC, t1)
2: Req(A1 , AS, t2)
T
R
5: Resp(A2 , A1, t2)
Match
5: Resp(A2 , A1 , t2)
with
2: Req(A1 , AS , t2)
e
Int-1
Address A1
f
NetInf| Ericsson Internal | 2014-05-26 | Page 9
Match
2: Req(A1 , AS , t2)
with
1: Req(AC , AS , t1)
Construct and send
6: Resp(A1 , AC , t1)
NetInf NODE Protocol Stack Using
Legacy IP Routing
Sub
Sub
Sub
Sub
NetInf Node Functions
•
pub/sub
•
event notification
•
request aggregation
•
caching
A
DNS
IP Network
NRS
A
• name-based routing
NetInf / COAP API
intercept
A
Publisher
NetInf/CoAP
NetInf/CoAP
UDP
UDP
IP
IP
NetInf / CoAP
requests and responses
transit packets
NetInf functions
NRS
NetInf| Ericsson Internal | 2014-05-26 | Page 10
Name Resolution System
Example Use Case prototyped and
Evaluated
› Live Video Streaming
– We show that a NetInf implementation of SPIN in request
aggregation mode can handle flash crowds very well, can scale to
unlimited number of users
– Request aggregation is best suited for use cases where each IO is
(normally) only requested once and the client can (roughly) predict
when it will become available
› Sensor networking
– With the pub/sub model the sensor can publish new readings as they
become available, no need to respond to periodic requests. It can
even go offline in-between publications
– Publish/Subscribe is best used when the publications are time series
and/or published infrequently at unpredictable times (e.g. fire alarms)
and/or when the publisher is only intermittently online
NetInf| Ericsson Internal | 2014-05-26 | Page 11
NetInf/SPIN
Request Aggregation
Streaming
node
NetInf
router
NetInf
network
Cache
NetInf
router
NetInf
router
Cache
NetInf Access network
NetInf| Ericsson Internal | 2014-05-26 | Page 12
Cache
CPU utilization as a function of the number of
clients
measured on routers R1, R2 and R3
Cache hit limit
Traditional HTTP caching vs. request aggregation
Measured values with traditional http proxy
Measured values with request aggregation proxy
Cache hit region with traditional http proxy
Cache hit region with request aggregation proxy
CPU Load (MHz)
CPU load in ICN routers R1 and R2
as a function of the number of
subscribers
R2
R1
NetInf| Ericsson Internal | 2014-05-26 | Page 15
Conclusions and Future Work
› Key take a ways:
– SPIN support both request aggregation and publish/subscribe
– SPIN can support flash crowds without network provisioning,
something not possible in today’s IP networks
– Use IP unicast routing both for forwarding requests and for retrieving
objects
› Future Work
– Access control using Attribute Based Encryption (ABE)
– Cut-through forwarding
NetInf| Ericsson Internal | 2014-05-26 | Page 16