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